idnits 2.17.1 draft-ietf-ids-iwps-schema-spec-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 378 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 51 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (5 June 1997) is 9821 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UTF-8' is mentioned on line 215, but not defined == Missing Reference: 'RFC 1355' is mentioned on line 275, but not defined == Unused Reference: 'Davis' is defined on line 326, but no explicit reference was found in the text == Unused Reference: 'RFC-1355' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'UCS' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'RFC 1766' is defined on line 347, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Davis' ** Downref: Normative reference to an Informational RFC: RFC 1107 (ref. 'KS89') ** Obsolete normative reference: RFC 1295 (ref. 'NADF92') (Obsoleted by RFC 1417) ** Downref: Normative reference to an Informational RFC: RFC 1588 (ref. 'PA94') ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 1355 -- Possible downref: Non-RFC (?) normative reference: ref. 'UCS' ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) Summary: 16 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 3 T. Genovese 4 Microsoft 6 Barbara Jennings 7 Sandia National Laboratory 9 5 June 1997 10 Expires: 4 December 1997 12 A Common Schema for the Internet White Pages Service 13 File Name: draft-ietf-ids-iwps-schema-spec-06.txt 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts 29 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 30 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 32 Abstract 34 This work is the result of the IETF Integrated Directory Services (IDS) 35 Working Group. The IDS Working Group proposes a standard specification 36 for a simple Internet White Pages service by defining a common schema for 37 use by the various White Pages servers. This schema is independent of 38 specific implementations of the White Pages service. 40 This document specifies the minimum set of core attributes of a White Pages 41 entry for an individual and describes how new objects with those attributes 42 can be defined and published. It does not describe how to represent other 43 objects in the White Pages service. Further, it does not address the search 44 sort expectations within a particular service. 46 1.0 Introduction to IWPS 48 The Internet community has stated a need for the development and deployment 49 of a White Pages service for use in locating information about people in the 50 Internet [PA94]. To facilitate interoperability and to provide a common user 51 experience, the Internet White Pages Service (IWPS) must have a common set 52 of information about each person. 54 A common user object would allow a user to go between implementations of 55 the service and to expect consistency in the types of information provided. 56 A common user object would also provide developers with an unambigious 57 method of representing the information managed by the service. 59 This document will focus only on common information modeling issues to 60 which all IWPS providers must conform. 62 2.0 Scope 64 This document establishes the set of attributes that specify the Common 65 User Information Object for the IWPS. It does not attempt to be an 66 exhaustive specification of all objects that may be stored in the IWPS. 67 The process used by this document to define the user object is recommended 68 to be used to define other information objects used in the IWPS. 70 All conforming implementations must support at the minimum, the core attributes 71 listed in Section 5.0. Implementations may include local attributes in addition 72 to the core set and still be considered "in conformance". 74 This document will not specify rules with respect to information privacy. 75 Each country has its own set of laws and practices. Previous work covering 76 this area has been done by the North American Directory Forum (NADF), whose 77 publication [NADF92] contain recommendations for registrants' rights in both the 78 USA and Canada. 80 This document does not specify a Directory access protocol (i.e. whois++, 81 LDAP, DAP, etc.). 83 3.0 IWPS Schema Considerations 85 The description of the IWPS information object consists of the following 86 requirements: 88 1. Syntax for definition/representation of information 89 object templates. 90 2. Publication of information object templates, etc. 91 3. Database structure or schema. 93 Items 1 and 2 will be covered in this document. Because database structure 94 can potentially restrict implementations (i.e. X.500 schema based versus 95 DNS schema based) it will be treated as a separate research topic and will 96 not be defined in this paper. 98 4.0 Syntax for Definition/Representation of Information Object Templates 100 A clear, precise, and consistent method must be used when discussing information 101 object templates and their associated attributes. Therefore, this document makes 102 uses of the previously defined syntax used by LDAP. To avoid restrictions on 103 implementations of the IWPS, some syntax are listed as requirements vs 104 specific encodings. The general IWPS syntax is included in section 6.0 for 105 reference. 107 The IWPS Person Object specifies a limited set of recommended attributes that 108 a White Pages Service must include. Storage of user attributes are a local 109 issue, therefore, this draft suggest storage sizes but not storage types. 111 This document lists the syntax with the attributes for developers of user 112 interface (UIs) to use as a reference, but it does not specify how the UI 113 should display these attributes. 115 Attributes that contain multiple-line text (i.e. Address) must use the 116 procedure defined in RFC 822 in section 3.1.1 on "folding" long header lines 117 [RFC-822]. 119 5.0 Information Object Template Definitions 121 This section describes the IWPS Person Information Object Template 122 and its associated attributes. The Person Object is a simple list of 123 attributes, no structure nor object inheritance is implied. 125 IWPS client applications should use the following size recommendations as the 126 maximum sizes of the attributes. However, applications should be able to 127 handle attributes of arbitrary size, returned by a server which may not comply 128 with these recommendation. All size recommendations are in characters. 130 Note: Multi-byte languages will require larger storage allocation to achieve 131 the character size recommendation. 133 This set of attributes describes information types, and are not defined 134 attributes in a particular schema. Any technology deploying a White Page 135 service ( WHOIS ++, LDAP, vCard, etc.) will need to publish as a companion 136 document, their specific schema detailing how the general attributes of the 137 White Pages schema are expressed. 139 SPECIAL CONSIDERATIONS 141 Phone number: The full international form is recommended; 142 i.e. +1 206 703 0852. The field may contain 143 additional information following the phone 144 number. For example: 146 +1 800 759 7243 #123456 147 +1 505 882 8080 ext. 30852 149 Email address: Is multivalued. 151 Certificate: Is multivalued. 153 Common Name: Is multivalued. 155 Language Spoken: Is multivalued. 157 THE INFORMATION OBJECT TEMPLATE FOR THE IWPS PERSON 159 --General Attributes -- 161 Field Name Size Syntax 163 Email 360 Mailbox 164 Cert 4000 Certificate 165 Home Page 128 URI 166 Common Name 64 WhitepageString 167 Given Name 48 WhitepageString 168 Surname 48 WhitepageString 169 Organization 64 WhitepageString 170 Locality 20 WhitepageString 171 Country 2 WhitepageString (ISO 3166) 172 Language Spoken 128 WhitepageString (RFC 1766) 174 --Personal Attributes 176 Personal Phone 30 PrintableString 177 Personal Fax 30 PrintableString 178 Personal Mobile Phone 30 PrintableString 179 Personal Pager Number 30 PrintableString 180 Personal Postal Address 255 Address 181 Description 255 WhitepageString 183 --Organizational Attributes 185 Title 64 WhitepageString 186 Office Phone 30 PrintableString 187 Office Fax 30 PrintableString 188 Office Mobile Phone 30 PrintableString 189 Office Pager 30 PrintableString 190 Office Postal Address 255 Address 192 --Ancillary 194 Creation Date 24 GeneralizedTime 195 Creator Name 255 URI 196 Modified Date 24 GeneralizedTime 197 Modifier Name 255 URI 199 6.0 IWPS Person Information Object Template Syntax 201 This section defines the syntax used by the IWPS person information object 202 template. It is copied in whole from the LDAP attribute working document with 203 some modification for completeness. 205 Certificate: 207 The certificate field is intended to hold any kind of certificate; 208 X.509 certificates are one example. A specific implementation will 209 specify how to indicate the type of certificate when describing the 210 mapping of the IWPS schema onto the implementation schema. 212 WhitepageString: 214 This syntax must be able to encode arbitrary ISO 10646 characters. 215 One such encoding is the UTF-8 encoding [UTF-8]. 217 GeneralizedTime: 219 Values of this syntax are encoded as printable strings, represented 220 as specified in X.208. Note that the time zone must be specified. 221 It is strongly recommended that Zulu time zone be used. For example: 223 199412161032Z 225 Mailbox: 227 There are many kinds of mailbox addresses, including X.400 and Internet 228 mailbox addresses. The implementation must clearly distinguish between 229 different types of mailbox address, for instance by using a textual 230 prefix or a set of attribute types. There must be a way to represent 231 any mailbox type. 233 Address: 235 According to Universal Postal Union standards, this field must be 236 able to represent at least 6 lines of 40 characters. 238 PrintableString: 240 The encoding of a value with PrintableString syntax is the string 241 value itself. PrintableString is limited to the characters in 242 production

