RFC 2218

RFC 2218: A Common Schema for the Internet White Pages Service 💖

okay bestie, the header tea ☕ this is an Internet Standards Track doc from October 1997, written by T. Genovese (Microsoft) and B. Jennings (Sandia National Laboratory). It comes out of the IETF Integrated Directory Services (IDS) Working Group. The header doesn't list anything it obsoletes or updates, so there's no drama there 🙈

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Abstract ✨

so this work is the result of the IETF Integrated Directory Services (IDS) Working Group. The IDS crew basically wants a simple Internet White Pages service, and they're getting it by defining a common schema that all the White Pages servers can use. The schema doesn't care how any particular implementation is built 💅

This document only nails down the minimum set of core attributes for an individual's White Pages entry, and explains how new objects with those attributes can be defined and published. It does not explain how to represent other objects in the White Pages service. It also doesn't touch on the search sort expectations within a particular service 🎀

1.0 Introduction to IWPS 🌸

the Internet community has said it needs a White Pages service for finding information about people on the Internet [PA94]. For interoperability and a shared user experience, the Internet White Pages Service (IWPS) MUST have a common set of information about each person.

a common user object lets a user move between implementations of the service and expect the same kinds of information to show up. It also gives developers an unambigious way to represent the information the service manages 🦋

this document is going to focus only on the common information modeling issues that all IWPS providers MUST conform to.

---

2.0 Scope 🧚

this document defines the set of attributes that make up the Common User Information Object for the IWPS. It is not trying to be an exhaustive spec for every object that might be stored in the IWPS. The process this document uses to define the user object is RECOMMENDED for defining the other information objects used in the IWPS.

All conforming implementations MUST support, at the minimum, the core attributes listed in Section 5.0. Implementations MAY include local attributes on top of the core set and still be considered "in conformance" 💜

this document won't set any rules about information privacy. Every country has its own laws and practices. The North American Directory Forum (NADF) already covered this area in its publication [NADF92], which has recommendations for registrants' rights in both the USA and Canada 🇺🇸

This document does not specify a Directory access protocol (i.e. whois++, LDAP, DAP, etc.).

3.0 IWPS Schema Considerations 🍓

the IWPS information object is described by the following requirements:

1. Syntax for definition/representation of information object templates.
2. Publication of information object templates, etc.
3. Database structure or schema.

Items 1 and 2 are covered in this document. Database structure can restrict implementations (X.500 schema based versus DNS schema based, for example), so it's treated as a separate research topic and won't be defined in this paper 🫶

4.0 Syntax for Definition/Representation of Information Object Templates 🎀

a clear, precise, and consistent method MUST be used whenever information object templates and their attributes get discussed. So this document uses the syntax LDAP already defined. To avoid restricting implementations of the IWPS, some syntax is listed as requirements instead of specific encodings. The general IWPS syntax is in Section 6.0 for reference 📖

the IWPS Person Object lists a limited set of RECOMMENDED attributes that a White Pages Service MUST include. Storing user attributes is a local issue, so this memo suggests storage sizes but not storage types 🗂️

this document lists the syntax alongside the attributes so UI developers have a reference, but it doesn't say how the UI should display them 👑

Attributes that contain multiple-line text (i.e. Address) MUST use the "folding" procedure for long header lines defined in RFC 822 in section 3.1.1 [RFC-822].

5.0 Information Object Template Definitions 💅

this section describes the IWPS Person Information Object Template and its attributes. The Person Object is a simple list of attributes, with no structure or object inheritance implied 🌈

IWPS client applications SHOULD use the following size recommendations as the maximum sizes of the attributes. Applications SHOULD still be able to handle attributes of arbitrary size, though, since a server MAY not follow these recommendations. All size recommendations are in characters.

Note: Lots of characters in lots of encodings take up more than one byte, so the size recommendations can't be read as sizes in bytes. Don't mix them up! 🙈

this set of attributes describes information types. They are not defined attributes in any particular schema. Any technology deploying a White Pages service (WHOIS ++, LDAP, vCard, etc.) will need to publish a companion document with its specific schema, showing how the general attributes of the White Pages schema are expressed 💖

SPECIAL CONSIDERATIONS ✨

Phone number: the full international form is RECOMMENDED, like +1 206 703 0852. The field MAY contain additional information after the phone number. For example:

+1 800 759 7243 #123456
+1 505 882 8080 ext. 30852

Email address: is multivalued.

Certificate: is multivalued.

Common Name: is multivalued.

Language Spoken: is multivalued.

THE INFORMATION OBJECT TEMPLATE FOR THE IWPS PERSON 🧚

--General Attributes --

      Field Name             Size         Syntax

      Email                   360         Mailbox
      Cert                   4000         Certificate
      Home Page               128         URI
      Common Name              64         WhitepageString
      Given Name               48         WhitepageString
      Surname                  48         WhitepageString
      Organization             64         WhitepageString
      Locality                 20         WhitepageString
      Country                   2         WhitepageString (ISO 3166)
      Language Spoken         128         WhitepageString (RFC 1766)

--Personal Attributes

      Personal Phone           30         PrintableString
      Personal Fax             30         PrintableString
      Personal Mobile Phone    30         PrintableString
      Personal Pager Number    30         PrintableString
      Personal Postal Address 255         Address
      Description             255         WhitepageString

