home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ids-iwps-schema-spec-06.txt < prev    next >
Text File  |  1997-06-06  |  15KB  |  379 lines
  1.  
  2. INTERNET-DRAFT
  3.  
  4.                                                       T. Genovese
  5.                                                         Microsoft
  6.  
  7.                                                  Barbara Jennings
  8.                                        Sandia National Laboratory
  9.  
  10.                                                                                                            
  11.                                                       5 June 1997
  12.                                       Expires:    4 December 1997 
  13.  
  14.  
  15.       A Common Schema for the Internet White Pages Service
  16.       File Name: draft-ietf-ids-iwps-schema-spec-06.txt
  17.  
  18. Status of this Memo
  19.  
  20. This document is an Internet-Draft.  Internet-Drafts are working
  21. documents of the Internet Engineering Task Force (IETF), its areas,
  22. and its working groups.  Note that other groups may also distribute
  23. working documents as Internet-Drafts.
  24.  
  25. Internet-Drafts are draft documents valid for a maximum of six months
  26. and may be updated, replaced, or obsoleted by other documents at any
  27. time.  It is inappropriate to use Internet-Drafts as reference
  28. material or to cite them other than as "work in progress".
  29.  
  30. To learn the current status of any Internet-Draft, please check the
  31. "1id-abstracts.txt" listing contained in the Internet-Drafts
  32. Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
  33. (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au  (Pacific Rim).
  34.  
  35. Abstract
  36.  
  37. This work is the result of the IETF Integrated Directory Services (IDS) 
  38. Working Group.  The IDS Working Group proposes a standard specification
  39. for a simple Internet White Pages service by defining a common schema for 
  40. use by the various White Pages servers.  This schema is independent of 
  41. specific implementations of the White Pages service.
  42.  
  43. This document specifies the minimum set of core attributes of a White Pages
  44. entry for an individual and describes how new objects with those attributes
  45. can be defined and published.  It does not describe how to represent other 
  46. objects in the White Pages service.  Further, it does not address the search
  47. sort expectations within a particular service. 
  48.  
  49. 1.0     Introduction to IWPS
  50.  
  51. The Internet community has stated a need for the development and deployment 
  52. of a White Pages service for use in locating information about people in the 
  53. Internet [PA94].  To facilitate interoperability and to provide a common user 
  54. experience, the Internet White Pages Service (IWPS) must have a common set 
  55. of information about each person.
  56.  
  57. A common user object would allow a user to go between implementations of
  58. the service and to expect consistency in the types of information provided.
  59. A common user object would also provide developers with an unambigious
  60. method of representing the information managed by the service.
  61.  
  62. This document will focus only on common information modeling issues to 
  63. which all IWPS providers must conform.  
  64.  
  65. 2.0     Scope
  66.  
  67. This document establishes the set of attributes that specify the Common
  68. User Information Object for the IWPS.  It does not attempt to be an 
  69. exhaustive specification of all objects that may be stored in the IWPS. 
  70. The process used by this document to define the user object is recommended
  71. to be used to define other information objects used in the IWPS.
  72.  
  73. All conforming implementations must support at the minimum, the core attributes 
  74. listed in Section 5.0. Implementations may include local attributes in addition
  75. to the core set and still be considered "in conformance".
  76.  
  77. This document will not specify rules with respect to information privacy.
  78. Each country has its own set of laws and practices.  Previous work covering 
  79. this area has been done by the North American Directory Forum (NADF), whose
  80. publication [NADF92] contain recommendations for registrants' rights in both the
  81. USA and Canada.
  82.  
  83. This document does not specify a Directory access protocol (i.e. whois++,
  84. LDAP, DAP, etc.).
  85.  
  86. 3.0     IWPS Schema Considerations
  87.  
  88. The description of the IWPS information object consists of the following 
  89. requirements:
  90.  
  91.               1. Syntax for definition/representation of information
  92.                  object templates.
  93.               2. Publication of information object templates, etc.
  94.               3. Database structure or schema.
  95.  
  96. Items 1 and 2 will be covered in this document.  Because database structure
  97. can potentially restrict implementations (i.e. X.500 schema based versus 
  98. DNS schema based) it will be treated as a separate research topic and will
  99. not be defined in this paper.
  100.  
  101. 4.0     Syntax for Definition/Representation of Information Object Templates
  102.  
  103. A clear, precise, and consistent method must be used when discussing information
  104. object templates and their associated attributes. Therefore, this document makes
  105. uses of the previously defined syntax used by LDAP.  To avoid restrictions on 
  106. implementations of the IWPS, some syntax are listed as requirements vs 
  107. specific encodings.  The general IWPS syntax is included in section 6.0 for 
  108. reference.
  109.  
  110. The IWPS Person Object specifies a limited set of recommended attributes that 
  111. a White Pages Service must include.  Storage of user attributes are a local 
  112. issue, therefore, this draft suggest storage sizes but not storage types.
  113.  
  114. This document lists the syntax with the attributes for developers of user
  115. interface (UIs) to use as a reference, but it does not specify how the UI 
  116. should display these attributes.
  117.  
  118. Attributes that contain multiple-line text (i.e. Address) must use the 
  119. procedure defined in RFC 822 in section 3.1.1 on "folding" long header lines 
  120. [RFC-822].
  121.  
  122. 5.0     Information Object Template Definitions
  123.  
  124. This section describes the IWPS Person Information Object Template 
  125. and its associated attributes.  The Person Object is a simple list of 
  126. attributes, no structure nor object inheritance is implied. 
  127.  
  128. IWPS client applications should use the following size recommendations as the
  129. maximum sizes of the attributes.  However, applications should be able to 
  130. handle attributes of arbitrary size, returned by a server which may not comply
  131. with these recommendation.  All size recommendations are in characters.
  132.  
  133. Note: Multi-byte languages will require larger storage allocation to achieve 
  134. the character size recommendation.  
  135.  
  136. This set of attributes describes information types, and are not defined 
  137. attributes in a particular schema.  Any technology deploying a White Page 
  138. service ( WHOIS ++, LDAP, vCard, etc.) will need to publish as a companion 
  139. document, their specific schema detailing how the general attributes of the 
  140. White Pages schema are expressed.
  141.  
  142. SPECIAL CONSIDERATIONS
  143.  
  144. Phone number:  The full international form is recommended; 
  145.                i.e. +1 206 703 0852.  The field may contain
  146.                additional information following the phone
  147.                number.  For example:
  148.  
  149.                         +1 800 759 7243 #123456 
  150.                         +1 505 882 8080 ext. 30852
  151.  
  152. Email address: Is multivalued.
  153.  
  154. Certificate:   Is multivalued.
  155.  
  156. Common Name:   Is multivalued. 
  157.  
  158. Language Spoken:  Is multivalued.
  159.  
  160. THE INFORMATION OBJECT TEMPLATE FOR THE IWPS PERSON
  161.  
  162. --General Attributes --
  163.  
  164.       Field Name             Size         Syntax
  165.  
  166.       Email                   360         Mailbox
  167.       Cert                   4000         Certificate
  168.       Home Page               128         URI
  169.       Common Name              64         WhitepageString
  170.       Given Name               48         WhitepageString
  171.       Surname                  48         WhitepageString
  172.       Organization             64         WhitepageString
  173.       Locality                 20         WhitepageString
  174.       Country                   2         WhitepageString (ISO 3166)
  175.       Language Spoken         128         WhitepageString (RFC 1766)
  176.  
  177. --Personal Attributes
  178.  
  179.       Personal Phone           30         PrintableString
  180.       Personal Fax             30         PrintableString
  181.       Personal Mobile Phone    30         PrintableString
  182.       Personal Pager Number    30         PrintableString
  183.       Personal Postal Address 255         Address
  184.       Description             255         WhitepageString
  185.   
  186. --Organizational Attributes
  187.  
  188.       Title                    64         WhitepageString
  189.       Office Phone             30         PrintableString
  190.       Office Fax               30         PrintableString
  191.       Office Mobile Phone      30         PrintableString
  192.       Office Pager             30         PrintableString
  193.       Office Postal Address   255         Address
  194.       
  195. --Ancillary
  196.  
  197.       Creation Date            24         GeneralizedTime
  198.       Creator Name            255         URI 
  199.       Modified Date            24         GeneralizedTime 
  200.       Modifier Name           255         URI
  201.  
  202. 6.0     IWPS Person Information Object Template Syntax
  203.  
  204. This section defines the syntax used by the IWPS person information object 
  205. template.  It is copied in whole from the LDAP attribute working document with
  206. some modification for completeness.
  207.  
  208. Certificate:
  209.  
  210.    The certificate field is intended to hold any kind of certificate;
  211.    X.509 certificates are one example. A specific implementation will
  212.    specify how to indicate the type of certificate when describing the
  213.    mapping of the IWPS schema onto the implementation schema.   
  214.  
  215. WhitepageString:
  216.  
  217.    This syntax must be able to encode arbitrary ISO 10646 characters.
  218.    One such encoding is the UTF-8 encoding [UTF-8].
  219.  
  220. GeneralizedTime:
  221.  
  222.    Values of this syntax are encoded as printable strings, represented 
  223.    as specified in X.208.  Note that the time zone must be specified.
  224.    It is strongly recommended that Zulu time zone be used.  For example: 
  225.         
  226.                 199412161032Z
  227.  
  228. Mailbox:
  229.  
  230.   There are many kinds of mailbox addresses, including X.400 and Internet
  231.   mailbox addresses. The implementation must clearly distinguish between
  232.   different types of mailbox address, for instance by using a textual
  233.   prefix or a set of attribute types. There must be a way to represent
  234.   any mailbox type.
  235.  
  236. Address:
  237.  
  238.  
  239.   According to Universal Postal Union standards, this field must be
  240.   able to represent at least 6 lines of 40 characters.
  241.  
  242. PrintableString:
  243.  
  244.    The encoding of a value with PrintableString syntax is the string
  245.    value itself.  PrintableString is limited to the characters in 
  246.    production <p>. Where production <p> is described by the following:
  247.  
  248.      <a> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' |
  249.              'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' |
  250.              's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' |
  251.              'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' |
  252.              'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' |
  253.              'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z'
  254.  
  255.      <d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
  256.  
  257.      
  258.      <p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
  259.              '/' | ':' | '?' | ' '
  260.  
  261. 7.0     Publication of IWPS Information Object Templates.
  262.  
  263. The Working Group recommends that all information object templates
  264. used for the IWPS be published as an RFC at the minimum. To facilitate 
  265. distribution, these publications should be made available on an Internet 
  266. information server (i.e. InterNIC).
  267.  
  268. Individual organizations may define information object templates that
  269. are local in scope as required to meet local organizational needs.  All 
  270. information that the organization wishes to be part of the IWPS must use a 
  271. published IWPS information object template.
  272.  
  273. 8.0     Data Privacy
  274.  
  275. Each country, and each state within the US, has legislation defining
  276. information privacy.  The suggested attributes in Section 5.0 may be
  277. considered private and the directory administrator is strongly advised
  278. to verify the privacy legislation for his domain.
  279.  
  280. As suggested in "Privacy and Accuracy in NIC Databases" [RFC 1355], each 
  281. directory provider should provide a clear statement of the purpose of the
  282. directory, the information that should be contained in it, and a privacy
  283. policy associated with that information.  This policy should include 
  284. restrictions for data dissemination.
  285.  
  286. This policy is strongly recommended for the US and Canada and required 
  287. by many countries in the European Community for data sharing.
  288.  
  289. 9.0     Data Integrity
  290.  
  291. Data Integrity was first addressed in RFC1107 [KS89], which states "a
  292. White Pages service will not be used, if the information it provides is
  293. out of date or incorrect."  Therefore, any production IWPS provider must 
  294. insure that all data is reasonably correct and up-to-date.
  295.  
  296. The Ancillary Attributes of the IWPS person template denote the
  297. information's source and date of origin, and the source and date of its 
  298. latest modification.  They provide the user with some measurement of the 
  299. quality of data making it easy to determine the owner and freshness of the 
  300. data retrieved.
  301.  
  302. The IWPS User Agent must be able to retrieve and display Ancillary
  303. Attributes.  Retrieval and display may be done as separate operations.
  304.  
  305. The Ancillary Attributes are recommended as the minimum set of attributes for
  306. any new information object template.  Each IWPS server may individually decide
  307. whether to support the storage and retrieval of this data.
  308.  
  309. The Ancillary Attributes (also defined in Section 5.0) provide the following
  310. information about its associated information object:
  311.  
  312.               1.  The date and time the entry was created; Creation Date. 
  313.  
  314.               2.  Owner or individual responsible for the data creation;
  315.                   Creator Name. 
  316.  
  317.               3.  The date and time of the last modification; 
  318.                   Modified Date.
  319.  
  320.               4.  Individual responsible for the last modification; 
  321.                   Modifier Name.
  322.  
  323. 10.0    Security Considerations
  324.  
  325. Security is implementation and deployment specific and as such is not
  326. addressed in this memo.  Security must ensure that the constraints mentioned 
  327. in the Data Privacy Section 8.0 are complied with.
  328.  
  329. 11.0     References
  330.  
  331.    [Davis] Davis, M., UTF-8, (WG2 N1036) DAM for ISO/IEC 10646-1.
  332.  
  333.    [KS89]  Sollins, K., "A Plan for Internet Directory Services", RFC
  334.    1107, Laboratory for Computer Science, MIT, July 1989.
  335.  
  336.    [NADF92] North American Directory Forum, "User Bill of Rights for
  337.     entries and listings in the Public Directory', RFC 1295,
  338.     North American Directory Forum, January 1992.
  339.  
  340.    [PA94]  Postel, J., Anderson, C., "WHITE PAGES MEETING REPORT", RFC
  341.    1588, University of Southern California, February 1994.
  342.  
  343.    [RFC-822] Crocker, D., "Standard for the Format of  ARPA  Internet  
  344.     Text Messages", STD 11, RFC 822, August 1982.
  345.  
  346.    [RFC-1355] Curran, J., Marine, A., "Privacy and Accuracy Issues in Network 
  347.    Information Center Databases", FYI 15, RFC 1355, August 1992.
  348.  
  349.    [UCS] Universal Multiple-Octet Coded Character Set (UCS) - Architecture
  350.     and Basic Multilingual Plane, ISO/IEC 10646-1, 1993.
  351.  
  352.    [RFC 1766] Alvestrand, H. "Tags for the Identification of Languages",
  353.     RFC 1766, March 1995.
  354.  
  355. 11.0     Authors' Address
  356.  
  357.    Tony Genovese
  358.    The Microsoft Corporation
  359.    One Microsoft Way
  360.    Redmond, Washington 98007
  361.    USA
  362.  
  363.    Phone: (206) 703-0852
  364.    EMail: TonyG@Microsoft.com
  365.  
  366.    Barbara Jennings
  367.    Sandia National Laboratories
  368.    Albuquerque, New Mexico 87106
  369.    USA
  370.  
  371.    Phone:  (505) 845-8554
  372.    EMail:  jennings@sandia.gov
  373.  
  374.                              Expires: 10 October 1997
  375.  
  376.  
  377.  
  378.  
  379.