idnits 2.17.1 draft-ietf-ids-iwps-schema-spec-02.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 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 305 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 16 instances of too long lines in the document, the longest one being 5 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 (11 November 1996) is 10020 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. '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) Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Integrated Directory Services Working Group 3 T. Genovese 4 Microsoft 5 Barbara Jennings 6 Sandia National Laboratory 8 11 November 1996 9 Expires: 10 May 1997 11 A Common Schema for the Internet White Pages Service 12 File Name: draft-ietf-ids-iwps-schema-spec-02.txt 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), it areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts 28 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 29 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 31 Overview 33 The work is the result of the IETF Integrated Directory Services (IDS) 34 Working Group which proposes to establish a specification for a simple 35 Internet white pages service. To facilitate this effort it would be 36 helpful to have a common schema used by the various white page servers. 37 This document is designed to specify the basic set of attributes to be 38 used for a white page entry for an individual. This schema does not 39 describe how to represent other objects in the White page service. 40 It does describe how new objects can be defined and registered. This 41 schema is independent of implementations of the White Page service. 43 1.0 Introduction 45 The Internet community has stated that there is a need for the 46 development and deployment of a White Page service. This service 47 would be used to locate information about people in the Internet[PA94]. 48 To facilitate interoperability and a common user expectation the 49 Internet White Pages Service (IWPS) needs to have a common set of 50 information about each person. 52 This Document will focus only on common information modeling issues to 53 which all IWPS providers must conform. To insure a consistent user 54 experience of this service we need to define a common user object. This 55 will allow a user to go between different implementations of the service 56 and have a consistent expectation as to what information can be found about 57 people on the Internet. Developers of this service need to have an 58 unambiguous method of representing the Information objects managed by 59 the service. This will help facilitate interoperability and data management. 61 2.0 Scope 63 This document will establish the set of attributes that specify the common 64 user information object for the IWPS. It will not attempt to be an 65 exhaustive specification of all objects that will be stored in the IWPS. 66 The process used by this document to define the user object will be used to 67 define all other information objects used in the IWPS. 69 This document will not specify rules with respect to information privacy. 70 Each country has its own set of laws and practices. Work covering 71 this area was done by North American Directory Forum (NADF) [NADF92]. In 72 this are recommendations for registrants rights for both the USA and Canada. 74 3.0 IWPS Schema Considerations 76 The information object description requirements for the IWPS 77 consists of the following: 79 1. Syntax for definition/representation of Information 80 Object Templates. 81 2. Registration procedures for information object 82 Templates, etc. 83 3. Database structure or schema. 85 Items 1 and 2 will be covered in this Document. Database structure 86 can potentially restrict implementations (i.e. X.500 schema based verses 87 DNS schema based) and will not be defined in this document. This area is 88 a separate Research topic and will be covered in its own document. 90 3.1 Syntax for Definition/Representation of Information objects 92 A clear, precise and consistent method must be used when information 93 object Templates and their associated attributes are discussed within 94 the context of IWPS. There are two possible methods to do this. i.e. 96 1. BNF 97 2. ASN.1 99 The Working Group has recommended the use of ASN.1. It provides us with 100 a set of defined attributes and encoding syntax's. Also, it is well 101 documented and widely available. 103 The use of ASN.1 to specify the attributes of the information objects does 104 not imply the use of Basic Encoding Rules (BER) for any IWPS servers 105 protocols. The use of Object inheritance is not used or specified by 106 this document. The IWP person object specifies a set of recommended 107 attributes that a White Page Service chould include. It suggests storage 108 sizes, but does not recommend storage types. How an implementation stores 109 the user attributes is a local issue. The Syntax listed with the attributes 110 are provided so the developers of user interfaces (UIs) may have a consistent 111 expectation. This document does not specify a Directory access protocol 112 (i.e. whoi++, LDAP, DAP, etc.) or how the UI is to display these attributes. 114 Attributes that contain textual information that must be split over multiple 115 lines (i.e. Postal address) will use the procedure defined in RFC 822 in 116 section 3.1.1 on "folding" long header lines [RFC-822]. 118 For International localization it is recommended that attributes (except 119 email addresses) used to identify people must follow the 120 DirectoryString syntax defined by LDAP [LDAP-A]. 122 3.2 Publishing of IWPS Information object Templates. 124 The Working Group recommends that all information object Templates 125 used for the IWPS be published as an RFC at the mimimum. To facilitate 126 distribution of IWPS information object Templates they should be made 127 available on the Internet information server (i.e. InterNIC). 129 Individual organizations may define information object Templates that 130 are only local in scope. This may be needed to meet local 131 organizational needs. All information that the organization wishes 132 to be part of the IWPS must use an IWPS published information object 133 Template. 135 4.0 Data Privacy 137 Each country and within the US, each state, has legislation defining 138 information privacy. The suggested attributes in Appendix may be 139 considered private and a directory administrator is stongly advised 140 to verify the privacy legislation for his domain. 142 As suggested in RFC 1355 (4) each Directory provider should provide a 143 clear statement of the purpose of the directory, the information that 144 will be contained in it, and a privacy policy associated with the 145 information that is stored within the directory. This policy should 146 include restrictions for data dissimenation. 148 This policy is strongly recommended for the US and Canada and required 149 for many counties in the European Community for data sharing. 151 5.0 Data Integrity 153 Data Integrity was first addressed in RFC1107 [KS89]. Which states, 154 that if the information is out of date it is useless and the service 155 will not be used. Therefore, a clear requirement is that any production 156 IWPS provider must insure that all data is reasonably correct and current. 158 To facilitate the user in determining the quality of the data that 159 has been retrieved it is recommended that the optional Ancillary 160 attributes of the IWPS person Template be supported. This would require 161 that the IWPS User Agent to be able to retrieve and display this 162 information. This may be done as a separate operation from the fetch 163 of the information object. The Ancillary Attributes are defined in 164 Appendix A. It is further recommended that any new information object 165 Template include as a minimum the Ancillary attributes as an optional 166 set of attributes. It would then be left to the IWPS servers to 167 optionally support the storage and retrieval of this data. 169 The Ancillary attributes have been designed to provide the following 170 information about the information object with which it is associated: 172 1. The date and time of the last modification. 174 2. Who performed the last modification. 176 3. Who owns or is responsible for the data stored 177 in the information object. 179 4. What is the official source of the data. 181 6.0 References 183 [LDAP-A] Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight 184 Directory Access Protocol: Standard and Pilot Attribute Definitions", 185 Draft-ietf-asid-ldapv3-attributes-01.txt, June, 1996 187 [KS89] Sollins, K., "A Plan for Internet Directory Services", RFC 188 1107, Laboratory for Computer Science, MIT, July 1989. 190 [NADF92] North American Directory Forum, "User Bill of Rights for 191 entries and listings in the Public Directory', RFC 1295, 192 North American Directory Forum, January 1992. 194 [PA94] Postel, J., Anderson, C., "WHITE PAGES MEETING REPORT", RFC 195 1588, University of Southern California, February 1994. 197 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet 198 Text Messages", STD 11, RFC 822, August 1982. 200 8.0 Authors Address 202 Tony Genovese 203 The Microsoft Corporation 204 One Microsoft way 205 Redmond, Washington 98007 206 USA 208 Phone: (206) 703-0852 209 EMail: TonyG@Microsoft.com 211 Barbara Jennings 212 Sandia National Laboratories 213 Albuquerque, New Mexico 87106 214 USA 216 Phone: (505) 845-8554 217 EMail: jennings@sandia.gov 219 Appendix A Information Object Template Definitions 221 This appendix contains the IWPS Person Information Object Template 222 and its associated attributes. The Person Object is a simple list 223 of attributes, no structure or object inheritance is implied. All 224 size recommendations are in bytes. 226 The following size recommendations should be used as an indication 227 of the largest size of a particular attribute that an IWPS client 228 application would see in practice. In particular instances, actual 229 user attributes may be larger or smaller than these recommendations, 230 and applications should be written to accept any size attribute returned 231 from a server. 233 -- SPECIAL CONSIDERATIONS -- 235 Phone number: should be the full international form 236 i.t. +1 206 703 0852. The field may contain 237 additional information following the phone 238 number. For example: 240 +1 800 sky page #123456 241 +1 882 8080 ext 30852 243 Email address: Is multivalued and uses the otherMailbox syntax 244 to identify the different email addresses. 246 Certificate: Is multivalued. 248 Common Name: Is multivalued. 250 -- THE INFORMATION OBJECT TEMPLATE FOR THE IWPS PERSON -- 252 --General Attributes -- 254 Field Name Size Syntax 256 Email 360 otherMailbox 257 Cert 4000 Certificate 258 Home Page 128 caseExactString 259 Common Name 64 DirectoryString 260 Given Name 48 DirectoryString 261 Surname 48 DirectoryString 262 Organization 64 DirectoryString 263 Locality 20 DirectoryString 264 Country 02 DirectoryString (ISO3166) 265 Language Spoken 02 DirectoryString (ISO 639) 267 --Personal Attributes 269 Telephone Number 30 PrintableString 270 Fax 30 PrintableString 271 Mobile Phone 30 PrintableString 272 Pager Number 30 PrintableString 273 Postal Address 255 PostalAddress 274 Bio 255 DirectoryString 276 --Organizational Attributes 278 Title 64 DirectoryString 279 Office Phone 30 PrintableString 280 Office Fax 30 PrintableString 281 Office Mobile Ph 30 PrintableString 282 Office Pager 30 PrintableString 283 Postal Address 255 PostalAddress 285 --Security 287 Password 64 Password 289 --Ancillary 291 Creation time 24 GeneralizedTime 292 Last Modified 24 GeneralizedTime 293 Creator Name 255 DN 294 Modifier Name 255 DN