Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_i/draft-ietf-ids-iwps-schema-spec-05.txt

Text File | 1997-04-28 | 17KB | 417 lines

INTERNET-DRAFT

                                                      T. Genovese
                                                        Microsoft

                                                 Barbara Jennings
                                       Sandia National Laboratory


                                                    18 April 1997
                                      Expires:    10 October 1997


      A Common Schema for the Internet White Pages Service
      File Name: draft-ietf-ids-iwps-schema-spec-05.txt

Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its 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).

Abstract

This work is the result of the IETF Integrated Directory Services (IDS)
Working Group.  The IDS Working Group proposes a standard specification
for a simple Internet White Pages service by defining a common schema for
use by the various White Pages servers.  This schema is independent of
specific implementations of the White Pages service.

This document specifies the minimum set of core attributes of a White Pages
entry for an individual and describes how new objects with those attributes
can be defined and published.  It does not describe how to represent other
objects in the White Pages service.  Further, it does not address the search
sort expectations within a particular service.

1.0     Introduction to IWPS

The Internet community has stated a need for the development and deployment
of a White Pages service for use in locating information about people in the
Internet [PA94].  To facilitate interoperability and to provide a common user
experience, the Internet White Pages Service (IWPS) must have a common set
of information about each person.

A common user object would allow a user to go between implementations of
the service and to expect consistency in the types of information provided.
A common user object would also provide developers with an unambigious
method of representing the information managed by the service.

This document will focus only on common information modeling issues to
which all IWPS providers must conform.

2.0     Scope

This document establishes the set of attributes that specify the Common
User Information Object for the IWPS.  It does not attempt to be an
exhaustive specification of all objects that may be stored in the IWPS.
The process used by this document to define the user object is recommended
to be used to define 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 in addition
to the core set and still be considered "in conformance".

This document will not specify rules with respect to information privacy.
Each country has its own set of laws and practices.  Previous work covering
this area has been done by the North American Directory Forum (NADF), whose
publication [NADF92] contain 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 description of the IWPS information object consists of 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 will be covered in this document.  Because database structure
can potentially restrict implementations (i.e. X.500 schema based versus
DNS schema based) it will be treated as a separate research topic and will
not be defined in this paper.

4.0     Syntax for Definition/Representation of Information Object Templates

A clear, precise, and consistent method must be used when discussing information
object templates and their associated attributes are discussed within the
context of IWPS. Therefore, this document uses the previously defined syntax
used by LDAP.  The syntax is included in section 6.0 for reference.

The IWPS Person Object specifies a limited set of recommended attributes that
a White Pages Service should include.  For instance, storage of user attributes
is a local issue, therefore, this draft suggest storage sizes but not storage
types.

This document lists the syntax with the attributes for developers of user
interface (UIs) to use as a reference, but it does not specify how the UI
should display these attributes.

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

5.0     Information Object Template Definitions

This section describes the IWPS Person Information Object Template
and its associated attributes.  The Person Object is a simple list of
attributes, no structure nor object inheritance is implied.

IWPS client applications should use the following size recommendations as the
maximum sizes of the attributes.  However, applications should be able to
handle attributes of arbitrary size, returned by a server which may not comply
with these recommendation.  All size recommendations are in characters.

Note: Multi-byte languages will require larger storage allocation to achieve
the character size recommendation.

This set of attributes describes information types, and are not defined
attributes in a particular schema.  Any technology deploying a White Page
service ( WHOIS ++, LDAP, vCard, etc.) will need to publish as a companion
document, their specific schema detailing how the general attributes of the
White Pages schema are expressed.

SPECIAL CONSIDERATIONS

Phone number:  The full international form is recommended;
               i.e. [phone].  The field may contain
               additional information following the phone
               number.  For example:

                        [phone] #123456
                        [phone] ext. 30852

