idnits 2.17.1 draft-ietf-ids-iwps-schema-spec-05.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-18) 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 417 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 65 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 (18 April 1997) is 9862 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: 'RFC 1355' is mentioned on line 317, but not defined == Unused Reference: 'RFC-1355' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'RFC 1766' is defined on line 389, 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 (~~), 5 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 18 April 1997 10 Expires: 10 October 1997 12 A Common Schema for the Internet White Pages Service 13 File Name: draft-ietf-ids-iwps-schema-spec-05.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 are discussed within the 102 context of IWPS. Therefore, this document uses the previously defined syntax 103 used by LDAP. The syntax is included in section 6.0 for reference. 105 The IWPS Person Object specifies a limited set of recommended attributes that 106 a White Pages Service should include. For instance, storage of user attributes 107 is a local issue, therefore, this draft suggest storage sizes but not storage 108 types. 110 This document lists the syntax with the attributes for developers of user 111 interface (UIs) to use as a reference, but it does not specify how the UI 112 should display these attributes. 114 Attributes that contain multiple-line text (i.e. Postal address) must use the 115 procedure defined in RFC 822 in section 3.1.1 on "folding" long header lines 116 [RFC-822]. 118 5.0 Information Object Template Definitions 120 This section describes the IWPS Person Information Object Template 121 and its associated attributes. The Person Object is a simple list of 122 attributes, no structure nor object inheritance is implied. 124 IWPS client applications should use the following size recommendations as the 125 maximum sizes of the attributes. However, applications should be able to 126 handle attributes of arbitrary size, returned by a server which may not comply 127 with these recommendation. All size recommendations are in characters. 129 Note: Multi-byte languages will require larger storage allocation to achieve 130 the character size recommendation. 132 This set of attributes describes information types, and are not defined 133 attributes in a particular schema. Any technology deploying a White Page 134 service ( WHOIS ++, LDAP, vCard, etc.) will need to publish as a companion 135 document, their specific schema detailing how the general attributes of the 136 White Pages schema are expressed. 138 SPECIAL CONSIDERATIONS 140 Phone number: The full international form is recommended; 141 i.e. +1 206 703 0852. The field may contain 142 additional information following the phone 143 number. For example: 145 +1 800 759 7243 #123456 146 +1 505 882 8080 ext. 30852 148 Email address: Is multivalued and uses the otherMailbox syntax 149 to identify the different email addresses. 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 otherMailbox 164 Cert 4000 Certificate 165 Home Page 128 URI 166 Common Name 64 DirectoryString 167 Given Name 48 DirectoryString 168 Surname 48 DirectoryString 169 Organization 64 DirectoryString 170 Locality 20 DirectoryString 171 Country 2 DirectoryString (ISO 3166) 172 Language Spoken 128 DirectoryString (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 PostalAddress 181 Description 255 DirectoryString 183 --Organizational Attributes 185 Title 64 DirectoryString 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 PostalAddress 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 Due to differences from version X.509(1988) and X.509(1993) and additional 208 changes to support Certificate extensions, no string representation is 209 defined. Values with Certificate syntax must only be transferred using 210 the binary encoding, by requesting or returning the attributes with 211 descriptions "userCertificate;binary" or "caCertificate;binary". 213 DirectoryString: 215 A string with DirectoryString syntax is encoded in the UTF-8 form of 216 ISO 10646 (a superset of Unicode). Servers and clients must be prepared to 217 receive arbitrary Unicode characters in values. 219 For characters in the PrintableString form, the value is encoded as the 220 string value itself. 222 If it is of the TeletexString form, then the characters are transliterated 223 to their equivalents in UniversalString, and encoded in UTF-8 [Davis]. 225 If it is of the UniversalString or BMPString forms [UCS], UTF-8 is used to 226 encode them. 228 Note: the form of DirectoryString is not indicated in protocol unless the 229 attribute value is carried in binary. Servers which convert to DAP must 230 choose an appropriate form. Servers must not reject values merely because 231 they contain legal Unicode characters outside of the range of printable 232 ASCII. 234 GeneralizedTime: 236 Values of this syntax are encoded as printable strings, represented 237 as specified in X.208. Note that the time zone must be specified. 238 It is strongly recommended that Zulu time zone be used. For example: 240 199412161032Z 242 OtherMailbox: 244 Values of the OtherMailbox syntax are encoded according to the 245 following: 247 ::= '$' 249 ::= an encoded Printable String 251 ::= an encoded IA5 String 253 In the above, represents the type of mail system in 254 which the mailbox resides, for example "MCIMail"; and is the 255 actual mailbox in the mail system defined by . 257 NB: Practical experience has shown that developers will commonly use the 258 attribute RFC822 address instead of otherMailbox with the value equal: 260 Internet$foo@bar.com. 262 PostalAddress: 264 Values with the PostalAddress syntax are encoded according to the 265 following: 267 ::= | '$' 269 In the above, each component of a postal address value is 270 encoded as a value of type DirectoryString syntax. Backslashes and 271 dollar characters, if they occur in the component, are quoted as 272 follows: 274 A backslash quoting mechanism is used to encode symbol character 275 such as ''', '$' or '#'. The backslash is followed by a pair of 276 hexadecimal digits representing the next character. A backslash 277 itself in the string which forms part of a larger syntax is 278 always transmitted as '\5C' or '\5c'. 280 PrintableString: 282 The encoding of a value with PrintableString syntax is the string 283 value itself. PrintableString is limited to the characters in 284 production

