home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / ldapsdk.zip / doc / rfc / rfc2218.txt < prev    next >
Text File  |  1998-10-28  |  16KB  |  452 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       T. Genovese
  8. Request for Comments: 2218                                    Microsoft
  9. Category: Standards Track                                   B. Jennings
  10.                                              Sandia National Laboratory
  11.                                                            October 1997
  12.  
  13.  
  14.           A Common Schema for the Internet White Pages Service
  15.  
  16.  
  17. Status of this Memo
  18.  
  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.
  24.  
  25. Abstract
  26.  
  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
  32.    service.
  33.  
  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
  39.    service.
  40.  
  41. 1.0     Introduction to IWPS
  42.  
  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
  48.    person.
  49.  
  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
  54.    service.
  55.  
  56.  
  57.  
  58. Genovese & Jennings        Standards Track                      [Page 1]
  59.  
  60. RFC 2218                 Common Schema for IWPS             October 1997
  61.  
  62.  
  63.    This document will focus only on common information modeling issues
  64.    to which all IWPS providers must conform.
  65.  
  66. 2.0     Scope
  67.  
  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
  73.    the IWPS.
  74.  
  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
  78.    conformance".
  79.  
  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.
  85.  
  86.    This document does not specify a Directory access protocol (i.e.
  87.    whois++, LDAP, DAP, etc.).
  88.  
  89. 3.0     IWPS Schema Considerations
  90.  
  91.    The description of the IWPS information object consists of the
  92.    following requirements:
  93.  
  94.               1. Syntax for definition/representation of information
  95.                  object templates.
  96.               2. Publication of information object templates, etc.
  97.               3. Database structure or schema.
  98.  
  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.
  103.  
  104. 4.0     Syntax for Definition/Representation of Information Object
  105.         Templates
  106.  
  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,
  111.  
  112.  
  113.  
  114. Genovese & Jennings        Standards Track                      [Page 2]
  115.  
  116. RFC 2218                 Common Schema for IWPS             October 1997
  117.  
  118.  
  119.    some syntax are listed as requirements vs specific encodings.  The
  120.    general IWPS syntax is included in section 6.0 for reference.
  121.  
  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.
  126.  
  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.
  130.  
  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].
  134.  
  135. 5.0     Information Object Template Definitions
  136.  
  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.
  140.  
  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.
  146.  
  147.    Note: Because many characters in many encodings require more than one
  148.    byte, the size recommendations cannot be interpreted as sizes in
  149.    bytes.
  150.  
  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.
  156.  
  157.    SPECIAL CONSIDERATIONS
  158.  
  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
  162.                   number.  For example:
  163.  
  164.                            +1 800 759 7243 #123456
  165.                            +1 505 882 8080 ext. 30852
  166.  
  167.  
  168.  
  169.  
  170. Genovese & Jennings        Standards Track                      [Page 3]
  171.  
  172. RFC 2218                 Common Schema for IWPS             October 1997
  173.  
  174.  
  175.    Email address: Is multivalued.
  176.  
  177.    Certificate:   Is multivalued.
  178.  
  179.    Common Name:   Is multivalued.
  180.  
  181.    Language Spoken:  Is multivalued.
  182.  
  183.    THE INFORMATION OBJECT TEMPLATE FOR THE IWPS PERSON
  184.  
  185.    --General Attributes --
  186.  
  187.          Field Name             Size         Syntax
  188.  
  189.          Email                   360         Mailbox
  190.          Cert                   4000         Certificate
  191.          Home Page               128         URI
  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)
  199.  
  200.    --Personal Attributes
  201.  
  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
  208.  
  209.    --Organizational Attributes
  210.  
  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
  217.  
  218.    --Ancillary
  219.  
  220.          Creation Date            24         GeneralizedTime
  221.          Creator Name            255         URI
  222.          Modified Date            24         GeneralizedTime
  223.  
  224.  
  225.  
  226. Genovese & Jennings        Standards Track                      [Page 4]
  227.  
  228. RFC 2218                 Common Schema for IWPS             October 1997
  229.  
  230.  
  231.          Modifier Name           255         URI
  232.  
  233. 6.0     IWPS Person Information Object Template Syntax
  234.  
  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.
  238.  
  239.    Certificate:
  240.  
  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.
  245.  
  246.    WhitepageString:
  247.  
  248.       This syntax must be able to encode arbitrary ISO 10646 characters.
  249.       One such encoding is the UTF-8 encoding [UTF-8].
  250.  
  251.    GeneralizedTime:
  252.  
  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
  256.       used.  For example:
  257.  
  258.                                 199412161032Z
  259.  
  260.    Mailbox:
  261.  
  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.
  267.  
  268.    Address:
  269.  
  270.       According to Universal Postal Union standards, this field must be
  271.       able to represent at least 6 lines of 40 characters.
  272.  
  273.    PrintableString:
  274.  
  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
  278.       following:
  279.  
  280.  
  281.  
  282. Genovese & Jennings        Standards Track                      [Page 5]
  283.  
  284. RFC 2218                 Common Schema for IWPS             October 1997
  285.  
  286.  
  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'
  293.  
  294.       <d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
  295.  
  296.  
  297.       <p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
  298.               '/' | ':' | '?' | ' '
  299.  
  300. 7.0     Publication of IWPS Information Object Templates.
  301.  
  302.    The Working Group recommends that all information object templates
  303.    used for the IWPS be published.
  304.  
  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.
  309.  
  310. 8.0     Data Privacy
  311.  
  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.
  316.  
  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.
  322.  
  323.    This policy is strongly recommended for the US and Canada and
  324.    required by many countries in the European Community for data
  325.    sharing.
  326.  
  327. 9.0     Data Integrity
  328.  
  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
  333.    up-to-date.
  334.  
  335.  
  336.  
  337.  
  338. Genovese & Jennings        Standards Track                      [Page 6]
  339.  
  340. RFC 2218                 Common Schema for IWPS             October 1997
  341.  
  342.  
  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.
  348.  
  349.    The IWPS User Agent must be able to retrieve and display Ancillary
  350.    Attributes.  Retrieval and display may be done as separate
  351.    operations.
  352.  
  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
  356.    of this data.
  357.  
  358.    The Ancillary Attributes (also defined in Section 5.0) provide the
  359.    following information about its associated information object:
  360.  
  361.       1.  The date and time the entry was created; Creation Date.
  362.  
  363.       2.  Owner or individual responsible for the data creation;
  364.           Creator Name.
  365.  
  366.       3.  The date and time of the last modification;
  367.           Modified Date.
  368.  
  369.       4.  Individual responsible for the last modification;
  370.           Modifier Name.
  371.  
  372. 10.0    Security Considerations
  373.  
  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.
  377.  
  378. 11.0     References
  379.  
  380.    [KS89]  Sollins, K., "A Plan for Internet Directory Services", RFC
  381.    1107, Laboratory for Computer Science, MIT, July 1989.
  382.  
  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.
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Genovese & Jennings        Standards Track                      [Page 7]
  395.  
  396. RFC 2218                 Common Schema for IWPS             October 1997
  397.  
  398.  
  399.    [PA94] Postel, J., and C. Anderson, "WHITE PAGES MEETING REPORT",
  400.    RFC 1588, University of Southern California, February 1994.
  401.  
  402.    [RFC-822] Crocker, D., "Standard for the Format of  ARPA  Internet
  403.    Text Messages", STD 11, RFC 822, August 1982.
  404.  
  405.    [RFC-1355] Curran, J., and A. Marine, "Privacy and Accuracy Issues
  406.    in Network Information Center Databases", FYI 15, RFC 1355, August
  407.    1992.
  408.  
  409.    [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
  410.    Architecture and Basic Multilingual Plane, ISO/IEC 10646-1, 1993.
  411.  
  412.    [RFC-1766] Alvestrand, H., "Tags for the Identification of
  413.    Languages", RFC 1766, March 1995.
  414.  
  415.    [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
  416.    Work in Progress.
  417.  
  418. 11.0     Authors' Addresses
  419.  
  420.    Tony Genovese
  421.    The Microsoft Corporation
  422.    One Microsoft Way
  423.    Redmond, Washington 98007
  424.    USA
  425.  
  426.    Phone: (206) 703-0852
  427.    EMail: TonyG@Microsoft.com
  428.  
  429.  
  430.    Barbara Jennings
  431.    Sandia National Laboratories
  432.    Albuquerque, New Mexico 87106
  433.    USA
  434.  
  435.    Phone:  (505) 845-8554
  436.    EMail:  jennings@sandia.gov
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Genovese & Jennings        Standards Track                      [Page 8]
  451.  
  452.