. Where production

is described by the following: 244 ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | 245 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | 246 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' | 247 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | 248 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | 249 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z' 251 ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' 253

::= | | ''' | '(' | ')' | '+' | ',' | '-' | '.' | 254 '/' | ':' | '?' | ' ' 256 7.0 Publication of IWPS Information Object Templates. 258 The Working Group recommends that all information object templates 259 used for the IWPS be published as an RFC at the minimum. To facilitate 260 distribution, these publications should be made available on an Internet 261 information server (i.e. InterNIC). 263 Individual organizations may define information object templates that 264 are local in scope as required to meet local organizational needs. All 265 information that the organization wishes to be part of the IWPS must use a 266 published IWPS information object template. 268 8.0 Data Privacy 270 Each country, and each state within the US, has legislation defining 271 information privacy. The suggested attributes in Section 5.0 may be 272 considered private and the directory administrator is strongly advised 273 to verify the privacy legislation for his domain. 275 As suggested in "Privacy and Accuracy in NIC Databases" [RFC 1355], each 276 directory provider should provide a clear statement of the purpose of the 277 directory, the information that should be contained in it, and a privacy 278 policy associated with that information. This policy should include 279 restrictions for data dissemination. 281 This policy is strongly recommended for the US and Canada and required 282 by many countries in the European Community for data sharing. 284 9.0 Data Integrity 286 Data Integrity was first addressed in RFC1107 [KS89], which states "a 287 White Pages service will not be used, if the information it provides is 288 out of date or incorrect." Therefore, any production IWPS provider must 289 insure that all data is reasonably correct and up-to-date. 291 The Ancillary Attributes of the IWPS person template denote the 292 information's source and date of origin, and the source and date of its 293 latest modification. They provide the user with some measurement of the 294 quality of data making it easy to determine the owner and freshness of the 295 data retrieved. 297 The IWPS User Agent must be able to retrieve and display Ancillary 298 Attributes. Retrieval and display may be done as separate operations. 300 The Ancillary Attributes are recommended as the minimum set of attributes for 301 any new information object template. Each IWPS server may individually decide 302 whether to support the storage and retrieval of this data. 304 The Ancillary Attributes (also defined in Section 5.0) provide the following 305 information about its associated information object: 307 1. The date and time the entry was created; Creation Date. 309 2. Owner or individual responsible for the data creation; 310 Creator Name. 312 3. The date and time of the last modification; 313 Modified Date. 315 4. Individual responsible for the last modification; 316 Modifier Name. 318 10.0 Security Considerations 320 Security is implementation and deployment specific and as such is not 321 addressed in this memo. Security must ensure that the constraints mentioned 322 in the Data Privacy Section 8.0 are complied with. 324 11.0 References 326 [Davis] Davis, M., UTF-8, (WG2 N1036) DAM for ISO/IEC 10646-1. 328 [KS89] Sollins, K., "A Plan for Internet Directory Services", RFC 329 1107, Laboratory for Computer Science, MIT, July 1989. 331 [NADF92] North American Directory Forum, "User Bill of Rights for 332 entries and listings in the Public Directory', RFC 1295, 333 North American Directory Forum, January 1992. 335 [PA94] Postel, J., Anderson, C., "WHITE PAGES MEETING REPORT", RFC 336 1588, University of Southern California, February 1994. 338 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet 339 Text Messages", STD 11, RFC 822, August 1982. 341 [RFC-1355] Curran, J., Marine, A., "Privacy and Accuracy Issues in Network 342 Information Center Databases", FYI 15, RFC 1355, August 1992. 344 [UCS] Universal Multiple-Octet Coded Character Set (UCS) - Architecture 345 and Basic Multilingual Plane, ISO/IEC 10646-1, 1993. 347 [RFC 1766] Alvestrand, H. "Tags for the Identification of Languages", 348 RFC 1766, March 1995. 350 11.0 Authors' Address 352 Tony Genovese 353 The Microsoft Corporation 354 One Microsoft Way 355 Redmond, Washington 98007 356 USA 358 Phone: (206) 703-0852 359 EMail: TonyG@Microsoft.com 361 Barbara Jennings 362 Sandia National Laboratories 363 Albuquerque, New Mexico 87106 364 USA 366 Phone: (505) 845-8554 367 EMail: jennings@sandia.gov 369 Expires: 10 October 1997