HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 09:08:20 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 17 Nov 1994 23:00:00 GMT ETag: "323e63-96a5-2ecbe070" Accept-Ranges: bytes Content-Length: 38565 Connection: close Content-Type: text/plain White Pages Requirements Working Group T. Genovese draft-ietf-whip-iwps-requirements-01.txt ESnet Expires: 16 May 1995 16 November 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 (IWPS). 1.0 Introduction The Internet community has done a significant amount of work in the analysis of Internet White Pages Services and several documents address the issue of IWPS requirements [KS89, PA94]. The work on this document has benefited from the review of this work and several implementations. Each implementation was developed to explore a solution set of requirements. A number of them are based on an underlying technology like X.500 [KH93]. Others have defined new or built on old systems [PD94]. With each approach we acquired a new understanding of the eneral problem set. The Internet always benefits from this type of implementation diversity and the most likely future Genovese [Page 1] Internet Draft Internet White Pages Requirements 16 November 1994 for the IWPS is that it will consist of a number of directory like services that will interwork to provide the general IWPS. The purpose of this document is to define a single set of functional requirements for the Internet White Pages Service that accommodates the wide variety of information retrieval protocols that may be used to create a directory service, based upon the work done to date. It is not the purpose of this document to propose restrictions for the development of the independent implementations of the IWPS. Yet, as these systems are built and deployed new issues of interoperability and data reliability come to play. Therefore a common set of information objects and procedures is proposed to minimize these problems. This Document will focus only on common information and operational modeling issues that all IWPS provider must conform to. To insure a consistent User view of this service we need to define a common naming structure. This will 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 data management. 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 will describe a conceptual model for the IWPS and deal with naming, schema, query and response issues for a narrowly defined subset of directory services. 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 process 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 wide scale directory services. To insure a consistent user view of the service, the User Agent (UA) Genovese [Page 2] Internet Draft Internet White Pages Requirements 16 November 1994 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 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 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 the definition of a simple, unified, client/server model would meet our needs. However, a simple model can not be achieved because, the different information servers that constitute the the IWPS will not, at least initially, use common designs or protocols. The servers of the IWPS do not provide a consistent delineation of function between the client and the server or a common method of query and response. One way to accommodate the existing, diverse client/server architectures, while creating a ubiquitous IWPS is to define a conceptual client/server model and the functions that must be performed within this model. This document will concentrate on how and what these servers must do as a minimum to participate in the IWPS with a limited set of data that will constitute the IWPS data model. We need to augment this data model with the type of operations that must be supported by the IWPS clients and servers. Throughout this document we refer to 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. The requirement for a consistent naming architecture for the IWPS presents a complex problem. This issue is described in detail later in this document. To aid in the understanding of the conceptual model we should point out that there are two name forms used in the IWPS. The following conceptual names will 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. The basic model for interaction between the Client and Server of the IWPS is depicted in Figure 1. Genovese [Page 3] Internet Draft Internet White Pages Requirements 16 November 1994 +-------------+ +--------+ +---------+ +----------+ IWPS Server | | |----------->| WPN |-------->| Search | wps.domain | | IWPS | +---------+ +----------+-------------+ | Client | +---------+ / | |<-----------| WPI/URN |<----------+ +--------+ +---------+ A White Pages Name is submitted and a White Pages Identifier is returned. +--------+ +---------+ +---------+ | |----------->| WPI/URN |-------->| Fetch | | IWPS | +---------+ +---------+ | Client | +---------+ / | |<-----------| URC |<----------+ +--------+ +---------+ A White Pages Identifier is resolved to its Uniform Resource Characteristic (URC). The URC list the IWPS server(s) that manage the IWPS Record. +------------+ +--------+ +---------+ +---------+ Directory | | |----------->| URL |-------->| Fetch | Service | | IWPS | +---------+ +---------+------------+ | Client | +-------------+ / | |<-----------| IWPS Record |<------+ +--------+ +-------------+ A URL from the URC is selected and resolved to the IWPS Record. Figure 1 Internet White Pages Model There are no restrictions on the general design or operations of IWPS 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 specific server requirements. How the user has to present the information for the requests to the UA or how the UA present the results to the user is outside the scope of this document. There are two basic operational requests defined for IWPS complaint UAs. Genovese [Page 4] Internet Draft Internet White Pages Requirements 16 November 1994 1. Search 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. 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 single queries similar to those performed within the domain name system. Support of both modes of UA to server interactions is expected by IWPS Users. Genovese [Page 5] Internet Draft Internet White Pages Requirements 16 November 1994 4.0 Naming 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. 4.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]. 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 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 6] Internet Draft Internet White Pages Requirements 16 November 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 servers accessed 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. 4.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 Genovese [Page 7] Internet Draft Internet White Pages Requirements 16 November 1994 locate individuals. 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. 5.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. 5.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. Genovese [Page 8] Internet Draft Internet White Pages Requirements 16 November 1994 1. BNF 2. ASN.1 The Working Group recommends the use of ASN.1. It provides us with a set of predefined attributes and encoding syntaxs. Also, it is well documented and widely available. The use of ASN.1 to specify the structure 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. 5.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. 5.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. 6.0 Security The IWPS must deal with two general security issues: Genovese [Page 9] Internet Draft Internet White Pages Requirements 16 November 1994 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. 6.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. 6.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. Genovese [Page 10] Internet Draft Internet White Pages Requirements 16 November 1994 7.0 Security Certificates Another feature that IWPS can provide us is the ability to store Security Certificates. It is needed by secure mail services such as PEM and PGP. To facilitate the storage and management of these Certificates a new element is defined for the iwpPerson object. This new element will allow multiple Certificates to be stored with the person record. It also allows for the deprecation of certificates through the use of a validity field. This field is use to state the beginning and end dates the certificate is valid. The element "certificates" is defined in Appendix A. 8.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 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 Genovese [Page 11] Internet Draft Internet White Pages Requirements 16 November 1994 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. 9.0 Unstructured Data There are a number of existing directory based systems that are currently providing White Pages style of information. These systems respond to queries by returning information without regard to any structure of the data. There is nothing in their protocol specifications that identify individual fields or attributes in the response that would allow it to be machine processable. To accommodate these systems and the way they return information, the element unstructureData has been added to the iwpPerson object. This element consists of a 1k block of data without any structure or content requirements. It can be used to represent/store any of the current sets of White Pages information. It should be noted that this element is added for backward compatibility of the existing systems only. It should not be used for the development of any new white page service. 10.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 11.0 References Genovese [Page 12] Internet Draft Internet White Pages Requirements 16 November 1994 [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 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. [PD94] Deutsch, P., Schoultz, R., Faltstrom, P., Weider, C., Architecture of the Whois++ Service, Internet Draft: draft-ietf- wnils-arch-01.txt, April 6, 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. 12.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 Genovese [Page 13] Internet Draft Internet White Pages Requirements 16 November 1994 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, postalAddress, telephoneNumber, emailAddress, certificates, unstructuredData, ancillaryInformation} ::={iwpsObjectTemplate.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} -- The element for the storage of Email information -- emailAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX EmailAddress ::={iwpsAttributeType 1} EmailAddress ::= SEQUENCE (SIZE(1..ub-email-boxes)) OF caseIgnoreString(SIZE(1..ub-email-addr)) -- The element to be used to store Securiy Certificates -- certificates ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX Keys{iwpsAttributeType 3} Genovese [Page 14] Internet Draft Internet White Pages Requirements 16 November 1994 Keys ::= SEQUENCE (SIZE(1..ub-keys)) OF keyInfo keyInfo ::= SEQUENCE{ validity Valid, key KeyType} Validity ::= SEQUENCE{ notBefore UTCTime, notAfter UTCTime} KeyType ::= SEQUENCE{ algorithm OBJECT IDENTIFIER, subjectKey caseIgnoreStringSyntax(SIZE(1..ub-keysize))} -- The Unstructure Data element used to contain free form data -- unstructuredData ::= caseIgnoreStringSyntax(SIZE(1..ub-data)) -- 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), postalAddress (3), telephoneNumber (4), Genovese [Page 15] Internet Draft Internet White Pages Requirements 16 November 1994 emailAddress (5), wpi (6) } -- Size limits used by the IWPS -- ub-database INTEGER ::= 1024 ub-data INTEGER ::= 1024 ub-email-boxes INTEGER ::= 8 ub-email-addr INTEGER ::= 1024 ub-keys INTEGER ::= 6 ub-keysize INTEGER ::= 512 ub-iwps-wpi INTEGER ::= 256 -- 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} Genovese [Page 16] Internet Draft Internet White Pages Requirements 16 November 1994 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) +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 Genovese [Page 17] Internet Draft Internet White Pages Requirements 16 November 1994 Woermann, Ascan Woermann@osi.e3x.fr Wright, Russ Wright@LBL.Gov Lawrence Berkeley Laboratory 1 Cyclotron Road Mail-Stop 50B-2258 Berkeley, California, USA 94720 +1 510 486-6965 Genovese [Page 18] Internet Draft Internet White Pages Requirements 16 November 1994 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 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 PEM Privacy Enhanced Mail PGP Pretty Good(tm) Privacy: Public Key Encrytion for the Masses Purported name: A naming construct which is syntactically a name, but which has not been shown to be an actual entry in the IWPS. Genovese [Page 19] Internet Draft Internet White Pages Requirements 16 November 1994 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. 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: 16 May 1995 Genovese [Page 20]