--Organizational Attributes

      Title                    64         WhitepageString
      Office Phone             30         PrintableString
      Office Fax               30         PrintableString
      Office Mobile Phone      30         PrintableString
      Office Pager             30         PrintableString
      Office Postal Address   255         Address

--Ancillary

      Creation Date            24         GeneralizedTime
      Creator Name            255         URI
      Modified Date            24         GeneralizedTime
      Modifier Name           255         URI

---

6.0 IWPS Person Information Object Template Syntax 🦋

this section defines the syntax the IWPS person information object template uses. It's copied in full from the LDAP attribute working document, with a few tweaks for completeness 💜

Certificate: the certificate field is meant to hold any kind of certificate, and X.509 certificates are one example. A specific implementation will say how to indicate the certificate type when it maps the IWPS schema onto its own implementation schema 🎀

WhitepageString: this syntax MUST be able to encode arbitrary ISO 10646 characters. One such encoding is the UTF-8 encoding [UTF-8] 🌸

GeneralizedTime: values of this syntax are encoded as printable strings, represented as specified in X.208. Note that the time zone MUST be specified. It is strongly RECOMMENDED that the Zulu time zone be used. For example:

199412161032Z

Mailbox: there are many kinds of mailbox addresses, including X.400 and Internet mailbox addresses. The implementation MUST clearly distinguish between the different types of mailbox address, for instance by using a textual prefix or a set of attribute types. There MUST be a way to represent any mailbox type 📬

Address: according to Universal Postal Union standards, this field MUST be able to represent at least 6 lines of 40 characters 🏤

PrintableString: the encoding of a value with PrintableString syntax is the string value itself. PrintableString is limited to the characters in production <p>, which is described by the following:

<a> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' |
        'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' |
        's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' |
        'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' |
        'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' |
        'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z'

<d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'


<p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
        '/' | ':' | '?' | ' '

7.0 Publication of IWPS Information Object Templates. 📣

the Working Group recommends that all information object templates used for the IWPS be published.

Individual organizations MAY define information object templates that are local in scope, as needed to meet local organizational needs. All information that the organization wants to be part of the IWPS MUST use a published IWPS information object template 🌷

8.0 Data Privacy 🔒

each country, and each state within the US, has legislation defining information privacy. The suggested attributes in Section 5.0 MAY be considered private, and the directory administrator is strongly advised to check the privacy legislation for his domain 🕵️

As suggested in "Privacy and Accuracy in NIC Databases" [RFC-1355], each directory provider SHOULD provide a clear statement of the purpose of the directory, the information that should be contained in it, and a privacy policy associated with that information. This policy SHOULD include restrictions for data dissemination 💖

This policy is strongly RECOMMENDED for the US and Canada and REQUIRED by many countries in the European Community for data sharing. 🌈✨

9.0. Data Integrity 🎀

okay so bestie, this is the part where we talk about whether the info is actually TRUE 💅 and honestly it's giving responsibility. Back in RFC 1107 [KS89] there's this iconic line that says "a White Pages service will not be used, if the information it provides is out of date or incorrect." 😭 So any production IWPS provider MUST make sure all the data is reasonably correct and up-to-date. no cap, that's the whole vibe 💖

The Ancillary Attributes of the IWPS person template are the receipts 🧾✨ They tell you where the information came from, when it was first made, and when it was last changed. So the user gets a little measurement of how trustworthy the data is, and it's super easy to figure out who owns it and how fresh it is. main character energy for data 🦋

The IWPS User Agent MUST be able to retrieve and display Ancillary Attributes. It's totally fine to do the retrieving and the displaying as separate steps 🌸

The Ancillary Attributes are RECOMMENDED as the minimum set of attributes for any new information object template. Each IWPS server MAY individually decide whether it wants to support storing and retrieving this data. it's a server choice, periodt 💜

The Ancillary Attributes (which are also defined in Section 5.0) tell you these four things about the information object they're attached to 🫶

1. The date and time the entry was created; Creation Date.
2. Owner or individual responsible for the data creation; Creator Name.
3. The date and time of the last modification; Modified Date.
4. Individual responsible for the last modification; Modifier Name.

---

10.0. Security Considerations 🔥

okay this one is serious, so listen up 🙈 Security is implementation and deployment specific, which is why this memo doesn't cover it. BUT security MUST make sure the constraints from the Data Privacy Section 8.0 are followed. no skipping that, bestie 💀

---

11.0. References 📚

[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., and C. Anderson, "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.

[RFC-1355] Curran, J., and A. Marine, "Privacy and Accuracy Issues in Network Information Center Databases", FYI 15, RFC 1355, August 1992.

[UCS] Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646-1, 1993.

[RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.

[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", Work in Progress.

---

11.0. Authors' Addresses 🌈

Tony Genovese The Microsoft Corporation One Microsoft Way Redmond, Washington 98007 USA

Phone: (206) 703-0852 EMail: TonyG@Microsoft.com

Barbara Jennings Sandia National Laboratories Albuquerque, New Mexico 87106 USA

Phone: (505) 845-8554 EMail: jennings@sandia.gov