idnits 2.17.1 draft-ietf-ids-iwps-schema-spec-04.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 407 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 61 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (05 March 1997) is 9913 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 316, but not defined == Unused Reference: 'RFC-1355' is defined on line 377, 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' Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 4 T. Genovese 5 Microsoft 7 Barbara Jennings 8 Sandia National Laboratory 10 05 March 1997 11 Expires: 10 September 1977 13 A Common Schema for the Internet White Pages Service 14 File Name: draft-ietf-ids-iwps-schema-spec-04.txt 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts 30 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 31 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 33 Abstract 35 This work is the result of the IETF Integrated Directory Services (IDS) 36 Working Group. The IDS Working Group proposes a standard specification 37 for a simple Internet White Pages service by defining a common schema for 38 use by the various White Pages servers. This schema is independent of 39 specific implementations of the White Pages service. 41 This document specifies the minimum set of core attributes of a White Pages 42 entry for an individual and describes how new objects with those attributes 43 can be defined and registered. It does not describe how to represent other 44 objects in the White Pages service. Further, it does not address the search 45 sort expectations within a particular service. 47 1.0 Introduction to IWPS 49 The Internet community has stated a need for the development and deployment 50 of a White Pages service for use in locating information about people in the 51 Internet [PA94]. To facilitate interoperability and to provide a common user 52 experience, the Internet White Pages Service (IWPS) must have a common set 53 of information about each person. 55 A common user object would allow a user to go between implementations of 56 the service and to expect consistency in the types of information provided. 57 A common user objet would also provide developers with an unambigious 58 method of representing the information managed by the service. 60 This document will focus only on common information modeling issues to 61 which all IWPS providers must conform. 63 2.0 Scope 65 This document establishes the set of attributes that specify the Common 66 User Information Object for the IWPS. It does not attempt to be an 67 exhaustive specification of all objects that may be stored in the IWPS. 68 The process used by this document to define the user object will also be 69 used to define all other information objects used in the IWPS. 71 All conforming implementations must support at the minimum, the core attributes 72 listed in Section 5.0. Implementations may include local attributes in addition 73 to the core set and still be considered "in conformance". 75 This document will not specify rules with respect to information privacy. 76 Each country has its own set of laws and practices. Previous work covering 77 this area has been done by the North American Directory Forum (NADF), whose 78 publication [NADF92] contain recommendations for registrants' rights in both the 79 USA and Canada. 81 This document does not specify a Directory access protocol (i.e. whois++, 82 LDAP, DAP, etc.). 84 3.0 IWPS Schema Considerations 86 The description of the IWPS information object consists of the following 87 requirements: 89 1. Syntax for definition/representation of information 90 object templates. 91 2. Registration procedures for information object 92 templates, etc. 93 3. Database structure or schema. 95 Items 1 and 2 will be covered in this document. Because database structure 96 can potentially restrict implementations (i.e. X.500 schema based versus 97 DNS schema based) it will be treated as a separate research topic and will 98 not be defined in this paper. 100 4.0 Syntax for Definition/Representation of Information Object Templates 102 A clear, precise, and consistent method must be used when discussing information 103 object templates and their associated attributes are discussed within the 104 context of IWPS. Therefore, this document uses the previously defined syntax 105 used by LDAP. The syntax is included in section 6.0 for reference. 107 The IWPS Person Object specifies a limited set of recommended attributes that 108 a White Pages Service should include. For instance, storage of user attributes 109 is a local issue, therefore, this draft suggest storage sizes but not storage 110 types. 112 This document lists the syntax with the attributes for developers of user 113 interface (UIs) to use as a reference, but it does not specify how the UI 114 should display these attributes. 116 Attributes that contain multiple-line text (i.e. Postal address) must use the 117 procedure defined in RFC 822 in section 3.1.1 on "folding" long header lines 118 [RFC-822]. 120 5.0 Information Object Template Definitions 122 This section describes the IWPS Person Information Object Template 123 and its associated attributes. The Person Object is a simple list of 124 attributes, no structure nor object inheritance is implied. 126 IWPS client applications should use the following size recommendations as the 127 maximum sizes of the attributes. However, applications should be able to 128 handle attributes of arbitrary size, returned by a server which may not comply 129 with these recommendation. All size recommendations are in bytes. 131 SPECIAL CONSIDERATIONS 133 Phone number: The full international form is recommended; 134 i.e. +1 206 703 0852. The field may contain 135 additional information following the phone 136 number. For example: 138 +1 800 759 7243 #123456 139 +1 505 882 8080 ext. 30852 141 Email address: Is multivalued and uses the otherMailbox syntax 142 to identify the different email addresses. 144 Certificate: Is multivalued. 146 Common Name: Is multivalued. 148 THE INFORMATION OBJECT TEMPLATE FOR THE IWPS PERSON 150 --General Attributes -- 152 Field Name Size Syntax 154 Email 360 otherMailbox 155 Cert 4000 Certificate 156 Home Page 128 URI 157 Common Name 64 DirectoryString 158 Given Name 48 DirectoryString 159 Surname 48 DirectoryString 160 Organization 64 DirectoryString 161 Locality 20 DirectoryString 162 Country 02 DirectoryString (ISO3166) 163 Language Spoken 02 DirectoryString (ISO 639) 165 --Personal Attributes 167 Telephone Number 30 PrintableString 168 Fax 30 PrintableString 169 Mobile Phone 30 PrintableString 170 Pager Number 30 PrintableString 171 Postal Address 255 PostalAddress 172 Description 255 DirectoryString 174 --Organizational Attributes 176 Title 64 DirectoryString 177 Office Phone 30 PrintableString 178 Office Fax 30 PrintableString 179 Office Mobile Ph 30 PrintableString 180 Office Pager 30 PrintableString 181 Postal Address 255 PostalAddress 183 --Security 185 Password 64 Password 187 --Ancillary 189 Creation Date 24 GeneralizedTime 190 Creator Name 255 URI 191 Modified Date 24 GeneralizedTime 192 Modifier Name 255 URI 194 6.0 IWPS Person Information Object Template Syntax 196 This section defines the syntax used by the IWPS person information object 197 template. It is copied in whole from the LDAP attribute working document with 198 some modification for completeness. 200 Certificate: 202 Due to differences from version X.509(1988) and X.509(1993) and additional 203 changes to support Certificate extensions, no string representation is 204 defined. Values with Certificate syntax must only be transferred using 205 the binary encoding, by requesting or returning the attributes with 206 descriptions "userCertificate;binary" or "caCertificate;binary". 208 DirectoryString: 210 A string with DirectoryString syntax is encoded in the UTF-8 form of 211 ISO 10646 (a superset of Unicode). Servers and clients must be prepared to 212 receive arbitrary Unicode characters in values. 214 For characters in the PrintableString form, the value is encoded as the 215 string value itself. 217 If it is of the TeletexString form, then the characters are transliterated 218 to their equivalents in UniversalString, and encoded in UTF-8 [Davis]. 220 If it is of the UniversalString or BMPString forms [UCS], UTF-8 is used to 221 encode them. 223 Note: the form of DirectoryString is not indicated in protocol unless the 224 attribute value is carried in binary. Servers which convert to DAP must 225 choose an appropriate form. Servers must not reject values merely because 226 they contain legal Unicode characters outside of the range of printable 227 ASCII. 229 GeneralizedTime: 231 Values of this syntax are encoded as printable strings, represented 232 as specified in X.208. Note that the time zone must be specified. 233 It is strongly recommended that Zulu time zone be used. For example: 235 199412161032Z 237 OtherMailbox: 239 Values of the OtherMailbox syntax are encoded according to the 240 following: 242 ::= '$' 244 ::= an encoded Printable String 246 ::= an encoded IA5 String 248 In the above, represents the type of mail system in 249 which the mailbox resides, for example "MCIMail"; and is the 250 actual mailbox in the mail system defined by . 252 NB: Practical experience has shown that developers will commonly use the 253 attribute RFC822 address instead of otherMailbox with the value equal: 255 Internet$foo@bar.com. 257 Password: 259 Values with Password syntax are encoded as octet strings. 261 PostalAddress: 263 Values with the PostalAddress syntax are encoded according to the 264 following: 266 ::= | '$' 268 In the above, each component of a postal address value is 269 encoded as a value of type DirectoryString syntax. Backslashes and 270 dollar characters, if they occur in the component, are quoted as 271 follows: 273 A backslash quoting mechanism is used to encode symbol character 274 such as ''', '$' or '#'. The backslash is followed by a pair of 275 hexadecimal digits representing the next character. A backslash 276 itself in the string which forms part of a larger syntax is 277 always transmitted as '\5C' or '\5c'. 279 PrintableString: 281 The encoding of a value with PrintableString syntax is the string 282 value itself. PrintableString is limited to the characters in 283 production

