idnits 2.17.1 draft-ietf-ids-iwps-schema-spec-00.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-03-29) 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 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 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. ** There are 7 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 231: '... MUST CONTAIN{...' RFC 2119 keyword, line 234: '... MAY CONTAIN{...' RFC 2119 keyword, line 302: '...subtypes are the MUST CONTAIN attribut...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 122 has weird spacing: '...ability is ne...' -- 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 (22 November 1995) is 10355 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) == Unused Reference: 'NADF92' is defined on line 202, but no explicit reference was found in the text == Unused Reference: 'PA94' is defined on line 206, but no explicit reference was found in the text ** 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') Summary: 16 errors (**), 0 flaws (~~), 6 warnings (==), 2 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-00.txt Microsoft 3 Expires: 22 May 1996 22 November 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. 42 To facilitate interoperibility and a common user experience the 43 Internet White Pages service needs to have a common set of information 44 about each person. 46 This Document will focus only on common information modeling issues 47 to which all IWPS providers must conform. To insure a consistent User 48 experience of this service we need to define a common User object. 49 This will allow a User to go between different implementations of 50 the service and have a consistent expectation as to what information 51 can be found about people on the Internet. Developers of this service 52 need to have an unambiguous method of representing the Information 53 objects managed by the service. This will help facilitate 54 interoperability and data management. 56 2.0 Scope 58 This document attempts to establish a simple set of information 59 objects templates that should prove extensible and usable by developers 60 of the IWPS. It will not attempt to be an exhaustive specification 61 of all objects that will be stored in the IWPS. It will provide a 62 specification of how objects will be defined and registered as part 63 of the IWPS. 65 3.0 IWPS Schema Considerations 67 The information object description requirements for the IWPS consists 68 of the following: 70 1. Syntax for definition/representation of Information 71 Object Templates. 72 2. Registration procedures for information object 73 Templates, etc. 74 3. Database structure or schema. 76 Items 1 and 2 will be covered in this Document. Database structure 77 because, it will potentially restrict implementations (i.e. X.500 78 schema based Vs DNS schema based) will not be defined in this 79 document. This area is a separate Research topic and will be covered 80 in its own document. 82 3.1 Syntax for definition/representation of Information objects 84 A clear, precise and consistent method must be used when information 85 object Templates and their attributes are discussed within the 86 context of IWPS. There are two possible methods to do this. i.e. 88 1. BNF 89 2. ASN.1 91 The Working Group recommends the use of ASN.1. It provides us with 92 a set of defined attributes and encoding syntax's. Also, it is well 93 documented and widely available. 95 The use of ASN.1 to specify the structure of the information objects 96 does not imply the use of Basic Encoding Rules (BER) for any IWPS 97 servers protocols. The use of Object inheritance is not used or 98 specified by this document. 100 3.2 Registration of IWPS Information object Templates. 102 The Working Group recommends the registration and publication of all 103 information object Templates used for the IWPS. We will use the IANA 104 branch of the ISO OID tree for registration of the IWPS Object 105 Templates. This branch was used by the Object Templates listed in 106 Appendix A. To facilitate distribution of IWPS information object 107 Templates they should be made available on the Internet information 108 server (i.e. InterNIC). At a minimum it is recommended that any new 109 information object Template that will be made available via the IWPS 110 will be published in a RFC and its OID registered with IANA. 112 Individual organizations may define information object Templates that 113 are only local in scope. This may be needed to meet local 114 organizational needs. If these information object Templates are not 115 registered with the IWPS, they may not be processable by the general 116 IWPS UAs. All information that the organization wishes to be part of 117 the IWPS must use an IWPS registered information object Template. 119 4.0 Security Certificates 121 Another feature that IWPS can provide us is the ability to store 122 Security Certificates. This capability is needed by secure mail 123 services such as PEM and PGP. To facilitate the storage and 124 management of these Certificates a new element is defined for the 125 iwpPerson object. This new element will allow multiple Certificates 126 to be stored with the person record. It also allows for the 127 deprecation of certificates through the use of a validity field. 128 This field is used to state the beginning and end dates the 129 certificate is valid. The element "certificates" is defined in 130 Appendix A. 132 5.0 Data Integrity 134 The question of Data Integrity was first addressed in RFC1107 [KS89]. 135 It basically states, that if the information is out of date it is 136 useless and the service will not be used. Therefore, a clear 137 requirement is that any production IWPS provider must insure that all 138 data is reasonably correct and current. 140 To facilitate the User in determining the quality of the data that 141 has been retrieved it is recommended that the optional Ancillary 142 information attribute of the IWPperson Template be supported. This 143 would require the IWPS UA to be able to retrieve and display this 144 information. This may be done as a separate operation from the fetch 145 of the information object. The Ancillary Information Attribute is 146 defined in Appendix A. It is further recommended that any new 147 information object Template include as a minimum the Ancillary 148 information attribute as an optional attribute. It would then be 149 left to the IWPS servers to optionally support the storage and 150 retrieval of this data. 152 The Ancillary Information attribute has been designed to provide the 153 following information about the information object with which it is 154 associated: 156 1. The date and time of the last modification. 158 2. Who performed the last modification. 160 3. Who owns or is responsible for the data stored 161 in the information object. 163 4. What is the official source of the data. 165 5. Which attributes in the information object have 166 been changed. 168 As new information object Templates are defined for the IWPS a new 169 changeRecord type will need to be defined for it and assigned to the 170 changeRecord attribute. 172 This attribute is not a part of the White Page Name (WPN). Where 173 WPN is an identifier for an instance of Information Object Template. 174 The WPN is constructed from the attributes of the Object. The 175 Ancillary Information attribute is not to be used as 176 part of the Purported Name presented to the IWPS UA. 178 6.0 Unstructured Data 180 There are a number of existing directory based systems that are 181 currently providing White Pages style of information. These systems 182 respond to queries by returning information without regard to any 183 structure of the data. There is nothing in their protocol 184 specifications that identify individual fields or attributes in the 185 response that would allow it to be machine processable. 187 To accommodate these systems and the way they return information, the 188 element unstructureData has been added to the iwpPerson object. This 189 element consists of a 1k block of data without any structure or 190 content requirements. It can be used to represent/store any of the 191 current sets of White Pages information. 193 It should be noted that this element is added for backward 194 compatibility of the existing systems only. It should not be used for 195 the development of any new white page service. 197 7.0 References 199 [KS89] Sollins, K., "A Plan for Internet Directory Services", RFC 200 1107, Laboratory for Computer Science, MIT, July 1989. 202 [NADF92] North American Directory Forum, "User Bill of Rights for 203 entries and listings in the Public Directory', RFC 1295, 204 North American Directory Forum, January 1992. 206 [PA94] Postel, J., Anderson, C., "WHITE PAGES MEETING REPORT", RFC 207 1588, University of Southern California, February 1994. 209 8.0 Authors Address 211 Tony Genovese 212 The Microsoft Corporation 213 One Microsoft way 214 Redmond, Washington 98007 215 USA 217 Phone: (206) 703-0852 218 EMail: TonyG@Microsoft.com 220 Appendix A Information Object Template Definitions 222 The Information Objects Template and attributes defined in this appendix 223 are used to define the contents of Information Objects of the IWPS. 224 In particular the Template defined below deals with the 225 person Object. Any new Information Object must be registered with IANA. 227 -- The Information Object Template for the IWPS person -- 229 iwpPerson OBJECT-CLASS 230 SUBCLASS OF top 231 MUST CONTAIN{ 232 commonName, 233 wpi} 234 MAY CONTAIN{ 235 surname, 236 organizationalName, 237 postalAddress, 238 telephoneNumber, 239 emailAddress, 240 certificates, 241 unstructuredData, 242 ancillaryInformation} 243 ::={iwpsObjectTemplate.1} 245 -- The WPI attribute to be use by Information Objects of the IWPS -- 247 wpi ATTRIBUTE 248 WITH ATTRIBUTE-SYNTAX 249 caseIgnoreStringSyntax 250 ((SIZE(1..ub-iwps-wpi)) 251 ::={iwpsAttributeType 2} 253 -- The element for the storage of Email information -- 255 emailAddress ATTRIBUTE 256 WITH ATTRIBUTE-SYNTAX EmailAddress 257 ::={iwpsAttributeType 1} 259 EmailAddress ::= SEQUENCE (SIZE(1..ub-email-boxes)) OF 260 caseIgnoreString(SIZE(1..ub-email-addr)) 262 -- The element to be used to store Security Certificates -- 264 certificates ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX 265 Keys{iwpsAttributeType 3} 267 Keys ::= SEQUENCE (SIZE(1..ub-keys)) OF keyInfo 269 keyInfo ::= SEQUENCE{ 270 validity Valid, 271 key KeyType} 273 Valid ::= SEQUENCE{ 274 notBefore UTCTime, 275 notAfter UTCTime} 277 KeyType ::= SEQUENCE{ 278 algorithm OBJECT IDENTIFIER, 279 subjectKey caseIgnoreStringSyntax(SIZE(1..ub-keysize))} 281 -- The Unstructured Data element used to contain free form data -- 283 unstructuredData ::= caseIgnoreStringSyntax(SIZE(1..ub-data)) 285 -- The Ancillary Information attribute used for data integrity -- 287 ancillaryInformation ::= 288 SEQUENCE{ 289 LastModifiedDate 290 UTCTime, 291 LastModifiedBy, 292 commanName, 293 OwnerofData, 294 commonName, 295 OfficialSourceofData 296 dataBase, 297 WhatWasChanged 298 changeRecord} 300 dataBase ::= caseIgnoreStringSyntax(SIZE(1..ub-database)) 302 -- Change record subtypes are the MUST CONTAIN attributes -- 304 changeRecord ::= iwpsPersonType (commonName | wpi) 306 iwpsPersonType ::= 307 BIT STRING { 308 commonName (0), 309 surname (1), 310 organizationalName (2), 311 postalAddress (3), 312 telephoneNumber (4), 313 emailAddress (5), 314 wpi (6) 315 } 317 -- Size limits used by the IWPS -- 319 ub-database INTEGER ::= 1024 320 ub-data INTEGER ::= 1024 321 ub-email-boxes INTEGER ::= 8 322 ub-email-addr INTEGER ::= 1024 323 ub-keys INTEGER ::= 6 324 ub-keysize INTEGER ::= 512 325 ub-iwps-wpi INTEGER ::= 256 327 -- Object Identifiers use by the IWPS -- 329 Internet OBJECT IDENTIFIER ::= {ISO(1) org(3) DOD(6) 1} 330 iwps OBJECT IDENTIFIER ::= {Internet NN} 331 iwpsAttributeType OBJECT IDENTIFIER ::= {iwps 1} 332 iwpsObjectTemplate OBJECT IDENTIFIER ::= {iwps 2}