. Where production

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

::= | | ''' | '(' | ')' | '+' | ',' | '-' | '.' | 296 '/' | ':' | '?' | ' ' 298 7.0 Publication of IWPS Information Object Templates. 300 The Working Group recommends that all information object templates 301 used for the IWPS be published as an RFC at the minimum. To facilitate 302 distribution, these publications should be made available on an Internet 303 information server (i.e. InterNIC). 305 Individual organizations may define information object templates that 306 are local in scope as required to meet local organizational needs. All 307 information that the organization wishes to be part of the IWPS must use a 308 published IWPS information object template. 310 8.0 Data Privacy 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 advised 315 to verify the privacy legislation for his domain. 317 As suggested in "Privacy and Accuracy in NIC Databases" [RFC 1355], each 318 directory provider should provide a clear statement of the purpose of the 319 directory, the information that should be contained in it, and a privacy 320 policy associated with that information. This policy should include 321 restrictions for data dissemination. 323 This policy is strongly recommended for the US and Canada and required 324 by many countries in the European Community for data sharing. 326 9.0 Data Integrity 328 Data Integrity was first addressed in RFC1107 [KS89], which states "a 329 White Pages service will not be used, if the information it provides is 330 out of date or incorrect." Therefore, any production IWPS provider must 331 insure that all data is reasonably correct and up-to-date. 333 The Ancillary Attributes of the IWPS person template denote the 334 information's source and date of origin, and the source and date of its 335 latest modification. They provide the user with some measurement of the 336 quality of data making it easy to determine the owner and freshness of the 337 data retrieved. 339 The IWPS User Agent must be able to retrieve and display Ancillary 340 Attributes. Retrieval and display may be done as separate operations. 342 The Ancillary Attributes are recommended as the minimum set of attributes for 343 any new information object template. Each IWPS server may individually decide 344 whether to support the storage and retrieval of this data. 346 The Ancillary Attributes (also defined in Section 5.0) provide the following 347 information about its associated information object: 349 1. The date and time the entry was created; Creation Date. 351 2. Owner or individual responsible for the data creation; 352 Creator Name. 354 3. The date and time of the last modification; 355 Modified Date. 357 4. Individual responsible for the last modification; 358 Modifier Name. 360 10.0 Security Considerations 362 Security is implementation and deployment specific and as such is not 363 addressed in this memo. Security must ensure that the constraints mentioned 364 in the Data Privacy Section 8.0 are complied with. 366 11.0 References 368 [Davis] Davis, M., UTF-8, (WG2 N1036) DAM for ISO/IEC 10646-1. 370 [KS89] Sollins, K., "A Plan for Internet Directory Services", RFC 371 1107, Laboratory for Computer Science, MIT, July 1989. 373 [NADF92] North American Directory Forum, "User Bill of Rights for 374 entries and listings in the Public Directory', RFC 1295, 375 North American Directory Forum, January 1992. 377 [PA94] Postel, J., Anderson, C., "WHITE PAGES MEETING REPORT", RFC 378 1588, University of Southern California, February 1994. 380 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet 381 Text Messages", STD 11, RFC 822, August 1982. 383 [RFC-1355] Curran, J., Marine, A., "Privacy and Accuracy Issues in Network 384 Information Center Databases", FYI 15, RFC 1355, August 1992. 386 [UCS] Universal Multiple-Octet Coded Character Set (UCS) - Architecture 387 and Basic Multilingual Plane, ISO/IEC 10646-1, 1993. 389 [RFC 1766] Alvestrand, H. "Tags for the Identification of Languages", 390 RFC 1766, March 1995. 392 11.0 Authors' Address 394 Tony Genovese 395 The Microsoft Corporation 396 One Microsoft Way 397 Redmond, Washington 98007 398 USA 400 Phone: (206) 703-0852 401 EMail: TonyG@Microsoft.com 403 Barbara Jennings 404 Sandia National Laboratories 405 Albuquerque, New Mexico 87106 406 USA 408 Phone: (505) 845-8554 409 EMail: jennings@sandia.gov 411 Expires: 10 October 1997