idnits 2.17.1 draft-good-ldap-ldif-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 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 are 16 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 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: attrval-spec = attribute-description ((":") / (":" *SPACE value) / ("::" *SPACE base64-value) / (":<" *SPACE url)) url = ; (See Note 6, below) attribute-description = value = 1*safe-initval *safe safe = safe-initval = base64-value = -- 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 (2 November 1998) is 9307 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '3' is defined on line 469, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 478, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 484, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-asid-mime-direct-06 ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1779 (ref. '3') (Obsoleted by RFC 2253, RFC 3494) ** Obsolete normative reference: RFC 2251 (ref. '4') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 1521 (ref. '5') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1738 (ref. '6') (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LDAP Data Interchange Format (LDIF) Gordon Good 3 INTERNET-DRAFT Netscape Communications 4 2 November 1998 6 The LDAP Data Interchange Format (LDIF) - Technical Specification 7 Filename: draft-good-ldap-ldif-01.txt 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 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 This Internet Draft expires May 1st, 1999. 31 Abstract 33 This document describes a file format suitable for describing 34 directory information or modifications made to directory information. 35 The file format, known as LDIF, for LDAP Data Interchange Format, is 36 typically used to import and export directory information between 37 LDAP-based directory servers, or to describe a set of changes which 38 are to be applied to a directory. 40 Background and Intended Usage 42 There are a number of situations where a common interchange format is 43 desirable. For example, one might wish to export a copy of the 44 contents of a directory server to a file, move that file to a 45 different machine, and import the contents into a second directory 46 server. 48 Additionally, by using a well-defined interchange format, development 49 of data import tools from legacy systems is facilitated. A fairly 50 simple set of tools written in awk or perl can, for example, convert 51 a database of personnel information into an LDIF file, which can then 52 be imported into a directory server, regardless of the internal 53 database representation the target directory server uses. 55 The LDIF format was originally developed and used in the University 56 of Michigan LDAP implementation. The first use of LDIF was in 57 describing directory entries. Later, the format was expanded to 58 allow representation of changes to directory entries. 60 Relationship to the application/directory MIME content-type: 62 The application/directory MIME content-type [1] is a general 63 framework and format for conveying directory information, and is 64 independent of any particular directory service. It is preferred, in 65 most cases, to LDIF, for conveying directory information. The LDIF 66 format is a simpler format which is perhaps easier to create, and 67 also may be used, as noted, to describe a set of changes to be 68 applied to a directory. 70 The key words "MUST", "MAY", and "SHOULD" used in this document are 71 to be interpreted as described in [7]. 73 Definition of the LDAP Data Interchange Format 75 The LDIF format is used to convey directory information, or a 76 description of a set of changes made to directory entries. An LDIF 77 file consists of a series of records separated by line separators. A 78 record consists of a sequence of lines describing a directory entry, 79 or a sequence of lines describing a set of changes to a single 80 directory entry. An LDIF file specifies a set of directory entries, 81 or a set of changes to be applied to directory entries, but not both. 83 There is a one-to-one correlation between LDAP operations which 84 modify the directory (add, delete, modify, and modrdn), and the types 85 of changerecords described below ("add", "delete", "modify", and 86 "modrdn" or "moddn"). This correspondence is intentional, and 87 permits a straightforward translation from LDIF changerecords to 88 protocol operations. 90 Formal Syntax Definition of LDIF 92 The following definition uses the augmented Backus-Naur Form 93 specified in RFC 822 [2]. 95 ldif-file = ldif-content / ldif-changes 96 ldif-content = 0,1*(version-spec 1*SEP) 97 ldif-attrval-record *(1*SEP ldif-attrval-record) 98 ldif-changes = 0,1*(version-spec 1*SEP) 99 ldif-change-record *(1*SEP ldif-change-record) 100 ldif-attrval-record = dn-spec SEP 1*(attrval-spec SEP) 101 ldif-change-record = dn-spec SEP 1*(changerecord SEP) 103 version-spec = "version:" *SPACE version-number 104 version-number = 1*DIGIT ; version-number MUST be "1" for the 105 ; LDIF format described in this document. 107 dn-spec = ("dn:" *SPACE dn) / ("dn::" *SPACE base64-dn) 108 dn = 109 base64-dn = 111 rdn = 113 base64-rdn = 116 attrval-spec = attribute-description ((":") / (":" *SPACE value) / 117 ("::" *SPACE base64-value) / 118 (":<" *SPACE url)) 119 url = 120 ; (See Note 6, below) 121 attribute-description = 124 value = 1*safe-initval *safe 125 safe = 126 safe-initval = 129 base64-value = 131 changerecord = change-add / change-delete / change-modify / 132 change-moddn 133 change-add = "changetype:" *SPACE "add" 1*(SEP attrval-spec) 134 change-delete = "changetype:" *SPACE "delete" 135 change-moddn = "changetype:" *SPACE ("modrdn" / "moddn") SEP 136 ("newrdn:" *SPACE rdn / 137 "newrdn::" *SPACE base-64-rdn) SEP 138 "deleteoldrdn:" *SPACE ("0" / "1") 139 0,1*(SEP (("newsuperior:" *SPACE dn) / 140 ("newsuperior:: *SPACE base-64-dn))) 141 change-modify = "changetype:" *SPACE "modify" 1*(SEP mod-spec) 142 mod-spec = mod-add-spec / mod-delete-spec / mod-replace-spec 143 mod-add-spec = "add:" *SPACE attribute-description 144 1*(SEP attrval-spec) SEP "-" 145 mod-delete-spec = "delete:" *SPACE attribute-description 146 *(SEP attrval-spec) SEP "-" 147 mod-replace-spec = "replace:" *SPACE attribute-description 148 *(SEP attrval-spec) SEP "-" 149 SPACE = 150 SEP = (CR LF / LF) 151 CR = 152 LF = 153 DIGIT = 155 Notes on LDIF Syntax 157 1) The version number is optional. If absent, version 0 is assumed, 158 which corresponds to the version of LDIF supported by the University 159 of Michigan ldap-3.3 reference implementation [8]. For the LDIF 160 format described in this document, the version number MUST be "1". 162 2) Any line in an LDIF file MAY be wrapped by inserting a line 163 separator (SEP) and a SPACE. Any line which begins with a single 164 space MUST be treated as a continuation of the previous line. 166 3) Any line which begins with a pound-sign ("#", ASCII 35) is a 167 comment line, and MUST be ignored when parsing an LDIF file. 169 4) Any dn or value which contains characters other than those defined 170 as "safe," or begins with a character other than those defined as 171 "safe-initval", above, MUST be base-64 encoded. Other values MAY be 172 base-64 encoded. 174 5) To represent a zero-length attribute value, use an attrval-spec of 175 "attribute-description:". For example, "seeAlso:" represents a 176 zero-length "seeAlso" attribute value. 178 6) When a URL is specified in an attrval-spec, the following 179 conventions apply: 180 a) Implementations SHOULD support the file:// URL format. The 181 contents of the referenced file are to be included verbatim 182 in the interpreted output of the LDIF file. 183 b) Implementations MAY support other URL formats. The semantics 184 associated with each supported URL will be documented in 185 an associated Applicability Statement. 187 7) While it is permissible for character values larger than 126 to be 188 contained in an attribute value, implementations SHOULD base-64 189 encode any value which contains such characters when generating LDIF. 191 However, implementations MAY leave the values unencoded. This 192 relaxation is designed to allow editing of LDIF files containing 193 UTF-8 data. 195 8) Attribute values contained in LDIF files represent directory data, 196 and therefore MUST be valid UTF-8 strings. Implementations which read 197 LDIF MAY interpret files in which the values are stored in some other 198 character set encoding, but implementations MUST NOT generate LDIF 199 content which does not contain valid UTF-8 data. 201 Differences from previous versions of this document 203 Differences between draft-ietf-asid-ldif-00.txt and draft-ietf-asid- 204 ldif-01.txt 206 1) The BNF has been modified to explicitly disallow ldif content and 207 change records in the same file. In other words, a given LDIF file 208 is either a series of directory entries, or a series of 209 modifications. An LDIF file MUST NOT contain both types of records. 211 2) External references are now URLs, instead of simple filenames. 213 3) The BNF has been modified to allow base-64-encoded distinguished 214 names. 216 4) Multiple separators are now permitted between records. 218 Differences between draft-ietf-asid-ldif-01.txt and draft-ietf-asid- 219 ldif-02.txt 221 1) The BNF has been modified such that a simple attribute name 222 ("attrname") has been replaced with an "attribute-description" as 223 defined in the LDAPv3 protocol document [4]. This permits language 224 codes and other attribute options to be carried in an LDIF file. 226 2) A new option, "charset", may be used in attribute descriptions. 227 This facilitates multi-lingual character set conversion. 229 3) The definition of the "safe" and "safe-initval" productions has 230 been relaxed to allow non-ASCII characters with values greater than 231 126. This permits more natural expression of character sets such as 232 Latin-1 in LDIF files. 234 Differences between draft-ietf-asid-ldif-02.txt and draft-good-ldap- 235 ldif-00.txt 237 1) The "charset-option" and "charset-name" productions were removed 238 from the BNF, due to objections within the working group. UTF-8 is 239 the only character set which may be used in LDIF. 241 2) Examples were reworked to reflect the above change, and to include 242 an example of a non-western language represented in UTF-8. 244 Differences between draft-ietf-asid-ldif-00.txt and draft-good-ldap- 245 ldif-01.txt 247 1) Added version identifiers to the examples - they were missing. 249 2) Clarified that LDIF file must use UTF-8. 251 Examples of LDAP Data Interchange Format 253 Example 1: An simple LDAP file with two entries 255 version: 1 256 dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US 257 objectclass: top 258 objectclass: person 259 objectclass: organizationalPerson 260 cn: Barbara Jensen 261 cn: Barbara J Jensen 262 cn: Babs Jensen 263 sn: Jensen 264 uid: bjensen 265 telephonenumber: +1 408 555 1212 266 description: A big sailing fan. 268 dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US 269 objectclass: top 270 objectclass: person 271 objectclass: organizationalPerson 272 cn: Bjorn Jensen 273 sn: Jensen 274 telephonenumber: +1 408 555 1212 276 Example 2: A file containing an entry with a folded attribute value 278 version: 1 279 dn:cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US 280 objectclass:top 281 objectclass:person 282 objectclass:organizationalPerson 283 cn:Barbara Jensen 284 cn:Barbara J Jensen 285 cn:Babs Jensen 286 sn:Jensen 287 uid:bjensen 288 telephonenumber:+1 408 555 1212 289 description:Babs is a big sailing fan, and travels extensively in search of 290 perfect sailing conditions. 291 title:Product Manager, Rod and Reel Division 293 Example 3: A file containing a base-64-encoded value 295 version: 1 296 dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US 297 objectclass: top 298 objectclass: person 299 objectclass: organizationalPerson 300 cn: Gern Jensen 301 cn: Gern O Jensen 302 sn: Jensen 303 uid: gernj 304 telephonenumber: +1 408 555 1212 305 description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVlIGlzIGJ 306 hc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdGVyIGluIGl0ICh 307 hIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQgb3V0IG1vcmUu 309 Example 4: A file containing an entries with UTF-8-encoded attribute 310 values, including language tags. Comments indicate the contents 311 of UTF-8-encoded attributes and distinguished names. 313 version: 1 314 dn:: b3U95Za25qWt6YOoLG89QWlyaXVz 315 # dn:: ou=,o=Airius 316 objectclass: top 317 objectclass: organizationalUnit 318 ou:: 5Za25qWt6YOo 319 # ou:: 320 ou;lang-ja:: 5Za25qWt6YOo 321 # ou;lang-ja:: 322 ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2 323 # ou;lang-ja:: 324 ou;lang-en: Sales 325 description: Japanese office 327 dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz 328 # dn:: uid=,ou=,o=Airius 329 userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM= 330 objectclass: top 331 objectclass: person 332 objectclass: organizationalPerson 333 objectclass: inetOrgPerson 334 uid: rogasawara 335 mail: rogasawara@airius.co.jp 336 givenname;lang-ja:: 44Ot44OJ44OL44O8 337 # givenname;lang-ja:: 338 sn;lang-ja:: 5bCP56yg5Y6f 339 # sn;lang-ja:: 340 cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA== 341 # cn;lang-ja:: 342 title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw== 343 # title;lang-ja:: 344 preferredlanguage: ja 345 givenname:: 44Ot44OJ44OL44O8 346 # givenname:: 347 sn:: 5bCP56yg5Y6f 348 # sn:: 349 cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA== 350 # cn:: 351 title:: 5Za25qWt6YOoIOmDqOmVtw== 352 # title:: 353 givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8 354 # givenname;lang-ja;phonetic:: 355 356 sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ 357 # sn;lang-ja;phonetic:: 358 cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA== 359 # cn;lang-ja;phonetic:: 360 title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg== 361 # title;lang-ja;phonetic:: 362 givenname;lang-en: Rodney 363 sn;lang-en: Ogasawara 364 cn;lang-en: Rodney Ogasawara 365 title;lang-en: Sales, Director 367 Example 5: A file containing a reference to an external file 369 version: 1 370 dn: cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US 371 objectclass: top 372 objectclass: person 373 objectclass: organizationalPerson 374 cn: Horatio Jensen 375 cn: Horatio N Jensen 376 sn: Jensen 377 uid: hjensen 378 telephonenumber: +1 408 555 1212 379 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg 380 Example 6: A file containing a series of change records and comments 382 version: 1 383 # Add a new entry 384 dn: cn=Fiona Jensen, ou=Marketing, o=Ace Industry, c=US 385 changetype: add 386 objectclass: top 387 objectclass: person 388 objectclass: organizationalPerson 389 cn: Fiona Jensen 390 sn: Jensen 391 uid: fiona 392 telephonenumber: +1 408 555 1212 393 jpegphoto:< file:///usr/local/directory/photos/fiona.jpg 395 # Delete an existing entry 396 dn: cn=Robert Jensen, ou=Marketing, o=Ace Industry, c=US 397 changetype: delete 399 # Modify an entry's relative distinguished name 400 dn: cn=Paul Jensen, ou=Product Development, o=Ace Industry, c=US 401 changetype: modrdn 402 newrdn: cn=Paula Jensen 403 deleteoldrdn: 1 405 # Rename an entry and move all of its children to a new location in 406 # the directory tree (only implemented by LDAPv3 servers). 407 dn: ou=PD Accountants, ou=Product Development, o=Ace Industry, c=US 408 changetype: modrdn 409 newrdn: ou=Product Development Accountants 410 deleteoldrdn: 0 411 newsuperior: ou=Accounting, o=Ace Industry, c=US 413 # Modify an entry: add an additional value to the postaladdress attribute, 414 # completely delete the description attribute, replace the telephonenumber 415 # attribute with two values, and delete a specific value from the 416 # facsimiletelephonenumber attribute 417 dn: cn=Paula Jensen, ou=Product Development, o=Ace Industry, c=US 418 changetype: modify 419 add: postaladdress 420 postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086 421 - 422 delete: description 423 - 424 replace: telephonenumber 425 telephonenumber: +1 408 555 1234 426 telephonenumber: +1 408 555 5678 427 - 428 delete: facsimiletelephonenumber 429 facsimiletelephonenumber: +1 408 555 9876 430 - 432 Security Considerations 434 Given typical directory applications, an LDIF file is likely to 435 contain sensitive personal data. Appropriate measures should be 436 taken to protect the privacy of those persons whose data is contained 437 in an LDIF file. 439 Since ":<" directives can cause external content to be included when 440 processing an LDIF file, one should be cautious of accepting LDIF 441 files from external sources. A "trojan" LDIF file could name a file 442 with sensitive contents and cause it to be included in a directory 443 entry, which a hostile entity could read via LDAP. 445 LDIF does not provide any method for carrying authentication 446 information with an LDIF file. Users of LDIF files must take care to 447 verify the integrity of an LDIF file received from an external 448 source. 450 Acknowledgments 452 The LDAP Interchange Format was developed as part of the University 453 of Michigan LDAP reference implementation, and was developed by Tim 454 Howes, Mark Smith, and Gordon Good. It is based in part upon work 455 supported by the National Science Foundation under Grant No. NCR- 456 9416667. 458 References 460 [1] Howes, T., Smith, M., "A MIME Content-Type for Directory Infor- 461 mation", INTERNET-DRAFT draft-ietf-asid-mime-direct-06.txt, 462 Netscape Communications Corp., 465 [2] Crocker, D.H., "Standard for the Format of ARPA Internet Text 466 Messages", RFC 822, University of Delaware, August 1982, 467 469 [3] Kille, S., "A String Representation of Distinguished Names", RFC 470 1779, ISODE Consortium, March 1995, 471 473 [4] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access 474 Protocol (v3)", RFC 2251, Critical Angle, Inc., ISODE Consor- 475 tium, Netscape Communications Corp., July, 1997, 476 478 [5] Borenstein, N., Freed, N., "MIME (Multipurpose Internet Mail 479 Extensions) Part One: Mechanisms for Specifying and Describing 480 the Format of Internet Message Bodies", section 5.2, "Base64 481 Content-Transfer-Encoding", RFC 1521, Bellcore, Innosoft, 482 December 1993, 484 [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource 485 Locators (URL)", CERN, Xerox Corporation, University of Min- 486 nesota, Request for Comment (RFC) 1738, December 1994, 487 489 [7] S. Bradner, "Key Words for use in RFCs to Indicate Requirement 490 Levels", Harvard University, RFC 2119, March 1997, 491 493 [8] The SLAPD and SLURPD Administrators Guide. University of Michi- 494 gan, April 1996. 497 Author's Address 499 Gordon Good 500 Netscape Communications Corp. 501 501 E. Middlefield Rd. 502 Mailstop MV068 503 Mountain View, CA 94043, USA 504 Phone: +1 650 937-3825 505 EMail: ggood@netscape.com 507 This Internet Draft expires May 1st, 1999.