idnits 2.17.1 draft-ietf-ids-iwps-schema-spec-03.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-24) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 423 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 27 instances of too long lines in the document, the longest one being 6 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 (10 January 1997) is 9966 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Davis' -- Possible downref: Non-RFC (?) normative reference: ref. 'LDAP-A' ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'UCS' Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 T. Genovese 2 Microsoft 4 Barbara Jennings 5 Sandia National Laboratory 7 10 January 1997 8 Expires: July 1997 10 A Common Schema for the Internet White Pages Service 11 File Name: draft-ietf-ids-iwps-schema-spec-03.txt 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), it areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 30 Overview 32 The work is the result of the IETF Integrated Directory Services (IDS) 33 Working Group which proposes to establish a specification for a simple 34 Internet white pages service. To facilitate this effort it would be 35 helpful to have a common schema used by the various white page servers. 36 This document is designed to specify the basic set of attributes to be 37 used for a white page entry for an individual. It describes how new 38 objects can be defined and registered. This schema is independent of 39 specific implementations of the White Page service. 41 This document does not describe how to represent other objects in the 42 White page service. Further it does not address the search/sort expectations 43 within a particular service. 45 1.0 Introduction 47 The Internet community has stated that there is a need for the 48 development and deployment of a White Page service. This service 49 would be used to locate information about people in the Internet[PA94]. 50 To facilitate interoperability and a common user expectation the 51 Internet White Pages Service (IWPS) needs to have a common set of 52 information about each person. 54 This Document will focus only on common information modeling issues to 55 which all IWPS providers must conform. To insure a consistent user 56 experience of this service we need to define a common user object. This 57 will allow a user to go between different implementations of the service 58 and have a consistent expectation as to what information can be found about 59 people on the Internet. Developers of this service need to have an 60 unambiguous method of representing the Information objects managed by 61 the service. This will help facilitate interoperability and data management. 63 2.0 Scope 65 This document will establish the set of attributes that specify the common 66 user information object for the IWPS. It will not attempt to be an 67 exhaustive specification of all objects that will be stored in the IWPS. 68 The process used by this document to define the user object will be used to 69 define all other information objects used in the IWPS. 71 All conforming implementations must support at the minimum, the core 72 attributes listed in Appendix A. Implementations may include additional 73 local attributes and be considered in conformance as long as they support 74 the core set of attributes. 76 This document will not specify rules with respect to information privacy. 77 Each country has its own set of laws and practices. Work covering 78 this area was done by North American Directory Forum (NADF) [NADF92]. In 79 this are recommendations for registrants rights for both the USA and Canada. 81 3.0 IWPS Schema Considerations 83 The information object description requirements for the IWPS 84 consists of the following: 86 1. Syntax for definition/representation of Information 87 Object Templates. 88 2. Registration procedures for information object 89 Templates, etc. 90 3. Database structure or schema. 92 Items 1 and 2 will be covered in this Document. Database structure 93 can potentially restrict implementations (i.e. X.500 schema based verses 94 DNS schema based) and will not be defined in this document. This area is 95 a separate Research topic and will be covered in its own document. 97 3.1 Syntax for Definition/Representation of Information objects 99 A clear, precise and consistent method must be used when information 100 object Templates and their associated attributes are discussed within 101 the context of IWPS. There are two possible methods to do this. i.e. 103 1. BNF 104 2. ASN.1 106 The Working Group has recommended the use of BNF. BNF is widely used by 107 the Internet community and is well understood. It is used by the 108 LDAP work on attribute definitions. This document makes use of the 109 previously defined syntaxes use by LDAP. They are included in Appendix 110 B for convenience. 112 The use of Object inheritance is not used or specified by this document. 113 The IWP person object specifies a set of recommended attributes that a 114 White Page Service should include. This draft suggests storage sizes, 115 but does not recommend storage types. Storage of user attributes is a 116 local issue. The Syntax listed with the attributes are provided so the 117 developers of user interfaces (UIs) may have a consistent expectation. 118 This document does not specify a Directory access protocol (i.e. whoi++, 119 LDAP, DAP, etc.) or how the UI is to display these attributes. 121 Attributes that contain textual information that must be split over multiple 122 lines (i.e. Postal address) will use the procedure defined in RFC 822 in 123 section 3.1.1 on "folding" long header lines [RFC-822]. 125 For International localization it is recommended that attributes (except 126 email addresses) used to identify people must follow the DirectoryString 127 syntax defined by LDAP [LDAP-A]. 129 3.2 Publishing of IWPS Information object Templates. 131 The Working Group recommends that all information object Templates 132 used for the IWPS be published as an RFC at the mimimum. To facilitate 133 distribution of IWPS information object Templates they should be made 134 available on the Internet information server (i.e. InterNIC). 136 Individual organizations may define information object Templates that 137 are only local in scope. This may be needed to meet local 138 organizational needs. All information that the organization wishes 139 to be part of the IWPS must use an IWPS published information object 140 Template. 142 4.0 Data Privacy 144 Each country and within the US, each state, has legislation defining 145 information privacy. The suggested attributes in Appendix A may be 146 considered private and the directory administrator is stongly advised 147 to verify the privacy legislation for his domain. 149 As suggested in RFC 1355 (4) each Directory provider should provide a 150 clear statement of the purpose of the directory, the information that 151 will be contained in it, and a privacy policy associated with the 152 information that is stored within the directory. This policy should 153 include restrictions for data dissimenation. 155 This policy is strongly recommended for the US and Canada and required 156 for many counties in the European Community for data sharing. 158 5.0 Data Integrity 160 Data Integrity was first addressed in RFC1107 [KS89]. Which states, 161 that if the information is out of date it is useless and the service 162 will not be used. Therefore, a clear requirement is that any production 163 IWPS provider must insure that all data is reasonably correct and current. 165 Ancillary attributes have been included which state the source of origin 166 and the current party responsible for the data in addition to date; 167 such that the owner and the freshness of the data can be easily determined. 169 To facilitate the user in determining the quality of the data that 170 has been retrieved it is recommended that the optional Ancillary 171 attributes of the IWPS person Template be supported. This would require 172 that the IWPS User Agent be able to retrieve and display this 173 information. This may be done as a separate operation from the fetch 174 of the information object. The Ancillary Attributes are defined in 175 Appendix A. It is further recommended that any new information object 176 Template include as a minimum the Ancillary attributes as an optional 177 set of attributes. It would then be left to the IWPS servers to 178 optionally support the storage and retrieval of this data. 180 The Ancillary attributes have been designed to provide the following 181 information about the information object with which it is associated: 183 1. The date and time the entry was created; Creation Date. 185 2. Owner or individual responsible for the data creation; 186 Creator Name. 188 3. The date and time of the last modification; 189 Modified Date. 191 4. Individual responsible forthe last modification; 192 Modifier Name. 194 6.0 References 196 [Davis] M. Davis, UTF-8, (WG2 N1036) DAM for ISO/IEC 10646-1. 198 [LDAP-A] Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight 199 Directory Access Protocol: Standard and Pilot Attribute Definitions", 200 Draft-ietf-asid-ldapv3-attributes-01.txt, June, 1996 202 [KS89] Sollins, K., "A Plan for Internet Directory Services", RFC 203 1107, Laboratory for Computer Science, MIT, July 1989. 205 [NADF92] North American Directory Forum, "User Bill of Rights for 206 entries and listings in the Public Directory', RFC 1295, 207 North American Directory Forum, January 1992. 209 [PA94] Postel, J., Anderson, C., "WHITE PAGES MEETING REPORT", RFC 210 1588, University of Southern California, February 1994. 212 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet 213 Text Messages", STD 11, RFC 822, August 1982. 215 [UCS] Universal Multiple-Octet Coded Character Set (UCS) - Architecture 216 and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993. 218 7.0 Authors Address 220 Tony Genovese 221 The Microsoft Corporation 222 One Microsoft way 223 Redmond, Washington 98007 224 USA 226 Phone: (206) 703-0852 227 EMail: TonyG@Microsoft.com 229 Barbara Jennings 230 Sandia National Laboratories 231 Albuquerque, New Mexico 87106 232 USA 234 Phone: (505) 845-8554 235 EMail: jennings@sandia.gov 237 Appendix A Information Object Template Definitions 239 This appendix contains the IWPS Person Information Object Template 240 and its associated attributes. The Person Object is a simple list 241 of attributes, no structure or object inheritance is implied. All 242 size recommendations are in bytes. 244 The following size recommendations should be used as an indication 245 of the largest size of a particular attribute that an IWPS client 246 application would see in practice. In particular instances, actual 247 user attributes may be larger or smaller than these recommendations, 248 and applications should be written to accept any size attribute returned 249 from a server. 251 -- SPECIAL CONSIDERATIONS -- 253 Phone number: the full international form is recommended; 254 i.e. +1 206 703 0852. The field may contain 255 additional information following the phone 256 number. For example: 258 +1 800 sky page #123456 259 +1 882 8080 ext 30852 261 Email address: Is multivalued and uses the otherMailbox syntax 262 to identify the different email addresses. 264 Certificate: Is multivalued. 266 Common Name: Is multivalued. 268 -- THE INFORMATION OBJECT TEMPLATE FOR THE IWPS PERSON -- 270 --General Attributes -- 272 Field Name Size Syntax 274 Email 360 otherMailbox 275 Cert 4000 Certificate 276 Home Page 128 URI 277 Common Name 64 DirectoryString 278 Given Name 48 DirectoryString 279 Surname 48 DirectoryString 280 Organization 64 DirectoryString 281 Locality 20 DirectoryString 282 Country 02 DirectoryString (ISO3166) 283 Language Spoken 02 DirectoryString (ISO 639) 285 --Personal Attributes 287 Telephone Number 30 PrintableString 288 Fax 30 PrintableString 289 Mobile Phone 30 PrintableString 290 Pager Number 30 PrintableString 291 Postal Address 255 PostalAddress 292 Description 255 DirectoryString 294 --Organizational Attributes 296 Title 64 DirectoryString 297 Office Phone 30 PrintableString 298 Office Fax 30 PrintableString 299 Office Mobile Ph 30 PrintableString 300 Office Pager 30 PrintableString 301 Postal Address 255 PostalAddress 303 --Security 305 Password 64 Password 307 --Ancillary 309 Creation Date 24 GeneralizedTime 310 Creator Name 255 URI 311 Modified Date 24 GeneralizedTime 312 Modifier Name 255 URI 314 Appendix B IWPS Person Information Object Template Syntaxes 316 This Appendix contains the definitions of the syntaxes used by the 317 IWPS Person Information Object Template. They are copied in whole 318 from the LDAP attribute working document. Some modification to the 319 LDAP attribute text was done for completeness. 321 Certificate: 323 Do to differences from version X.509(1988) and X.509(1993) and additional 324 changes to the ASN.1 definition to support certificate extensions, no 325 string representation is defined, and values with Certificate syntax 326 must only be transferred using the binary encoding, by requesting or 327 returning the attributes with descriptions "userCertificate;binary" or 328 "caCertificate;binary". The BNF notation in RFC 1778 for 329 "User Certificate" is not recommended to be used. 331 DirectoryString: 333 A string with DirectoryString syntax is encoded in the UTF-8 form of 334 ISO 10646 (a superset of Unicode). Servers and clients must be prepared to 335 receive arbitrary Unicode characters in values. 337 For characters in the PrintableString form, the value is encoded as the 338 string value itself. 340 If it is of the TeletexString form, then the characters are transliterated 341 to their equivalents in UniversalString, and encoded in UTF-8 [Davis]. 343 If it is of the UniversalString or BMPString forms [UCS], UTF-8 is used to 344 encode them. 346 Note: the form of DirectoryString is not indicated in protocol unless the 347 attribute value is carried in binary. Servers which convert to DAP must 348 choose an appropriate form. Servers must not reject values merely because 349 they contain legal Unicode characters outside of the range of printable 350 ASCII. 352 GeneralizedTime: 354 Values of this syntax are encoded as printable strings, represented 355 as specified in X.208. Note that the time zone must be specified. 356 It is strongly recommended that Zulu time zone be used. For example, 358 199412161032Z 359 OtherMailbox: 361 Values of the OtherMailbox syntax are encoded according to the 362 following BNF: 364 ::= '$' 366 ::= an encoded Printable String 368 ::= an encoded IA5 String 370 In the above, represents the type of mail system in 371 which the mailbox resides, for example "MCIMail"; and is the 372 actual mailbox in the mail system defined by . 374 Password: 376 Values with Password syntax are encoded as octet strings. 378 PostalAddress: 380 Values with the PostalAddress syntax are encoded according to the 381 following BNF: 383 ::= | '$' 385 In the above, each component of a postal address value is 386 encoded as a value of type DirectoryString syntax. Backslashes and 387 dollar characters, if they occur in the component, are quoted as 388 follows: 389 A backslash quoting mechanism is used to encode symbol character 390 such as ''', '$' or '#'. The backslash is followed by a pair of 391 hexadecimal digits representing the next character. A backslash 392 itself in the string which forms part of a larger syntax is 393 always transmitted as '\5C' or '\5c'. 395 PrintableString: 397 The encoding of a value with PrintableString syntax is the string 398 value itself. PrintableString is limited to the characters in 399 production

. Where production

is discribed by the following 400 BNF: 402 ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | 403 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | 404 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' | 405 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | 406 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | 407 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z' 409 ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' 411

::= | | ''' | '(' | ')' | '+' | ',' | '-' | '.' | 412 '/' | ':' | '?' | ' '