rfc2218.txt

RFC 的详细文档！


RFC 2218                 Common Schema for IWPS             October 1997


         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:

      The certificate field is intended to hold any kind of certificate;
      X.509 certificates are one example. A specific implementation will
      specify how to indicate the type of certificate when describing
      the mapping of the IWPS schema onto the 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 Zulu time zone be
      used.  For example:

                                199412161032Z

   Mailbox:

      here are many kinds of mailbox addresses, including X.400 and
      Internet mailbox addresses. The implementation must clearly
      distinguish between different types of mailbox address, for
      instance by using a textual refix 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>. Where production <p> is described by the
      following:



Genovese & Jennings        Standards Track                      [Page 5]

RFC 2218                 Common Schema for IWPS             October 1997


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




Genovese & Jennings        Standards Track                      [Page 6]

RFC 2218                 Common Schema for IWPS             October 1997


   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

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








Genovese & Jennings        Standards Track                      [Page 7]

RFC 2218                 Common Schema for IWPS             October 1997


   [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: [phone]
   EMail: [e-mail]


   Barbara Jennings
   Sandia National Laboratories
   Albuquerque, New Mexico 87106
   USA

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













Genovese & Jennings        Standards Track                      [Page 8]