7 Network Working Group T. Genovese
8 Request for Comments: 2218 Microsoft
9 Category: Standards Track B. Jennings
10 Sandia National Laboratory
14 A Common Schema for the Internet White Pages Service
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
27 This work is the result of the IETF Integrated Directory Services
28 (IDS) Working Group. The IDS Working Group proposes a standard
29 specification for a simple Internet White Pages service by defining a
30 common schema for use by the various White Pages servers. This
31 schema is independent of specific implementations of the White Pages
34 This document specifies the minimum set of core attributes of a White
35 Pages entry for an individual and describes how new objects with
36 those attributes can be defined and published. It does not describe
37 how to represent other objects in the White Pages service. Further,
38 it does not address the search sort expectations within a particular
41 1.0 Introduction to IWPS
43 The Internet community has stated a need for the development and
44 deployment of a White Pages service for use in locating information
45 about people in the Internet [PA94]. To facilitate interoperability
46 and to provide a common user experience, the Internet White Pages
47 Service (IWPS) must have a common set of information about each
50 A common user object would allow a user to go between implementations
51 of the service and to expect consistency in the types of information
52 provided. A common user object would also provide developers with an
53 unambigious method of representing the information managed by the
58 Genovese & Jennings Standards Track [Page 1]
60 RFC 2218 Common Schema for IWPS October 1997
63 This document will focus only on common information modeling issues
64 to which all IWPS providers must conform.
68 This document establishes the set of attributes that specify the
69 Common User Information Object for the IWPS. It does not attempt to
70 be an exhaustive specification of all objects that may be stored in
71 the IWPS. The process used by this document to define the user object
72 is recommended to be used to define other information objects used in
75 All conforming implementations must support at the minimum, the core
76 attributes listed in Section 5.0. Implementations may include local
77 attributes in addition to the core set and still be considered "in
80 This document will not specify rules with respect to information
81 privacy. Each country has its own set of laws and practices.
82 Previous work covering this area has been done by the North American
83 Directory Forum (NADF), whose publication [NADF92] contain
84 recommendations for registrants' rights in both the USA and Canada.
86 This document does not specify a Directory access protocol (i.e.
87 whois++, LDAP, DAP, etc.).
89 3.0 IWPS Schema Considerations
91 The description of the IWPS information object consists of the
92 following requirements:
94 1. Syntax for definition/representation of information
96 2. Publication of information object templates, etc.
97 3. Database structure or schema.
99 Items 1 and 2 will be covered in this document. Because database
100 structure can potentially restrict implementations (i.e. X.500 schema
101 based versus DNS schema based) it will be treated as a separate
102 research topic and will not be defined in this paper.
104 4.0 Syntax for Definition/Representation of Information Object
107 A clear, precise, and consistent method must be used when discussing
108 information object templates and their associated attributes.
109 Therefore, this document makes uses of the previously defined syntax
110 used by LDAP. To avoid restrictions on implementations of the IWPS,
114 Genovese & Jennings Standards Track [Page 2]
116 RFC 2218 Common Schema for IWPS October 1997
119 some syntax are listed as requirements vs specific encodings. The
120 general IWPS syntax is included in section 6.0 for reference.
122 The IWPS Person Object specifies a limited set of recommended
123 attributes that a White Pages Service must include. Storage of user
124 attributes are a local issue, therefore, this memo suggests storage
125 sizes but not storage types.
127 This document lists the syntax with the attributes for developers of
128 user interface (UIs) to use as a reference, but it does not specify
129 how the UI should display these attributes.
131 Attributes that contain multiple-line text (i.e. Address) must use
132 the procedure defined in RFC 822 in section 3.1.1 on "folding" long
133 header lines [RFC-822].
135 5.0 Information Object Template Definitions
137 This section describes the IWPS Person Information Object Template
138 and its associated attributes. The Person Object is a simple list of
139 attributes, no structure nor object inheritance is implied.
141 IWPS client applications should use the following size
142 recommendations as the maximum sizes of the attributes. However,
143 applications should be able to handle attributes of arbitrary size,
144 returned by a server which may not comply with these recommendation.
145 All size recommendations are in characters.
147 Note: Because many characters in many encodings require more than one
148 byte, the size recommendations cannot be interpreted as sizes in
151 This set of attributes describes information types, and are not
152 defined attributes in a particular schema. Any technology deploying
153 a White Page service (WHOIS ++, LDAP, vCard, etc.) will need to
154 publish as a companion document, their specific schema detailing how
155 the general attributes of the White Pages schema are expressed.
157 SPECIAL CONSIDERATIONS
159 Phone number: The full international form is recommended;
160 i.e. +1 206 703 0852. The field may contain
161 additional information following the phone
164 +1 800 759 7243 #123456
165 +1 505 882 8080 ext. 30852
170 Genovese & Jennings Standards Track [Page 3]
172 RFC 2218 Common Schema for IWPS October 1997
175 Email address: Is multivalued.
177 Certificate: Is multivalued.
179 Common Name: Is multivalued.
181 Language Spoken: Is multivalued.
183 THE INFORMATION OBJECT TEMPLATE FOR THE IWPS PERSON
185 --General Attributes --
187 Field Name Size Syntax
190 Cert 4000 Certificate
192 Common Name 64 WhitepageString
193 Given Name 48 WhitepageString
194 Surname 48 WhitepageString
195 Organization 64 WhitepageString
196 Locality 20 WhitepageString
197 Country 2 WhitepageString (ISO 3166)
198 Language Spoken 128 WhitepageString (RFC 1766)
200 --Personal Attributes
202 Personal Phone 30 PrintableString
203 Personal Fax 30 PrintableString
204 Personal Mobile Phone 30 PrintableString
205 Personal Pager Number 30 PrintableString
206 Personal Postal Address 255 Address
207 Description 255 WhitepageString
209 --Organizational Attributes
211 Title 64 WhitepageString
212 Office Phone 30 PrintableString
213 Office Fax 30 PrintableString
214 Office Mobile Phone 30 PrintableString
215 Office Pager 30 PrintableString
216 Office Postal Address 255 Address
220 Creation Date 24 GeneralizedTime
222 Modified Date 24 GeneralizedTime
226 Genovese & Jennings Standards Track [Page 4]
228 RFC 2218 Common Schema for IWPS October 1997
231 Modifier Name 255 URI
233 6.0 IWPS Person Information Object Template Syntax
235 This section defines the syntax used by the IWPS person information
236 object template. It is copied in whole from the LDAP attribute
237 working document with some modification for completeness.
241 The certificate field is intended to hold any kind of certificate;
242 X.509 certificates are one example. A specific implementation will
243 specify how to indicate the type of certificate when describing
244 the mapping of the IWPS schema onto the implementation schema.
248 This syntax must be able to encode arbitrary ISO 10646 characters.
249 One such encoding is the UTF-8 encoding [UTF-8].
253 Values of this syntax are encoded as printable strings,
254 represented as specified in X.208. Note that the time zone must
255 be specified. It is strongly recommended that Zulu time zone be
262 here are many kinds of mailbox addresses, including X.400 and
263 Internet mailbox addresses. The implementation must clearly
264 distinguish between different types of mailbox address, for
265 instance by using a textual refix or a set of attribute types.
266 There must be a way to represent any mailbox type.
270 According to Universal Postal Union standards, this field must be
271 able to represent at least 6 lines of 40 characters.
275 The encoding of a value with PrintableString syntax is the string
276 value itself. PrintableString is limited to the characters in
277 production <p>. Where production <p> is described by the
282 Genovese & Jennings Standards Track [Page 5]
284 RFC 2218 Common Schema for IWPS October 1997
287 <a> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' |
288 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' |
289 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' |
290 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' |
291 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' |
292 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z'
294 <d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
297 <p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
298 '/' | ':' | '?' | ' '
300 7.0 Publication of IWPS Information Object Templates.
302 The Working Group recommends that all information object templates
303 used for the IWPS be published.
305 Individual organizations may define information object templates that
306 are local in scope as required to meet local organizational needs.
307 All information that the organization wishes to be part of the IWPS
308 must use a published IWPS information object template.
312 Each country, and each state within the US, has legislation defining
313 information privacy. The suggested attributes in Section 5.0 may be
314 considered private and the directory administrator is strongly
315 advised to verify the privacy legislation for his domain.
317 As suggested in "Privacy and Accuracy in NIC Databases" [RFC-1355],
318 each directory provider should provide a clear statement of the
319 purpose of the directory, the information that should be contained in
320 it, and a privacy policy associated with that information. This
321 policy should include restrictions for data dissemination.
323 This policy is strongly recommended for the US and Canada and
324 required by many countries in the European Community for data
329 Data Integrity was first addressed in RFC 1107 [KS89], which states
330 "a White Pages service will not be used, if the information it
331 provides is out of date or incorrect." Therefore, any production
332 IWPS provider must insure that all data is reasonably correct and
338 Genovese & Jennings Standards Track [Page 6]
340 RFC 2218 Common Schema for IWPS October 1997
343 The Ancillary Attributes of the IWPS person template denote the
344 information's source and date of origin, and the source and date of
345 its latest modification. They provide the user with some measurement
346 of the quality of data making it easy to determine the owner and
347 freshness of the data retrieved.
349 The IWPS User Agent must be able to retrieve and display Ancillary
350 Attributes. Retrieval and display may be done as separate
353 The Ancillary Attributes are recommended as the minimum set of
354 attributes for any new information object template. Each IWPS server
355 may individually decide whether to support the storage and retrieval
358 The Ancillary Attributes (also defined in Section 5.0) provide the
359 following information about its associated information object:
361 1. The date and time the entry was created; Creation Date.
363 2. Owner or individual responsible for the data creation;
366 3. The date and time of the last modification;
369 4. Individual responsible for the last modification;
372 10.0 Security Considerations
374 Security is implementation and deployment specific and as such is not
375 addressed in this memo. Security must ensure that the constraints
376 mentioned in the Data Privacy Section 8.0 are complied with.
380 [KS89] Sollins, K., "A Plan for Internet Directory Services", RFC
381 1107, Laboratory for Computer Science, MIT, July 1989.
383 [NADF92] North American Directory Forum, "User Bill of Rights for
384 entries and listings in the Public Directory', RFC 1295,
385 North American Directory Forum, January 1992.
394 Genovese & Jennings Standards Track [Page 7]
396 RFC 2218 Common Schema for IWPS October 1997
399 [PA94] Postel, J., and C. Anderson, "WHITE PAGES MEETING REPORT",
400 RFC 1588, University of Southern California, February 1994.
402 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
403 Text Messages", STD 11, RFC 822, August 1982.
405 [RFC-1355] Curran, J., and A. Marine, "Privacy and Accuracy Issues
406 in Network Information Center Databases", FYI 15, RFC 1355, August
409 [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
410 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1, 1993.
412 [RFC-1766] Alvestrand, H., "Tags for the Identification of
413 Languages", RFC 1766, March 1995.
415 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
418 11.0 Authors' Addresses
421 The Microsoft Corporation
423 Redmond, Washington 98007
426 Phone: (206) 703-0852
427 EMail: TonyG@Microsoft.com
431 Sandia National Laboratories
432 Albuquerque, New Mexico 87106
435 Phone: (505) 845-8554
436 EMail: jennings@sandia.gov
450 Genovese & Jennings Standards Track [Page 8]