Integrated Directory Services Working Group T. Genovese draft-ietf-ids-iwps-schema-spec-01.txt Microsoft Expires: 11 December 1996 11 June 1995 A Common Schema for the Internet White Pages Service Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), it areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Overview The IETF Integrated Directory Services (IDS) Working Group proposes to establish a specification for a simple Internet white pages service. To facilitate this effort it would be helpful to have a common schema used by the various white page servers. This document is designed to specify the basic set of attributes to be used for a white page entry for a person. This schema does not describe how to represent other objects in the White page service. It does describe how new objects can be defined and registered. This schema is independent of implementations of the White Page service. 1.0 Introduction The Internet community has stated that there is a need for the development and deployment of a White Page service. This service would be used to locate information about people in the Internet[PA94]. To facilitate interoperibility and a common user experience the Internet White Pages service needs to have a common set of information about each person. This Document will focus only on common information modeling issues to which all IWPS providers must conform. To insure a consistent User experience of this service we need to define a common User object. This will allow a User to go between different implementations of the service and have a consistent expectation asto what information can be found about people on the Internet. Developers of this service need to have an unambiguous method of representing the Information objects Tony Genovese [Page 1] Internet Draft Common Schema for IWPS June 1996 managed by the service. This will help facilitate interoperability and data management. 2.0 Scope This document will establish the set of attributes that specify the common user information object for the IWPS. It will not attempt to be an exhaustive specification of all objects that will be stored in the IWPS. The process used by this document to define the User object will be used to define all other information objects used in the IWPS. This document will not specify rules with respect to information privacy. Each country has its own set of laws and practices. The best work covering this area was done by NADF [NADF92]. It makes recommendations for the USA Canada. 3.0 IWPS Schema Considerations The information object description requirements for the IWPS consists of the following: 1. Syntax for definition/representation of Information Object Templates. 2. Registration procedures for information object Templates, etc. 3. Database structure or schema. Items 1 and 2 will be covered in this Document. Database structure because, it will potentially restrict implementations (i.e. X.500 schema based Vs DNS schema based) will not be defined in this document. This area is a separate Research topic and will be covered in its own document. 3.1 Syntax for definition/representation of Information objects A clear, precise and consistent method must be used when information object Templates and their associated attributes are discussed within the context of IWPS. There are two possible methods to do this. i.e. 1. BNF 2. ASN.1 The Working Group has recommended the use of ASN.1. It provides us with a set of defined attributes and encoding syntax's. Also, it is well documented and widely available. The use of ASN.1 to specify the attributes of the information objects does not imply the use of Basic Encoding Rules (BER) for any IWPS servers protocols. The use of Object inheritance is not used or specified by this document. Tony Genovese [Page 2] Internet Draft Common Schema for IWPS June 1996 The IWP person object specifies a set of recommended attributes that a White Page service should include. It recommends storage sizes, but does not recommend storage types. How an implementation stores the user attributes is a local issue. The Syntax listed with the attributes are provided so the developers of UIs will have a consistent expectation. This document does not specify a Director access protocols (i.e. whoi++, LDAP,DAP, etc.) or how the UI is to display these attributes. Attributes that contain textual information that must be split over multiple lines (i.e. Postal address) will use the procedure defined in RFC 822 in section 3.1.1 on "folding" long header lines [RFC-822]. For International localization it is recommended that attributes (except email addresses) used to identify people use DirectoryString syntax defined by LDAP [LDAP-A]. 3.2 Publishing of IWPS Information object Templates. The Working Group recommends publication of all information object Templates used for the IWPS. To facilitate distribution of IWPS information object Templates they should be made available on the Internet information server (i.e. InterNIC). At a minimum it is recommended that any new information object Template that will be made available via the IWPS will be published as a RFC. Individual organizations may define information object Templates that are only local in scope. This may be needed to meet local organizational needs. All information that the organization wishes to be part of the IWPS must use an IWPS published information object Template. 5.0 Data Integrity The question of Data Integrity was first addressed in RFC1107 [KS89]. It basically states, that if the information is out of date it is useless and the service will not be used. Therefore, a clear requirement is that any production IWPS provider must insure that all data is reasonably correct and current. To facilitate the User in determining the quality of the data that has been retrieved it is recommended that the optional Ancillary attributes of the IWPS person Template be supported. This would require the IWPS UA to be able to retrieve and display this information. This may be done as a separate operation from the fetch of the information object. The Ancillary Attributes are defined in Appendix A. It is further recommended that any new information object Template include as a minimum the Ancillary attributes as an optional set of attributes. It would then be left to the IWPS servers to optionally support the storage and retrieval of this data. The Ancillary attributes have been designed to provide the following Tony Genovese [Page 3] Internet Draft Common Schema for IWPS June 1996 information about the information object with which it is associated: 1. The date and time of the last modification. 2. Who performed the last modification. 3. Who owns or is responsible for the data stored in the information object. 4. What is the official source of the data. 7.0 References [LDAP-A] Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight Directory Access Protocol: Standard and Pilot Attribute Definitions", Draft-ietf-asid-ldapv3-attributes-01.txt, June, 1996 [KS89] Sollins, K., "A Plan for Internet Directory Services", RFC 1107, Laboratory for Computer Science, MIT, July 1989. [NADF92] North American Directory Forum, "User Bill of Rights for entries and listings in the Public Directory', RFC 1295, North American Directory Forum, January 1992. [PA94] Postel, J., Anderson, C., "WHITE PAGES MEETING REPORT", RFC 1588, University of Southern California, February 1994. [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. 8.0 Authors Address Tony Genovese The Microsoft Corporation One Microsoft way Redmond, Washington 98007 USA Phone: (206) 703-0852 EMail: TonyG@Microsoft.com Appendix A Information Object Template Definitions This appendix contains the IWPS Person Information Object Template and its associated attributes. The Person Object is a simple list of attributes, no structure or object inheritance is implied. All size recommendations are in bytes. Phone numbers should be the full international form i.e. +1 206 703 0852. Tony Genovese [Page 4] Internet Draft Common Schema for IWPS June 1996 -- The Information Object Template for the IWPS person -- --General Attributes -- Field Name Size Syntax Primary Email 120 CaseIgnoreString Primary Cert 4000 Certificate Secondary Email 120 CaseIgnoreString Home Page 128 caseExactString Common Name 64 DirectoryString Given Name 48 DirectoryString initials 12 DirectoryString Surname 48 DirectoryString Generation Qual 06 DirectoryString Organization 64 DirectoryString Locality 20 DirectoryString Country 02 DirectoryString (ISO3166) Language 02 DirectoryString (ISO 639) --Personal Attributes Telephone Number 20 PrintableString Fax 20 PrintableString Mobile Phone 20 PrintableString Pager Number 20 PrintableString Mailing Address 255 PostalAddress Birth Date 08 PrintableString Gender 01 PrintableString Marital Status 01 PrintableString Bio 255 DirectoryString --Organizational Attributes Title 64 DirectoryString Office Phone 20 PrintableString Office Fax 20 PrintableString Office Mobile Ph 20 PrintableString Office Pager 20 PrintableString Mailing Address 255 PostalAddress --Security Password 64 Password --Ancillary User Id 04 Integer Creation time 24 GeneralizedTime Last Modified 24 GeneralizedTime Creator Name 255 DN Modifier Name 255 DN Tony Genovese [Page 5] Internet Draft Common Schema for IWPS June 1996 Tony Genovese [Page 6]