idnits 2.17.1 draft-ietf-ids-iwps-schema-spec-01.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-26) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 4 longer pages, the longest (page 3) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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. 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 June 1995) is 10547 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: 14 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Integrated Directory Services Working Group T. Genovese 2 draft-ietf-ids-iwps-schema-spec-01.txt Microsoft 3 Expires: 11 December 1996 11 June 1995 5 A Common Schema for the Internet White Pages Service 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), it areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet- Drafts as reference 17 material or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 21 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 22 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 23 Rim). 25 Overview 27 The IETF Integrated Directory Services (IDS) Working Group proposes to 28 establish a specification for a simple Internet white pages service. 29 To facilitate this effort it would be helpful to have a common schema 30 used by the various white page servers. This document is designed to 31 specify the basic set of attributes to be used for a white page entry 32 for a person. This schema does not describe how to represent other 33 objects in the White page service. It does describe how new objects 34 can be defined and registered. This schema is independent of 35 implementations of the White Page service. 37 1.0 Introduction 39 The Internet community has stated that there is a need for the 40 development and deployment of a White Page service. This service 41 would be used to locate information about people in the Internet[PA94]. 43 To facilitate interoperibility and a common user experience the 44 Internet White Pages service needs to have a common set of information 45 about each person. 47 This Document will focus only on common information 48 modeling issues to which all IWPS providers must conform. To insure 49 a consistent User experience of this service we need to define a common 50 User object. This will allow a User to go between different 51 implementations 52 of the service and have a consistent expectation asto what information 53 can be found about people on the Internet. Developers of this service 54 need to have an unambiguous method of representing the Information 55 objects 56 managed by the service. This will help facilitate interoperability and 57 data management. 59 2.0 Scope 61 This document will establish the set of attributes that specify the 62 common 63 user information object for the IWPS. It will not attempt to be an 64 exhaustive specification of all objects that will be stored in the IWPS. 65 The 66 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 70 privacy. 71 Each country has its own set of laws and practices. The best work 72 covering 73 this area was done by NADF [NADF92]. It makes recommendations for the 74 USA 75 Canada. 77 3.0 IWPS Schema Considerations 79 The information object description requirements for the IWPS 80 consists of the following: 82 1. Syntax for definition/representation of Information 83 Object Templates. 84 2. Registration procedures for information object 85 Templates, etc. 86 3. Database structure or schema. 88 Items 1 and 2 will be covered in this Document. Database structure 89 because, it will potentially restrict implementations (i.e. X.500 90 schema based Vs DNS schema based) will not be defined in this 91 document. This area is a separate Research topic and will be covered 92 in its own document. 94 3.1 Syntax for definition/representation of Information objects 96 A clear, precise and consistent method must be used when information 97 object Templates and their associated attributes are discussed within 98 the context of IWPS. There are two possible methods to do this. i.e. 100 1. BNF 101 2. ASN.1 103 The Working Group has recommended the use of ASN.1. It provides us with 105 a set of defined attributes and encoding syntax's. Also, it is well 106 documented and widely available. 108 The use of ASN.1 to specify the attributes of the information objects 109 does not imply the use of Basic Encoding Rules (BER) for any IWPS 110 servers protocols. The use of Object inheritance is not used or 111 specified by this document. 113 The IWP person object specifies a set of recommended attributes that 114 a White Page service should include. It recommends storage sizes, but 115 does not recommend storage types. How an implementation stores the user 116 attributes is a local issue. The Syntax listed with the attributes are 117 provided so the developers of UIs will have a consistent expectation. 118 This document does not specify a Director access protocols (i.e. whoi++, 120 LDAP,DAP, etc.) or how the UI is to display these attributes. 122 Attributes that contain textual information that must be split over 123 multiple 124 lines (i.e. Postal address) will use the procedure defined in RFC 822 in 126 section 3.1.1 on "folding" long header lines [RFC-822]. 128 For International localization it is recommended that attributes (except 130 email addresses) used to identify people use DirectoryString syntax 131 defined 132 by LDAP [LDAP-A]. 134 3.2 Publishing of IWPS Information object Templates. 136 The Working Group recommends publication of all information object 137 Templates 138 used for the IWPS. To facilitate distribution of IWPS information object 139 Templates they should be made available on the Internet information 140 server (i.e. InterNIC). At a minimum it is recommended that any new 141 information object Template that will be made available via the IWPS 142 will be published as a RFC. 144 Individual organizations may define information object Templates that 145 are only local in scope. This may be needed to meet local 146 organizational needs. All information that the organization wishes 147 to be part of the IWPS must use an IWPS published information object 148 Template. 150 5.0 Data Integrity 152 The question of Data Integrity was first addressed in RFC1107 [KS89]. 153 It basically states, that if the information is out of date it is 154 useless and the service will not be used. Therefore, a clear 155 requirement is that any production IWPS provider must insure that all 156 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 the IWPS UA to be able to retrieve and display this information. This 162 may be done as a separate operation from the fetch of the information 163 object. The Ancillary Attributes are defined in Appendix A. It is 164 further 165 recommended that any new information object Template include as a 166 minimum 167 the Ancillary attributes as an optional set of attributes. It would 168 then 169 be left to the IWPS servers to optionally support the storage and 170 retrieval 171 of this data. 173 The Ancillary attributes have been designed to provide the following 174 information about the information object with which it is associated: 176 1. The date and time of the last modification. 178 2. Who performed the last modification. 180 3. Who owns or is responsible for the data stored 181 in the information object. 183 4. What is the official source of the data. 185 7.0 References 187 [LDAP-A] Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight 188 Directory Access Protocol: Standard and Pilot Attribute Definitions", 189 Draft-ietf-asid-ldapv3-attributes-01.txt, June, 1996 191 [KS89] Sollins, K., "A Plan for Internet Directory Services", RFC 192 1107, Laboratory for Computer Science, MIT, July 1989. 194 [NADF92] North American Directory Forum, "User Bill of Rights for 195 entries and listings in the Public Directory', RFC 1295, 196 North American Directory Forum, January 1992. 198 [PA94] Postel, J., Anderson, C., "WHITE PAGES MEETING REPORT", RFC 199 1588, University of Southern California, February 1994. 201 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet 202 Text Messages", STD 11, RFC 822, August 1982. 204 8.0 Authors Address 206 Tony Genovese 207 The Microsoft Corporation 208 One Microsoft way 209 Redmond, Washington 98007 210 USA 212 Phone: (206) 703-0852 213 EMail: TonyG@Microsoft.com 215 Appendix A Information Object Template Definitions 217 This appendix contains the IWPS Person Information Object Template and 218 its associated attributes. The Person Object is a simple list of 219 attributes, 220 no structure or object inheritance is implied. All size recommendations 221 are 222 in bytes. Phone numbers should be the full international form 223 i.e. +1 206 703 0852. 225 -- The Information Object Template for the IWPS person -- 227 --General Attributes -- 229 Field Name Size Syntax 231 Primary Email 120 CaseIgnoreString 232 Primary Cert 4000 Certificate 233 Secondary Email 120 CaseIgnoreString 234 Home Page 128 caseExactString 235 Common Name 64 DirectoryString 236 Given Name 48 DirectoryString 237 initials 12 DirectoryString 238 Surname 48 DirectoryString 239 Generation Qual 06 DirectoryString 240 Organization 64 DirectoryString 241 Locality 20 DirectoryString 242 Country 02 DirectoryString (ISO3166) 243 Language 02 DirectoryString (ISO 639) 245 --Personal Attributes 247 Telephone Number 20 PrintableString 248 Fax 20 PrintableString 249 Mobile Phone 20 PrintableString 250 Pager Number 20 PrintableString 251 Mailing Address 255 PostalAddress 252 Birth Date 08 PrintableString 253 Gender 01 PrintableString 254 Marital Status 01 PrintableString 255 Bio 255 DirectoryString 257 --Organizational Attributes 259 Title 64 DirectoryString 260 Office Phone 20 PrintableString 261 Office Fax 20 PrintableString 262 Office Mobile Ph 20 PrintableString 263 Office Pager 20 PrintableString 264 Mailing Address 255 PostalAddress 266 --Security 268 Password 64 Password 270 --Ancillary 272 User Id 04 Integer 273 Creation time 24 GeneralizedTime 274 Last Modified 24 GeneralizedTime 275 Creator Name 255 DN 276 Modifier Name 255 DN