White Pages Requirements Working Group T. Genovese draft-ietf-whip-iwps-requirements-01.txt ESnet Expires: 15 January 1995 15 July 1994 A Specification for the Simple 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 Internet White Pages Requirements (Whip) Working Group proposes to establish a set of requirements for a Simple Internet White Pages Service without prejudice to existing recommendations or implementations. This Document is designed to be used by other WGs in the IETF to guide the overall structure of the Internet White Pages Service. 1.0 Introduction The Internet has explored, several times, the issue of requirements for the Internet White Pages Service (IWPS) [KS89, PA94]. The work on this document has benefited from being able to review several implementations. Each implementation was developed to explore a solution set of requirements. With each approach we acquired a new understanding of the general problem set. The Internet always benefits from this type of implementation diversity. The Internet has done a significant amount of work in looking at what is needed by the Internet White pages services. A number of them are based on an underlying technology [KH93] like X.500. Others have define new or built on old systems [XXXX]. The most likely future for the IWPS is that it will consist of a number of directory like services that will Genovese [Page 1] Internet Draft Internet White Pages Requirements 15 July 1994 interwork to provide the general IWPS. It is not the purpose of this Document to restrict the development of the independent implementations of the IWPS. Yet, as these systems are built and deployed new issues of interoperability and synchronization come to play. Therefore, if we can agree on some common Information Objects and procedures we may be able to minimize these problems. This Document will focus only on common information and operational modeling issues that all IWPS service provider must conform to. To insure a consistent User view of this service we need to define a common naming structure. This would allow a User to go between different implementations of the service and have a consistent way of looking for people or other Information Objects in the Internet. For developers of this service we need to have an unambiguous method of representing the Information Objects managed by the service. This will help facilitate interoperability and synchronization. As any group of people begin to work on an issue a set of words or terms start to take on meaning only to the group. This helps them to communicate common ideas. Depending where you are when you join the effort the terms may be confusing or even new. To facilitate our need to communicate common ideas Appendix C attempts to document certain words and terms used in this document. It also, will expand all Acronyms used in this document. It may be useful for the reader to glance through this appendix before reading this document. 2.0 Scope This Document attempts to establish a simple set of information objects that should prove extensible and usable by developers of the IWPS. These Information Objects coupled with a basic set of requirements will form a basis from which related IETF efforts can build an ubiquitous IWPS. It will only deal with issues that are common to this service. It will not attempt to be an exhaustive specification of the IWPS. In particular this Document will deal with Naming and Schema issues. It will also provide a conceptual model for the IWPS. To insure a consistent User view of the service, the User Agent (UA) will need to be addressed. This will not be a specification of a UA but, will deal with those issues of information content as presented to or by the User. This Document will also describe a basic set of operations that will need to be supported by the UA. 3.0 Naming Genovese [Page 2] Internet Draft Internet White Pages Requirements 15 July 1994 The name associated with the IWPS is complicated by opposing naming requirements. One requirement was to allow a user, with incomplete naming information to be able to navigate the IWPS until the person or Information Object is found. This name form would map one name to one or more Information Objects (i.e. All Smiths at LLNL, US). We also, require a name that would uniquely identify a person or Information Object. This name form would map one name to one and only one Information Object. It would be ideal if the name we used to navigate through the IWPS could be derived from the unique identifying name but, we can not meet both goals with the same name. Therefore, two naming structures are needed. It is recommended that the following conceptual names be used: White Pages Name (WPN) Maps one name to one or more IWPS entries. White Pages ID (WPI) Maps one name to one and only one IWPS entry. 3.1 White Pages Identifier - WPI The WPI is designed to directly locate a particular person or Information Object in the Internet. A WPI provides a one to one mapping between a name and an IWPS Information Object. When a User presents a WPI to a User Agent the service will be able, after name resolution, to locate the Information Object precisely. It is recommended that the WPI be represented as a URN [SM94]. At the time of this writing the final form of URNs has not been specified. When that work is finished it will be used to specify the WPI structure. In particular it is important that the WPI have the following qualities: 1. Global uniqueness 2. Persistence 3. Independence 4. Human transcribability These and other qualities are proposed characteristics of a URN. For illustration purposes it will be assumed that the WPI URN will have the following form: Where wp.nersc.gov is the DNS registered service provider that manages the Information Object u7224. It is recommended that the DNS be used to specify IWPS service providers. The specification of the Genovese [Page 3] Internet Draft Internet White Pages Requirements 15 July 1994 WPI attribute is in Appendix A. The IWPS, for any particular organization, will consist of a number of different information servers. These multiple servers may use different access protocols. The set of servers may also change over time. The use of URN will help to facilitate this changing environment. This will be accomplished by using the URN to URC mapping features [M94]. After a URN is resolved to its URC the attributes of the URC would be used by the IWPS UA to access a particular server. e.g. URN -> URC: 1. Version, etc. info 2. URL: finger://nersc.gov 3. URL: whois: //nersc.gov 4. URL: solo: //es.net This leaves administrative control of what servers can be used by the IWPS UAs with the local manager of the URC. It is possible that a person or Information Object may be registered with multiple servers. This could lead to having multiple WPIs for each Information Object. It is recommended that the Information Object have only one WPI and the multiple servers should be listed as URLs in the WPI's URC. It is left to the UA implementation, with possible User interaction, to select which URL to resolve. The WPI is designed to be Human Transcribable so, Users could exchange them via Email or on business cards. Because of the persistence nature of a WPI it could be used to get the latest information about a User even though the information in an Email or on a business card has expired. It is more likely that WPIs will be used more in UA to Server or Server to Server requests. 3.2 White Pages Name - WPN A WPN consists of the attributes from an Information Object Template. The Ancillary Information Attribute, described later, is not part of the WPN. Depending on the number of attributes enumerated in a IWPS query, it will provide a one to many mapping between a name and an IWPS Information Object. In general the WPN will be used by people with incomplete naming information to construct a Purported Name that can be submitted to the IWPS to locate an Internet person or Information Object. This Purported Name would be used as a guess when querying the IWPS. This process of discovery will be iterative in nature. It is envisioned that the most common use of a WPN would be to do searches of the IWPS space to locate individuals. Genovese [Page 4] Internet Draft Internet White Pages Requirements 15 July 1994 To insure a consistent view of what an Internet person WPN will contain, the Information Object Template Internet White Page Person is specified in Appendix A. It contains the minimum required set of attributes for representing a person in the IWPS. Similar Information Object Templates can be defined for organizations, documents, services, etc. This document deals only with the Internet person WPN. Because the Internet person WPN consists of a number of attributes it is possible that you can construct a number of Purported Names for the same person. e.g. Huitema, Inria, Fr Christian Huitema, Inria, Fr Huitema, Rodeo, Inria, Fr Huitema, Sophia, Inria, Fr The actual order the attributes of the WPN are presented by the user to the IWPS UA or used by the UA to generate a query is left to the implementation. The User must realize that the more complete the WPN is the better the chance is that useful information can be returned. i.e. a query for just "Huitema, Fr" will most likely fail. 4.0 IWPS Schema considerations The information 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. 4.1 Syntax for definition/representation of Information Objects A clear, precise and consistent method must be used when Information Object Templates and their 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 recommends the use of ASN.1. It provides us with a Genovese [Page 5] Internet Draft Internet White Pages Requirements 15 July 1994 set of pre-defined attributes and encoding syntax's. Also, it is well documented and widely available. 4.2 Registration of IWPS Information Object Templates. The Working Group recommends the registration and publication of all Information Object Templates used for the IWPS. We will use the IANA branch of the ISO OID tree for registration of the IWPS Object Templates. This branch was used by the Object Templates listed in Appendix A. 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 in a RFC and its OID registered with IANA. Individual organizations may define Information Object Templates that are only local in scope. This may be needed to meet local organizational needs. If these Information Object Templates are not registered with the IWPS, they may not be processable by the general IWPS UAs. All information that the organization wishes to be part of the IWPS must use an IWPS registered Information Object Template. 4.3 Database Structure It is envisioned that the IWPS will consist of a number of independent information servers. Each of these servers will construct their own Databases. Therefore, no Internet wide directory Database will be provided. This by its nature will cause interoperability and synchronization problems that must be worked out. This area of research is under development in the IETF Application Area. 5.0 Security The IWPS must deal with two general security issues: 1. Privacy laws/rules 2. Access Control/Authentication The Global nature of the Internet creates a complex interplay of Country and Organizational laws/rules. It would best serve the IWPS if all information was readily available to all people in the Internet but, this comes up against the security/privacy needs of Organizations and/or people. Security is further complicated by the potential diverse nature of the IWPS server environment. Each server could have different forms of Access/Authentication controls in place to meet their needs. Genovese [Page 6] Internet Draft Internet White Pages Requirements 15 July 1994 5.1 Privacy The question of User's Privacy requirements for North America has been addressed by NADF [NADF92]. The NADF document does not take into account the Global Internet set of Users. This topic is an area of research in the IETF Applications Area. It will not be dealt with in this document. 5.2 Access Control/Authentication With the IWPS environment consisting of multiple server types and different autonomous management domains the question of Access control is at best problematic. It is also clear that a model to approach this problem is needed if the IWPS is to be deployed. To meet the current needs of this community it is recommended that the general issues of Access Control/Authentication be broken down into the following two models: 1. Anonymous or Public Access 2. Administrative Access The issue of Administrative Access Control is a current research area of the IETF Application Area. This topic deals in general with the issues associated with the ability to add or modify entries in the IWPS. This document will only address the Anonymous or Public Access issues of the IWPS. The IWPS is to be considered a public access service only. If an organization is participating in this service, they must provide at a minimum anonymous access to their service. It may be the result of a query posted to one of these servers that a response is returned that the requested information is not available to the requester. This negative response is a minimum requirement for all IWPS servers. 6.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 Information attribute of the IWPperson 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 Genovese [Page 7] Internet Draft Internet White Pages Requirements 15 July 1994 of the Information Object. The Ancillary Information Attribute is defined in Appendix A. It is further recommended that any new Information Object Template include as a minimum the Ancillary Information attribute as an optional attribute. It would then be left to the IWPS servers to optionally support the storage and retrieval of this data. The Ancillary Information attribute has been designed to provide the following information about the Information Object it is part of: 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. 5. Which attributes in the Information Object has been changed. As new Information Object Templates are defined for the IWPS a new changeRecord type will need to be defined for it and assigned to the changeRecord attribute. This attribute is not a part of the WPN. It is not to be used as part of the Purported Name presented to the IWPS UA. 7.0 Performance If the IWPS is to be useful to its User community it must provide for reasonable performance. To set a performance requirement is unnecessary. Simply because, if the service does not meet the performance needs demanded by its Users it will not survive. The performance of the distributed IWPS will be affected by many things potentially outside the control of the local provider. The local provider can not control: 1. Remote server response or availability 2. Network speeds or partitions 8.0 Conceptual Model The Internet White Page Service will utilize the current information servers and not restrict the development of new information servers. It will also, strive to provide a consistent User view of the Genovese [Page 8] Internet Draft Internet White Pages Requirements 15 July 1994 service. To achieve these potentially tangential requirements it will be necessary to develop a model that can guide the current use and future development. At first glance it would seem that a simple Client/Server model would meet our needs. Yet, a clean model along these lines can not be achieved because, the different information servers that constitute the the IWPS will not, at least initially, use common designs or protocols. So, in our case the server or in general the servers of the IWPS are not definable. The only way to achieve a ubiquitous IWPS within the constraints setup in this document is to utilize a Conceptual Client/Server model. It can only be a conceptual model because, we can not define the underlaying servers. The IWPS will consist of a number of different Information servers. So, the exact structure of the servers will be opaque from our point of view. This document will concentrate on how and what these servers must do as a minimum to participate in the IWPS. We have developed so far a description of the data that will constitute the IWPS data model. We need to augment this data model with the type of operations that will need to be supported by the IWPS Clients and Servers. Through out this document we have been discussion the IWPS UA as the software that the User uses to access the IWPS. This UA can be seen as a Client of the IWPS servers. Therefore, you can use the term Client or UA interchangeably when discussing IWPS. There are two basic modes of operation that describe the way the UA will be used to access the servers. 1. Connection oriented - Interactively 2. Connectionless - Command/Response Long lived connections would help serve Users that are doing interactive types of searches or requesting multiple Information Objects. Connectionless mode of use would serve more the DNS style of requests. Both modes of UA to server interactions are expected by IWPS Users. There are no restrictions on the general design or operations of Information service UAs. Any UA that is going to participate in the IWPS must be capable of passing required operational requests to the various Information servers. These request must conform to the servers requirements. There are two basic operational requests defined for IWPS complaint UAs. 1. Search Genovese [Page 9] Internet Draft Internet White Pages Requirements 15 July 1994 2. Fetch (get, read, retrieval) The UA would use a WPN as the set of input parameters for the Search operation. The UA would use a WPI as the input parameter for the Fetch operation. Some UAs may wish to support addition modifiers to these operations. On a Fetch the User may be allowed to request that only certain attributes be returned. This would imply that the server supports this modifier or the UA would have to support it. There are two forms of response expected from the server for each of the above requested operations. 1. Positive - data or results 2. Negative - errors or suggestions With the Search operation a Positive response would imply that a WPI was returned to the UA. A Positive response to a Fetch operation would be the actual Information Object. Some negative responses to a Fetch or Search operation will be: Fetch: 1. Access denied. 2. Server specific Errors - administrative limit notices. 3. Referral to one or more servers. Search: 1. Access denied. 2. Server specific Errors - administrative limit notices. 3. Partial match notification. 4. Suggestions for possible WPNs to try. With respect to the Search Operation, effective server responses of the type 3 and 4 form above would help facilitate IWPS navigation. 9.0 References [KH93] Hardcastle-Kille, S.; Huizer, E.; Cerf, V.; Hobby, R.; Kent, S.; "A Strategic Plan for Deploying an Internet X.500 Directory Service", RFC 1430, ISODE-Consortium, February 1993. [KS89] Sollins, K., "A Plan for Internet Directory Services", RFC 1107, Laboratory for Computer Science, MIT, July 1989. [M94] Mitra, "URN to URC resolution scenario", Internet Draft: draft-ietf-uri-urn2urc-00.txt [MM94] Mealling, M. "Encoding and Use of Uniform Resource Genovese [Page 10] Internet Draft Internet White Pages Requirements 15 July 1994 Characteristics", Internet Draft: draft-ietf-uri-urc-spec-00.txt [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. [SM94] Sollins, K., Masinter, L., "Requirements for Uniform Resource Names", Internet Draft: draft-sollins-urn-01.txt [WR92] Weider, C., Reynolds, J., "Executive Introduction to Directory Services Using the X.500 Protocol", RFC 1308, ANS, March 1992. 10.0 Author's Address Tony Genovese Energy Science Network National Supercomputing Center Lawrence Livermore National Laboratory 7000 First Street Livermore, California 94551 USA Phone: (510) 423-2471 EMail: Genovese@ES.net Appendix A Information Object Template Definitions The Information Objects Template and attributes defined in this appendix are used to define the contents of Information Objects of the IWPS. In particular the the Template defined below deals with the person Object. Any new Information Object must be registered with IANA. -- The Information Object Template for the IWPS person -- iwpPerson OBJECT-CLASS SUBCLASS OF top MUST CONTAIN{ commonName, wpi} MAY CONTAIN{ surname, organizationalName, Genovese [Page 11] Internet Draft Internet White Pages Requirements 15 July 1994 postalAddress, telephoneNumber, emailAddress, ancillaryInformation} ::={iwpsObjectTemplate.1} emailAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX EmailAddress ::={iwpsAttributeType 1} -- The WPI attribute to be use by Information Objects of the IWPS -- wpi ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax ((SIZE(1..ub-iwps-wpi)) ::={iwpsAttributeType 2} EmailAddress ::= SEQUENCE (SIZE(1..ub-email-boxes)) OF caseIgnoreString(SIZE(1..ub-email-addr)) -- The Ancillary Information attribute used for data integrity -- ancillaryInformation ::= SEQUENCE{ LastModifiedDate UTCTime, LastModifiedBy, commanName, OwnerofData, commonName, OfficialSourceofData dataBase, WhatWasChanged changeRecord} dataBase ::= caseIgnoreStringSyntax(SIZE(1..ub-database)) -- Change record subtypes are the MUST CONTAIN attributes -- changeRecord ::= iwpsPersonType (commonName | wpi) iwpsPersonType ::= BIT STRING { commonName (0), surname (1), organizationalName (2), Genovese [Page 12] Internet Draft Internet White Pages Requirements 15 July 1994 postalAddress (3), telephoneNumber (4), emailAddress (5), wpi (6) } -- Size limits used by the IWPS -- ub-iwps-wpi INTEGER ::= 256 ub-email-boxes INTEGER ::= 8 ub-email-addr INTEGER ::= 1024 ub-database INTEGER ::= 1024 -- Object Identifiers use by the IWPS -- Internet OBJECT IDENTIFIER ::= {ISO(1) org(3) DOD(6) 1} iwps OBJECT IDENTIFIER ::= {Internet NN} iwpsAttributeType OBJECT IDENTIFIER ::= {iwps 1} iwpsObjectTemplate OBJECT IDENTIFIER ::= {iwps 2} Appendix B Technical Contributors The following people contributed to the technical issues and discussions of this document: Gargano, Joan jcgargano@ucdavis.edu University of California Computing Services Davis, CA 95616 (916) 752-2591 Hamilton, Martin martin@mrrl.lut.ac.uk Department of Computer Studies University of Technology Loughborough, Leicestershire LE11 3TU, UK. Hedberg, Roland rhg@UMDC.UMU.SE Umea University Umea SE +46 90-165204 Howes, Tim tim@terminator.rs.itd.umich.edu ITD Research Systems 4214 Argus Building 535 West William Street Ann Arbor, MI 48103-4943 +1 313 747 4454 (voice) Genovese [Page 13] Internet Draft Internet White Pages Requirements 15 July 1994 +1 313 764 5140 (fax) Huitema, Christian Christian.Huitema@inria.fr Jurg, Peter Peter.Jurg@SURFnet.nl Langlois, Sylvain Sylvain.Langlois@der.edf.fr Lenggenhager, Thomas Lenggenhager@SWITCH.CH SWITCH Teleinformatics Services Limmatquai 138 CH-8001 Zurich CH +41 1 261 8178 Pays, Paul-Andre pays@faugeres.inria.fr Spero, Simon ses@tipper.oit.unc.edu Waugh, Andrew ajw@mel.dit.csiro.au Woermann, Ascan Woermann@osi.e3x.fr Wright, Russ RWWright@lbl.gov Information and Computer Science Lawrence Berkeley Laboratory 1 Cyclotron Road Berkeley, California, USA 94720 Appendix C Glossary Attribute: Typed information that constitutes a part of an Information Object that is stored in the IWPS. DNS: Domain Name System. Entry: An Information Object. IETF: Internet Engineering Task Force Genovese [Page 14] Internet Draft Internet White Pages Requirements 15 July 1994 Information Object: An instance of an Information Object Template. Information Object Template: An abstract way of representing people, machines Servers, etc., as data that can be stored in a IWPS server. IWPS: The Internet White pages Service. NADF: North American Directory Forum Purported name: A naming construct which is syntactically a name, but which has not been shown to be an actual entry in the IWPS. Schema: The structure applied to the data that represents Objects in the Internet. This will consist of a set of rules and constraints that define Information Objects and Information Object Templates. URC: Uniform Resource Characteristics. URL: Uniform Resource Locator. URN: Uniform Resource Names. User: The end user of the IWPS. i.e. The person that accesses the IWPS. Genovese [Page 15] Internet Draft Internet White Pages Requirements 15 July 1994 User Agent: The software Application that is used by a person to access the IWPS. WPI: White Pages Identifier. A naming construct that identifies one and only one entry in the IWPS. WPN: White Pages Name. A naming construct that may identify one or more entries in the IWPS. The WPN would be used to construct Purported Names for submission to the IWPS UAs for directory searches. Expires: 15 January 1995 Genovese [Page 16]