Email address: Is multivalued and uses the otherMailbox syntax
               to identify the different email addresses.

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          otherMailbox
      Cert                   4000          Certificate
      Home Page               128          URI
      Common Name              64          DirectoryString
      Given Name               48          DirectoryString
      Surname                  48          DirectoryString
      Organization             64          DirectoryString
      Locality                 20          DirectoryString
      Country                   2          DirectoryString (ISO 3166)
      Language Spoken         128          DirectoryString (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         PostalAddress
      Description             255         DirectoryString

--Organizational Attributes

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

--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 used by the IWPS person information object
template.  It is copied in whole from the LDAP attribute working document with
some modification for completeness.

Certificate:

   Due to differences from version X.509(1988) and X.509(1993) and additional
   changes to support Certificate extensions, no string representation is
   defined. Values with Certificate syntax must only be transferred using
   the binary encoding, by requesting or returning the attributes with
   descriptions "userCertificate;binary" or "caCertificate;binary".

DirectoryString:

   A string with DirectoryString syntax is encoded in the UTF-8 form of
   ISO 10646 (a superset of Unicode).  Servers and clients must be prepared to
   receive arbitrary Unicode characters in values.

   For characters in the PrintableString form, the value is encoded as the
   string value itself.

   If it is of the TeletexString form, then the characters are transliterated
   to their equivalents in UniversalString, and encoded in UTF-8 [Davis].

   If it is of the UniversalString or BMPString forms [UCS], UTF-8 is used to
   encode them.

   Note: the form of DirectoryString is not indicated in protocol unless the
   attribute value is carried in binary.  Servers which convert to DAP must
   choose an appropriate form.  Servers must not reject values merely because
   they contain legal Unicode characters outside of the range of printable
   ASCII.

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 Zulu time zone be used.  For example:

                199412161032Z

OtherMailbox:

   Values of the OtherMailbox syntax are encoded according to the
   following:

      <otherMailbox> ::= <mailbox-type> '$' <mailbox>

      <mailbox-type> ::= an encoded Printable String

      <mailbox> ::= an encoded IA5 String

   In the above, <mailbox-type> represents the type of mail system in
   which the mailbox resides, for example "MCIMail"; and <mailbox> is the
   actual mailbox in the mail system defined by <mailbox-type>.

   NB:  Practical experience has shown that developers will commonly use the
        attribute RFC822 address instead of otherMailbox with the value equal:

                   Internet$[e-mail].

PostalAddress:

   Values with the PostalAddress syntax are encoded according to the
   following:

      <postal-address> ::= <dstring> | <dstring> '$' <postal-address>

   In the above, each <dstring> component of a postal address value is
   encoded as a value of type DirectoryString syntax.  Backslashes and
   dollar characters, if they occur in the component, are quoted as
   follows:

   A backslash quoting mechanism is used to encode symbol character
   such as ''', '$' or '#'.  The backslash is followed by a pair of
   hexadecimal digits representing the next character.  A backslash
   itself in the string which forms part of a larger syntax is
   always transmitted as '\5C' or '\5c'.

PrintableString:

   The encoding of a value with PrintableString syntax is the string
   value itself.  PrintableString is limited to the characters in
   production <p>. Where production <p> 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 as an RFC at the minimum. To facilitate
distribution, these publications should be made available on an Internet
information server (i.e. InterNIC).

Individual organizations may define information object templates that
are local in scope as required to meet local organizational needs.  All
information that the organization wishes 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 verify 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

Data Integrity was first addressed in RFC1107 [KS89], which states "a
White Pages service will not be used, if the information it provides is
out of date or incorrect."  Therefore, any production IWPS provider must
insure that all data is reasonably correct and up-to-date.

The Ancillary Attributes of the IWPS person template denote the
information's source and date of origin, and the source and date of its
latest modification.  They provide the user with some measurement of the
quality of data making it easy to determine the owner and freshness of the
data retrieved.

The IWPS User Agent must be able to retrieve and display Ancillary
Attributes.  Retrieval and display may be done as separate operations.

The Ancillary Attributes are recommended as the minimum set of attributes for
any new information object template.  Each IWPS server may individually decide
whether to support the storage and retrieval of this data.

The Ancillary Attributes (also defined in Section 5.0) provide the following
information about its associated information object:

              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

Security is implementation and deployment specific and as such is not
addressed in this memo.  Security must ensure that the constraints mentioned
in the Data Privacy Section 8.0 are complied with.

11.0     References

   [Davis] Davis, M., UTF-8, (WG2 N1036) DAM for ISO/IEC 10646-1.

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

   [RFC-1355] Curran, J., Marine, A., "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.

11.0     Authors' Address

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

   Phone: [phone]
   EMail: [e-mail]

   Barbara Jennings
   Sandia National Laboratories
   Albuquerque, New Mexico 87106
   USA

   Phone:  [phone]
   EMail:  [e-mail]

                             Expires: 10 October 1997