[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 rfc2218                                  
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


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
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

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
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.
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
Each country has its own set of laws and practices.  The best work
this area was done by NADF [NADF92].  It makes recommendations for the

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
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

3.2 Publishing of IWPS Information object Templates.

The Working Group recommends publication of all information object
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

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
recommended that any new information object Template include as a
the Ancillary attributes as an optional set of attributes.  It would
be left to the IWPS servers to optionally support the storage and
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

   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
no structure or object inheritance is implied.  All size recommendations
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


      Password           64           Password


      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]