. Where production

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

::= | | ''' | '(' | ')' | '+' | ',' | '-' | '.' | 295 '/' | ':' | '?' | ' ' 297 7.0 Publishing of IWPS Information Object Templates. 299 The Working Group recommends that all information object templates 300 used for the IWPS be published as an RFC at the minimum. To facilitate 301 distribution, these publications should be made available on an Internet 302 information server (i.e. InterNIC). 304 Individual organizations may define information object templates that 305 are local in scope as required to meet local organizational needs. All 306 information that the organization wishes to be part of the IWPS must use a 307 published IWPS information object template. 309 8.0 Data Privacy 311 Each country, and each state within the US, has legislation defining 312 information privacy. The suggested attributes in Section 5.0 may be 313 considered private and the directory administrator is strongly advised 314 to verify the privacy legislation for his domain. 316 As suggested in "Privacy and Accuracy in NIC Databases" [RFC 1355], each 317 directory provider should provide a clear statement of the purpose of the 318 directory, the information that should be contained in it, and a privacy 319 policy associated with that information. This policy should include 320 restrictions for data dissemination. 322 This policy is strongly recommended for the US and Canada and required 323 by many countries in the European Community for data sharing. 325 9.0 Data Integrity 327 Data Integrity was first addressed in RFC1107 [KS89], which states "a 328 White Pages service will not be used, if the information it provides is 329 out of date or incorrect." Therefore, any production IWPS provider must 330 insure that all data is reasonably correct and up-to-date. 332 The optional Ancillary Attributes of the IWPS person template denote the 333 information's source and date of origin, and the source and date of its 334 latest modification. They provide the user with some measurement of the 335 quality of data making it easy to determine the owner and freshness of the 336 data retrieved. 338 If the Ancillary Attributes are implemented, the IWPS User Agent must be able 339 to retrieve and display this information. Retrieval and display may be done 340 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 References 362 [Davis] M. Davis, UTF-8, (WG2 N1036) DAM for ISO/IEC 10646-1. 364 [KS89] Sollins, K., "A Plan for Internet Directory Services", RFC 365 1107, Laboratory for Computer Science, MIT, July 1989. 367 [NADF92] North American Directory Forum, "User Bill of Rights for 368 entries and listings in the Public Directory', RFC 1295, 369 North American Directory Forum, January 1992. 371 [PA94] Postel, J., Anderson, C., "WHITE PAGES MEETING REPORT", RFC 372 1588, University of Southern California, February 1994. 374 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet 375 Text Messages", STD 11, RFC 822, August 1982. 377 [RFC-1355] Curran, J., Marine, A., "Privacy and Accuracy Issues in Network 378 Information Center Databases", FYI 15, RFC 1355, August 1992. 380 [UCS] Universal Multiple-Octet Coded Character Set (UCS) - Architecture 381 and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993. 383 11.0 Authors Address 385 Tony Genovese 386 The Microsoft Corporation 387 One Microsoft Way 388 Redmond, Washington 98007 389 USA 391 Phone: (206) 703-0852 392 EMail: TonyG@Microsoft.com 394 Barbara Jennings 395 Sandia National Laboratories 396 Albuquerque, New Mexico 87106 397 USA 399 Phone: (505) 845-8554 400 EMail: jennings@sandia.gov 402 Expires: 10 September 1977