idnits 2.17.1 draft-ietf-schema-rqmts-list-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-19) 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 222 has weird spacing: '... set of metad...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Verification - a process of determining authenticity of facts implied or explicitly specified by a contact person during the process of submitting a schema listing request; the methods used to implement such a process MAY or MAY NOT be based on an IETF-sanctioned security protocol; specification of the methods used to implement such a process as well as the trust relationships relevant to the process are outside the scope of this document. -- 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 (21 April 1998) is 9495 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: 'RFC2256' is mentioned on line 130, but not defined ** Obsolete undefined reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) == Unused Reference: 'CHARSET' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'RFC1630' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RFC2047' is defined on line 542, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CHARSET' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIMEDIR' ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Downref: Normative reference to an Informational RFC: RFC 1630 ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) -- Duplicate reference: RFC2047, mentioned in 'RFC2047', was also mentioned in 'MIME'. ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) Summary: 16 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT C. Apple 3 AT&T Labs 4 Expires: October 21, 1998 21 April 1998 6 Requirements for the Initial Release of a Directory Schema Listing Service 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), or ftp.isi.edu (US West Coast). 26 Abstract 28 This memo documents requirements for listing directory services 29 schema in a centrally operated, administered, and maintained 30 repository. This repository will be available as a resource to 31 directory protocol and service implementors to facilitate schema 32 discovery. 34 Table of Contents 36 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . 3 37 1.1 Scope. . . . . . . . . . . . . . . . . . . . . . . . . 3 38 1.2 Terms and Definitions. . . . . . . . . . . . . . . . . 4 39 1.3 Usage Scenarios. . . . . . . . . . . . . . . . . . . . 5 40 1.3.1 Location/Retrieval of the vCard Schema for LDAPv3. . 5 41 1.3.2 Submission of a New Schema Listing via SMTP. . . . . 5 42 2.0 Listing Service Requirements . . . . . . . . . . . . . 6 43 2.1 Functional Requirements. . . . . . . . . . . . . . . . 6 44 2.2 Operational Requirements . . . . . . . . . . . . . . . 6 45 2.3 Repository Access Functionality. . . . . . . . . . . . 7 46 3.0 Listing Service Namespace Requirements . . . . . . . . 8 47 4.0 Listing Requirements . . . . . . . . . . . . . . . . . 8 48 5.0 Listing Storage Requirements . . . . . . . . . . . . . 9 49 6.0 Security Considerations. . . . . . . . . . . . . . . . 9 50 6.1 Compromisable Assets . . . . . . . . . . . . . . . . . 9 51 6.2 Attack Scenarios . . . . . . . . . . . . . . . . . . . 9 52 6.2.1 Denial-of-Service Attack Scenarios . . . . . . . . . 10 53 6.2.2 Confuse-the-User Attack Scenarios. . . . . . . . . . 10 54 6.3 Security Requirements on Schema Listing Procedures . . 10 55 7.0 Acknowledgements . . . . . . . . . . . . . . . . . . . 11 56 8.0 References . . . . . . . . . . . . . . . . . . . . . . 12 57 9.0 Author's Address . . . . . . . . . . . . . . . . . . . 13 59 1.0 Introduction 61 The fastest route to interoperable directory services is through 62 standard object classes and attribute types. There is a growing 63 number of places where schema for Internet Directory Services and 64 Internet Operations are being defined, with varying degrees of 65 documentation. This plethora of schema is unavoidable in the light 66 of the needs of different service communities, but it makes it 67 difficult for directory service builders to find and make use of an 68 existing schema that will serve their needs and increase 69 interoperability with other systems. A listing service providing a 70 single point of discovery for directory service schema will promote 71 schema reuse, reduce duplication of effort, and thus promote 72 directory service interoperability. 74 The intent is to offer a schema listing service with public read 75 access and restricted, moderated write access. Many hard-coded 76 choices and constraints have been reflected in this requirements 77 document for the purpose of expediting deployment. Future releases of 78 the service may require an update of this document. 80 Initially, such a listing service will be centrally operated, 81 administered, and maintained. The schema listing repository database 82 may also be mirrored to ensure some level of redundancy for read 83 access in the event of service interruption. Eventually, the 84 operations, administration, and maintenance of such a listing service 85 may evolve to use a more distributed deployment scenario. 87 The schema listing service is also intended to be largely automated, 88 with minimal human involvement. Human involvement is likely to be 89 limited to the following types of activities: 91 + handling repository access problems 92 + trouble resolution for computing and communications facilities 93 + dealing with reasonable requests that fall outside 94 of the scope of normal schema listing repository operations 95 + reviewing schema listing requests on a mailing list 96 prior to publishing in the listing repository 98 Future releases of the service may automate some of these tasks. 100 1.1 Scope 102 Requirements for the initial release of a directory schema listing 103 service are inside the scope of this document. 105 Specifications for syntaxes and grammars to be used in the initial 106 release of the directory schema listing service are outside the scope 107 of this document. 109 Documentation of schema listing procedures is outside the scope of 110 this document. 112 1.2 Terms and Definitions 114 Information Object - a descriptive abstraction of some real-world 115 object 117 Object Attribute - a descriptive property of an information object; 118 typically, object attributes are defined in terms of semantic and 119 syntactic definitions 121 Schema - a collection of definitions for related information objects 123 Schema Unit - a related or grouped set of object attributes that form 124 a discrete unit within the context of a schema for a particular 125 protocol; examples include an LDAP object class or a WHOIS++ template 127 Schema Pak - a related or grouped set of schema units that 128 collectively specify a schema associated with a particular protocol; 129 an example of a schema pak is the set of LDAP object classes 130 specified in [RFC2256] 132 Metadata - characteristics that differentiate one schema unit or 133 schema pak from another; used to catalog listing service content; 134 structured using a profile of [MIMEDIR]; also contains references to 135 files stored within and outside of a listing repository 137 Schema Unit Content - a formal specification of a schema unit using a 138 profile of [MIMEDIR] 140 Schema Unit Listing - the combination of a single schema unit content 141 file intended for use within the context of a particular protocol and 142 a file containing metadata describing the schema unit specified 143 within that schema unit content file 145 Schema Pak Listing - a single metadata file containing information 146 describing and referring to a set of related or grouped schema unit 147 content files 149 Repository - a database in which listings are stored 151 Listing Request - a proposed schema unit listing or schema pak 152 listing formatted using [MIME] constructs that is submitted for 153 consideration as a listing to be published in a repository 154 Operator - an organization that administers and maintains a 155 repository 157 Primary Repository - the repository that masters the schema listings 158 database 160 Shadow Repository - a repository that mirrors the primary repository 162 Contact Person - the name of the individual who holds the authority 163 to update a listing and who should be contacted if questions or 164 concerns arise related to a listing or listing request 166 Listing Authority Contact - the name of the individual who holds 167 authority to replace a contact person; can be either the contact 168 person for a listing or an alternate contact within the organization 169 to which the contact person belongs (this allows one person 170 organizations to list schema) 172 The terms for specifying requirement level defined in [RFC2119] are 173 used in this document. 175 1.3 Usage Scenarios 177 1.3.1 Location/Retrieval of the vCard Schema for LDAPv3 179 A user of the schema listing service wants to locate a copy of the 180 vCard schema for LDAPv3 [RFC2251] so that they can use it in a 181 prototyping project. First, they point their web browser at a schema 182 listing repository web site and download the list of available 183 schema. Next, they use the search command on their browser to locate 184 occurances of the string "vCard". The browser automatically scrolls 185 down to the appropriate place in the list of available schema and the 186 user clicks on a link to view the listing metadata to verify that 187 this is indeed the vCard schema for use with version 3 of the LDAP 188 protocol. Included in the web-based representation of the listing 189 metadata are ftp URLs pointing to available profiles containing 190 listing content for this schema. The user clicks on the link for the 191 profile that they can use. 193 1.3.2 Submission of a New Schema Listing via SMTP 195 A schema writer wishes to list a schema they have created and 196 prepares the listing metadata and listing content according to one or 197 more appropriate [MIMEDIR] profiles. The schema writer will obtain a 198 permanent, unique schema listing name for the request. 200 The schema writer sends an SMTP message including the listing meta 201 data and all available listing content in multipart-related [MIME] 202 format to a listing request review mailing list. After a short review 203 period, the listing repository operator validates the request, and if 204 properly formed, publishes the listing according to the listing 205 procedures. An announcement of the newly published schema listing is 206 sent to a mailing list reserved for this purpose. 208 2.0 Listing Service Requirements 210 2.1 Functional Requirements 212 Listed schema MAY be published as an RFC. 214 A list of available listings MUST be maintained. 216 Listings MUST be named according to the namespace requirements 217 defined in section 3. 219 The listing service SHALL maintain information about schema units, 220 beyond their definition. This information is referred to as metadata 221 and will consist of information used for cataloging listings in the 222 repositories. The particular set of metadata elements used during 223 the initial deployment of the listing service will be defined in 224 other documents. 226 Listing metadata and listing content MUST be parsable. 228 2.2 Operational Requirements 230 The process of listing schema MUST be centralized for the initial 231 deployment. 233 All versions of all listings MUST be retained. A simple method for 234 getting the most recent version of a particular listing MUST be 235 provided. 237 The contact person for a listing MAY give an earlier listing a higher 238 version number, or MAY request that the listing get a new name. 240 The listing repository MUST be centrally administered. 242 The listing repository MAY be mirrored. 244 The primary repository operator MUST obtain an OID subtree for which 245 they hold sub-allocation authority for use in the schema listing 246 service. 248 Listing requests MAY be signed using PGP/MIME as described in 249 [RFC2015]. The primary listing repository operator MUST be able to 250 accept schema listing requests in PGP/MIME messages, although they 251 are NOT REQUIRED to validate the signatures. The method for 252 validating and determining trust of signatures is outside the scope 253 of this document and is determined by the parties in the exchange. 254 The method for determining and validating trust in an unsigned 255 request is outside the scope of this document, as is the method for 256 determining trust in schema listing repository or its content. 258 A mailing list MUST be created for the purpose of submitting listing 259 requests for review prior to publishing in the schema listing 260 repository. The schema listing repository publication process MUST be 261 moderated via this mailing list. Listing requests MUST be subjected 262 to community review on this mailing list for a period of at least 2 263 weeks. If no comments are received, properly formed schema listing 264 requests SHALL be published as listings; otherwise, the request MAY 265 either denied or the listing MAY published subject to incorporation 266 of comments. 268 A mailing list MUST be created for announcing new and updated 269 listings. 271 A mailbox MUST be created for the purpose of receiving service 272 trouble requests from users. 274 Listing repository operators (of primary and shadow sites) MUST 275 provide a free means of accessing the listing service consistent with 276 the functionality documented in paragraph 2.3. 278 2.3 Repository Access Functionality 280 The following schema listing repository access protocols MUST be 281 supported: FTP [RFC959], HTTP 1.1 [RFC2068], and SMTP [RFC821]. 283 The following access functions are REQUIRED: 285 a) browse and retrieve schema unit content, 286 metadata, and a list of available listings: 288 + via HTTP requests 290 + via FTP clients 292 + via requests through an SMTP server 294 b) search a list of available listings: 296 + via HTTP, retrieving either HTML or text listings 297 that can then be searched by the requestor 299 + via HTTP by accessing repository-based searching 300 facilities such as keyword searching; this can 301 return listing names, schema unit listings, 302 schema pak listings, metadata, or other useful 303 information 305 c) add and update listings by submitting a formatted 306 request to a mailing list for community review: 308 + via SMTP using appropriate MIME constructs 309 as described in section 4.0 311 Other access functions, including the following, MAY be supported, 312 but will be defined in other documents in the future: 314 a) search schema unit content 316 b) search metadata 318 3.0 Listing Service Namespace Requirements 320 The listing service namespace MUST be protocol-independent. 322 The listing service namespace SHALL be based on OIDs. 324 Listing names: 326 + MUST be permanent 328 + MUST be globally unique 330 + MUST be publicly available 332 + MUST NOT be recycled or re-used 334 + MUST be created within the OID subtree reserved for use 335 in the schema listing service and administered by the 336 primary listing repository operator 338 4.0 Listing Requirements 340 Schema unit content SHALL be limited to the information actually 341 required to specify and encode the schema for storage and transfer. 343 Metadata SHALL be composed of information used to catalog listings. 345 Metadata element syntax SHALL be defined based on the concept of 346 tagged attribute type-value pairs. 348 Language tags as specified in [RFC1766] MUST be used in all listings. 350 Metadata element values MUST be encoded using the UCS Transformation 351 Format - 8 bit form [RFC2044]. 353 For the purposes of submitting a listing request, schema unit content 354 and metadata SHOULD be structured according to appropriate profiles 355 of [MIMEDIR] defined in other documents. 357 Content associated with a listing, but not stored in the schema 358 listing repository (such as large copyright notices and vendor logo 359 images) MAY be included by reference in the metadata. If such 360 external references are included in a particular schema listing, a 361 fingerprint of the external content generated prior to schema listing 362 request creation MUST be included along with these references in the 363 request. Details associated with the creation of these external 364 content references, including the algorithm to be used for generation 365 of a content fingerprint and the syntax of the reference, will be 366 defined in the [MIMEDIR] profile used to format and encode listing 367 metadata for storage and transfer. 369 5.0 Listing Storage Requirements 371 Listing repository file names MUST be permanent, globally unique, and 372 publicly available. 374 Listing repository file names SHOULD be constructed in a manner that 375 allows human and machine users to determine the nature of file 376 content by inspecting the file names. 378 Schema unit content and metadata MUST be stored in separate files. 380 6.0 Security Considerations 382 6.1 Compromisable Assets 384 One or more of the following assets could be compromised if the 385 service is attacked: 387 + Metadata 388 + Schema unit content 389 + Repository Hardware & Software 390 + Networking Facilities Connecting Repository to the Internet 391 + Repository Mirror Sites 393 6.2 Attack Scenarios 395 Allowable methods for submitting listing requests are: 397 a) sending an e-mail message to a mail box 399 b) submitting requests using web-based forms 401 Based on these request submission methods, there are a number of known 402 repository attack scenarios that must be considered during the 403 implementation of schema listing procedures and the software and 404 operational processes required to support them. 406 6.2.1 Denial-of-Service Attack Scenarios 408 Scenario A: someone could send in a large number of improperly formed 409 requests 411 Scenario B: someone could send in a large number of properly formed, but 412 frivolous, useless, or trivial requests 414 6.2.2 Confuse-the-User Attack Scenarios 416 Scenario A: someone could send in a large number of valid, but 417 frivolous, useless, or trivial requests and some or all of these 418 requests actually become listings in the repository 420 Scenario B: someone could maliciously submit one or more slightly 421 modified versions of existing listings which are popular or widely used 423 6.3 Security Requirements on Schema Listing Procedures 425 The following contextual definitions apply to the requirements listed in 426 the remainder of this paragraph: 428 Verification - a process of determining authenticity of facts implied or 429 explicitly specified by a contact person during the process of 430 submitting a schema listing request; the methods used to implement such 431 a process MAY or MAY NOT be based on an IETF-sanctioned security 432 protocol; specification of the methods used to implement such a process 433 as well as the trust relationships relevant to the process are outside 434 the scope of this document. 436 High-Quality Directory Schema - a directory schema that serves some 437 useful purpose (e.g., a related set of attribute and object class 438 definitions for holding information about people in a LDAP directory); a 439 schema that is _not_ merely trivial or frivolous (e.g., a trivial schema 440 might consist of a related set of attribute and object class definitions 441 for holding information about the two possible binary bit values in a 442 directory). 444 The schema listing procedures SHOULD be designed to enable: 446 a) verification that all properly formed schema 447 listing requests are submitted by the contact 448 person claiming to originate them 450 b) methods of ensuring that only properly-formed, 451 high-quality directory schema are published 452 in the schema listing repository 454 c) verifcation that requests to change the identity 455 of the contact person for a listing originate 456 from the listing authority contact or the contact 457 person 459 d) coping with the situation in which the contact 460 person and/or listing authority contact for 461 a schema is no longer available or is unable 462 to submit updates to the listing 463 for which they hold update authority 465 For the initial release of the service, there is NO REQUIREMENT on 466 any participant, user, or application to retain signature information 467 as it applies to an entire schema listing request. 469 Fingerprints included with external content reference metadata 470 elements MUST be retained and included in published listing request. 471 Users of the schema listing service SHOULD verify that fingerprints 472 of referenced content match corresponding fingerprints included with 473 external references as a part of the published schema listing. If 474 purported (included in the listing) and actual (computed by the user) 475 fingerprints are different, users of the service SHOULD consider the 476 possibility that the referenced content has changed since publication 477 of the schema listing and that such a change could affect the way in 478 which associated content can be used. 480 Referenced content is outside of the control of the schema listing 481 service. A caveat explaining this concept MUST be included in the 482 metadata of all published listings if external references are 483 included in corresponding listing requests. 485 7.0 Acknowledgements 487 Leslie Daigle of Bunyip Information Systems and Chris Weider of 488 Microsoft provided valuable comments on multiple versions of this 489 document. 491 The engineering team for listing service requirements: 493 Chris Apple - AT&T Labs 494 Sanjay Jain - Oracle 495 Michael Mealling - NSI 496 John Strassner - Cisco 497 Sam Sun - CNRI 498 Mark Wahl - Critical Angle 499 Chris Weider - Microsoft 501 Paul Hoffman, for review and comment during his effort to implement 502 the primary directory schema listing service platform. 504 The members of the ietf-schema-reg@imc.org mailing list. 506 8.0 References 508 [CHARSET] Internet Assigned Numbers Authority, "CHARACTER SETS", 509 . 511 [MIME] [RFC2045], [RFC2046], and [RFC2047]. 513 [MIMEDIR] T. Howes, M. Smith, "A MIME Content-Type for Directory 514 Information", INTERNET-DRAFT , 515 July 1997. 517 [RFC821] J. Postel, "Simple Mail Transfer Protocol", RFC 821, August 518 1982. 520 [RFC959] J. Postel, J.K. Reynolds, "File Transfer Protocol", RFC 959, 521 October 1985. 523 [RFC1630] T. Berners-Lee, "Universal Resource Identifiers in WWW", 524 RFC 1630, June 1994. 526 [RFC1766] H. Alvestrand, "Tags for the Identification of Languages", 527 RFC 1766, March 1995. 529 [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", 530 RFC 2015, October 1996. 532 [RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode and 533 ISO 10646", RFC 2044, October 1996. 535 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 536 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 537 2045, November 1996. 539 [RFC2046] N. Freed & N. Borenstein, "Multipurpose Internet Mail 540 Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. 542 [RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) 543 Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 544 November 1996. 546 [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- 547 Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 548 1997. 550 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 551 Requirement Level", RFC 2119, March 1997. 553 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 554 Protocol (Version 3)", RFC 2251, December 1997. 556 9.0 Author's Address 558 Chris Apple 559 AT&T Labs 560 600 - 700 Mountain Ave., Room 2F-165 561 Murray Hill, NJ 07974-0636 562 USA 564 E-Mail: capple@att.com 565 Phone: +1 908 582 2409 566 FAX: +1 908 582 3296 568 This INTERNET-DRAFT expires on October 21, 1998.