idnits 2.17.1 draft-ietf-asid-ldapv2-attributes-00.txt: ** The Abstract section seems to be numbered 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-24) 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 14 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) ** There are 38 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([3], [9], [1,2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? '9' on line 663 looks like a reference -- Missing reference section? '1' on line 636 looks like a reference -- Missing reference section? '2' on line 641 looks like a reference -- Missing reference section? '3' on line 644 looks like a reference -- Missing reference section? '5' on line 650 looks like a reference -- Missing reference section? '6' on line 653 looks like a reference -- Missing reference section? '10' on line 666 looks like a reference -- Missing reference section? '8' on line 660 looks like a reference -- Missing reference section? '7' on line 656 looks like a reference -- Missing reference section? '4' on line 647 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tim Howes 2 INTERNET-DRAFT University of Michigan 3 Steve Kille 4 ISODE Consortium 5 Wengyik Yeong 6 Performance Systems International 7 Colin Robbins 8 NeXor Ltd. 9 Mark Wahl 10 ISODE Consortium 12 The String Representation of Standard Attribute Syntaxes 13 15 1. Status of this Memo 17 This draft document will be submitted to the RFC Editor as a standards 18 document. Distribution of this memo is unlimited. Please send comments 19 to the authors, or the discussion group . 21 This document is an Internet-Draft. Internet-Drafts are working docu- 22 ments of the Internet Engineering Task Force (IETF), its areas, and its 23 working groups. Note that other groups may also distribute working 24 documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference material 29 or to cite them other than as ``work in progress.'' 31 To learn the current status of any Internet-Draft, please check the 32 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 33 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 34 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 36 2. Abstract 38 The Lightweight Directory Access Protocol (LDAP) [9] requires that the 39 contents of AttributeValue fields in protocol elements be octet strings. 40 This document defines the requirements that must be satisfied by encod- 41 ing rules used to render X.500 Directory attribute syntaxes into a form 42 suitable for use in the LDAP, then goes on to define the encoding rules 43 for the standard set of attribute syntaxes defined in [1,2] and [3]. 45 Syntax Encoding May 1996 47 3. Attribute Syntax Encoding Requirements. 49 This section defines general requirements for lightweight directory pro- 50 tocol attribute syntax encodings. All documents defining attribute syn- 51 tax encodings for use by the lightweight directory protocols are 52 expected to conform to these requirements. 54 The encoding rules defined for a given attribute syntax must produce 55 octet strings. To the greatest extent possible, encoded octet strings 56 should be usable in their native encoded form for display purposes. In 57 particular, encoding rules for attribute syntaxes defining non-binary 58 values should produce strings that can be displayed with little or no 59 translation by clients implementing the lightweight directory protocols. 61 4. Table of LDAP Attributes 63 This section lists all Attribute Type names defined for this version of 64 LDAP. Servers may support additional names and attributes not listed 65 here by bilateral agreement. 67 4.1. Standard User Attributes 69 The attributes listed in this section are those defined in X.520(1988), 70 likely to be present in user entries. 72 Attribute Type Name OID Syntax 73 ==================== =============== ================ 74 objectClass 2.5.4.0 OID 75 aliasedObjectName 2.5.4.1 DN 76 knowledgeInformation 2.5.4.2 caseIgnoreString 77 cn 2.5.4.3 caseIgnoreString 78 sn 2.5.4.4 caseIgnoreString 79 serialNumber 2.5.4.5 PrintableString 80 c 2.5.4.6 CountryString 81 l 2.5.4.7 caseIgnoreString 82 st 2.5.4.8 caseIgnoreString 83 street 2.5.4.9 caseIgnoreString 84 o 2.5.4.10 caseIgnoreString 85 ou 2.5.4.11 caseIgnoreString 86 title 2.5.4.12 caseIgnoreString 87 description 2.5.4.13 caseIgnoreString 88 searchGuide 2.5.4.14 Guide 89 businessCategory 2.5.4.15 caseIgnoreString 90 postalAddress 2.5.4.16 PostalAddress 91 postalCode 2.5.4.17 caseIgnoreString 92 postOfficeBox 2.5.4.18 caseIgnoreString 93 physicalDeliveryOfficeName 2.5.4.19 caseIgnoreString 94 telephoneNumber 2.5.4.20 TelephoneNumber 96 Syntax Encoding May 1996 98 telexNumber 2.5.4.21 TelexNumber 99 teletexTerminalIdentifier 2.5.4.22 TeletexTerminalIdentifier 100 facsimileTelephoneNumber 2.5.4.23 FacsimileTelephoneNumber 101 x121Address 2.5.4.24 NumericString 102 internationaliSDNNumber 2.5.4.25 NumericString 103 registeredAddress 2.5.4.26 PostalAddress 104 destinationIndicator 2.5.4.27 PrintableString 105 preferredDeliveryMethod 2.5.4.28 DeliveryMethod 106 presentationAddress 2.5.4.29 PresentationAddress 107 supportedApplicationContext 2.5.4.30 OID 108 member 2.5.4.31 DN 109 owner 2.5.4.32 DN 110 roleOccupant 2.5.4.33 DN 111 seeAlso 2.5.4.34 DN 112 userPassword 2.5.4.35 Password 113 userCertificate 2.5.4.36 Certificate 114 cACertificate 2.5.4.37 Certificate 115 authorityRevocationList 2.5.4.38 CertificateList 116 certificateRevocationList 2.5.4.39 CertificateList 117 crossCertificatePair 2.5.4.40 CertificatePair 119 4.2. Pilot User Attributes 121 These attributes are defined in RFC 1274. 123 Attribute Type Name OID Syntax 124 ==================== =============================== ================ 125 uid 0.9.2342.19200300.100.1.1 CaseIgnoreString 126 textEncodedORaddress 0.9.2342.19200300.100.1.2 CaseIgnoreString 127 mail 0.9.2342.19200300.100.1.3 CaseIgnoreIA5String 128 info 0.9.2342.19200300.100.1.4 CaseIgnoreString 129 drink 0.9.2342.19200300.100.1.5 CaseIgnoreString 130 roomNumber 0.9.2342.19200300.100.1.6 CaseIgnoreString 131 photo 0.9.2342.19200300.100.1.7 Fax 132 userClass 0.9.2342.19200300.100.1.8 CaseIgnoreString 133 host 0.9.2342.19200300.100.1.9 CaseIgnoreString 134 manager 0.9.2342.19200300.100.1.10 DN 135 documentIdentifier 0.9.2342.19200300.100.1.11 CaseIgnoreString 136 documentTitle 0.9.2342.19200300.100.1.12 CaseIgnoreString 137 documentVersion 0.9.2342.19200300.100.1.13 CaseIgnoreString 138 documentAuthor 0.9.2342.19200300.100.1.14 DN 139 documentLocation 0.9.2342.19200300.100.1.15 CaseIgnoreString 140 homePhone 0.9.2342.19200300.100.1.20 TelephoneNumber 141 secretary 0.9.2342.19200300.100.1.21 DN 142 otherMailbox 0.9.2342.19200300.100.1.22 OtherMailbox 143 lastModifiedTime 0.9.2342.19200300.100.1.23 UTCTime 144 lastModifiedBy 0.9.2342.19200300.100.1.24 DN 146 Syntax Encoding May 1996 148 dc 0.9.2342.19200300.100.1.25 CaseIgnoreIA5String 149 dNSRecord 0.9.2342.19200300.100.1.26 IA5String 150 mXRecord 0.9.2342.19200300.100.1.28 IA5String 151 nSRecord 0.9.2342.19200300.100.1.29 IA5String 152 sOARecord 0.9.2342.19200300.100.1.30 IA5String 153 cNAMERecord 0.9.2342.19200300.100.1.31 IA5String 154 associatedDomain 0.9.2342.19200300.100.1.37 CaseIgnoreIA5String 155 associatedName 0.9.2342.19200300.100.1.38 DN 156 homePostalAddress 0.9.2342.19200300.100.1.39 PostalAddress 157 personalTitle 0.9.2342.19200300.100.1.40 CaseIgnoreString 158 mobile 0.9.2342.19200300.100.1.41 TelephoneNumber 159 pager 0.9.2342.19200300.100.1.42 TelephoneNumber 160 co 0.9.2342.19200300.100.1.43 CaseIgnoreString 161 organizationalStatus 0.9.2342.19200300.100.1.45 CaseIgnoreString 162 janetMailbox 0.9.2342.19200300.100.1.46 CaseIgnoreIA5String 163 mailPreferenceOption 0.9.2342.19200300.100.1.47 MailPreference 164 buildingName 0.9.2342.19200300.100.1.48 CaseIgnoreString 165 personalSignature 0.9.2342.19200300.100.1.53 Fax 166 dITRedirect 0.9.2342.19200300.100.1.54 DN 167 audio 0.9.2342.19200300.100.1.55 Audio 168 documentPublisher 0.9.2342.19200300.100.1.56 CaseIgnoreString 169 jpegPhoto 0.9.2342.19200300.100.1.60 JPEG 171 5. Standard Attribute Syntax Encodings 173 For the purposes of defining the encoding rules for the standard attri- 174 bute syntaxes, the following auxiliary BNF definitions will be used: 176 ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | 177 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | 178 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' | 179 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | 180 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | 181 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z' 183 ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' 185 ::= | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 186 'A' | 'B' | 'C' | 'D' | 'E' | 'F' 188 ::= | | '-' 190

::= | | ''' | '(' | ')' | '+' | ',' | '-' | '.' | 191 '/' | ':' | '?' | ' ' 193 ::= The ASCII newline character with hexadecimal value 0x0A 195 ::= | 197 Syntax Encoding May 1996 199 ::= | 201 ::= | 203 ::= | 205 ::=

|

207 ::= ' ' | ' ' 209 5.1. Undefined 211 This syntax is to be used for any values whose syntax is not defined by 212 another section of this document. Values of type Undefined are encoded 213 as if they were values of type Octet String, with the string value being 214 the BER-encoded version of the value. 216 5.2. Case Ignore String 218 A string of type caseIgnoreStringSyntax is encoded as the string value 219 itself. 221 5.3. Case Exact String 223 The encoding of a string of type caseExactStringSyntax is the string 224 value itself. 226 5.4. Printable String 228 The encoding of a string of type printableStringSyntax is the string 229 value itself. 231 5.5. Numeric String 233 The encoding of a string of type numericStringSyntax is the string value 234 itself. 236 5.6. Octet String 238 The encoding of a string of type octetStringSyntax is the string value 239 itself. 241 5.7. Case Ignore IA5 String 243 The encoding of a string of type caseIgnoreIA5String is the string value 244 itself. 246 Syntax Encoding May 1996 248 5.8. IA5 String 250 The encoding of a string of type iA5StringSyntax is the string value 251 itself. 253 5.9. T61 String 255 The encoding of a string of type t61StringSyntax is the string value 256 itself. 258 5.10. Case Ignore List 260 Values of type caseIgnoreListSyntax are encoded according to the follow- 261 ing BNF: 263 ::= | 264 '$' 266 ::= a string encoded according to the rules for Case 267 Ignore String as above. 269 5.11. Case Exact List 271 Values of type caseExactListSyntax are encoded according to the follow- 272 ing BNF: 274 ::= | 275 '$' 277 ::= a string encoded according to the rules for Case 278 Exact String as above. 280 5.12. Distinguished Name 282 Values of type distinguishedNameSyntax are encoded to have the represen- 283 tation defined in [5]. 285 5.13. Boolean 287 Values of type booleanSyntax are encoded according to the following BNF: 289 ::= "TRUE" | "FALSE" 291 Boolean values have an encoding of "TRUE" if they are logically true, 292 and have an encoding of "FALSE" otherwise. 294 Syntax Encoding May 1996 296 5.14. Integer 298 Values of type integerSyntax are encoded as the decimal representation 299 of their values, with each decimal digit represented by the its charac- 300 ter equivalent. So the digit 1 is represented by the character '1', the 301 digit 2 is represented by the character '2' and so on. 303 5.15. Object Identifier 305 Values of type objectIdentifierSyntax are encoded according to the fol- 306 lowing BNF: 308 ::= | '.' | 310 ::= 312 ::= | '.' 314 In the above BNF, is the syntactic representation of an object 315 descriptor. When encoding values of type objectIdentifierSyntax, the 316 first encoding option should be used in preference to the second, which 317 should be used in preference to the third wherever possible. That is, in 318 encoding object identifiers, object descriptors (where assigned and 319 known by the implementation) should be used in preference to numeric 320 oids to the greatest extent possible. For example, in encoding the 321 object identifier representing an organizationName, the descriptor 322 ``organizationName'' is preferable to ``ds.4.10'', which is in turn 323 preferable to the string ``2.5.4.10''. 325 5.16. Telephone Number 327 Values of type telephoneNumberSyntax are encoded as if they were Print- 328 able String types. 330 5.17. Telex Number 332 Values of type telexNumberSyntax are encoded according to the following 333 BNF: 335 ::= '$' '$' 337 ::= 339 ::= 341 ::= 343 In the above, is the syntactic representation of the number 344 Syntax Encoding May 1996 346 portion of the TELEX number being encoded, is the TELEX 347 country code, and is the answerback code of a TELEX terminal. 349 5.18. Teletex Terminal Identifier 351 Values of type teletexTerminalIdentifier are encoded according to the 352 following BNF: 354 ::= 0*('$' ) 356 ::= ':' 358 ::= 'graphic' | 'control' | 'misc' | 'page' | 'private' 360 ::= 362 In the above, the first is the encoding of the first 363 portion of the teletex terminal identifier to be encoded, and the subse- 364 quent 0 or more are subsequent portions of the 365 teletex terminal identifier. 367 5.19. Facsimile Telephone Number 369 Values of type FacsimileTelephoneNumber are encoded according to the 370 following BNF: 372 ::= [ '$' ] 374 ::= | '$' 376 ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' | 377 'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed' 379 In the above, the first is the actual fax number, and 380 the tokens represent fax parameters. 382 5.20. Presentation Address 384 Values of type PresentationAddress are encoded to have the representa- 385 tion described in [6]. 387 5.21. UTC Time 389 Values of type uTCTimeSyntax are encoded as if they were Printable 390 Strings with the strings containing a UTCTime value. 392 Syntax Encoding May 1996 394 5.22. Guide (search guide) 396 Values of type Guide, such as values of the searchGuide attribute, are 397 encoded according to the following BNF: 399 ::= [ '#' ] 401 ::= an encoded value of type objectIdentifierSyntax 403 ::= | | '!' 405 ::= [ '(' ] '&' [ ')' ] | 406 [ '(' ] '|' [ ')' ] 408 ::= [ '(' ] '$' [ ')' ] 410 ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX" 412 5.23. Postal Address 414 Values of type PostalAddress are encoded according to the following BNF: 416 ::= | '$' 418 In the above, each component of a postal address value is 419 encoded as a value of type t61StringSyntax. 421 5.24. User Password 423 Values of type userPasswordSyntax are encoded as if they were of type 424 octetStringSyntax. 426 5.25. User Certificate 428 Values of type userCertificate are encoded according to the following 429 BNF: 431 ::= '#' '#' 432 '#' '#' '#' 433 '#' '#' 435 ::= 437 ::= 439 ::= 441 Syntax Encoding May 1996 443 ::= an encoded Distinguished Name 445 ::= '#' 447 ::= 449 ::= 451 ::= | | 452 '{ASN}' 454 ::= an encoded Distinguished Name 456 ::= '#' 458 ::= | '-' 460 ::= '#' 462 ::= an encoded UTCTime value 464 ::= | 466 Note that this certificate format is appropriate for reading, but cannot 467 be guaranteed to be verifiable. This is because the string DN format 468 used to encode the issuer and subject portions of the certificate does 469 not produce a completely reversible encoding (i.e., one cannot always 470 produce the original DER-encoded certificate from its string representa- 471 tion). By bilateral agreement, sites are free to exchange native DER- 472 encoded certificates that can be verified, but via an attribute type 473 name other than "userCertificate" or "caCertificate". 475 5.26. CA Certificate 477 Values of type cACertificate are encoded as if the values were of type 478 userCertificate. 480 5.27. Authority Revocation List 482 Values of type authorityRevocationList are encoded according to the fol- 483 lowing BNF: 485 ::= '#' '#' 486 [ '#' ] 487 '#' 488 '#' 490 ::= 1*( '#' ) 492 Syntax Encoding May 1996 494 '#' 496 ::= '#' '#' 497 '#' 499 The syntactic components , , 500 , , and have the same 501 definitions as in the BNF for the userCertificate attribute syntax. 503 Note that as with the "User Certificate" syntax above, values encoded in 504 this syntax are not guaranteed to be verifiable. Also, servers which 505 implement or gateway to Directory systems supporting the 1993 or later 506 editions of the X.500 specifications may not be able to generate or 507 parse LDAP authority or certificate revocation lists, as the format 508 described in this section (based on the 1988 edition of X.509) is not 509 compatible with the syntax of X.509(1993). 511 5.28. Certificate Revocation List 513 Values of type certificateRevocationList are encoded as if the values 514 were of type authorityRevocationList. 516 5.29. Cross Certificate Pair 518 Values of type crossCertificatePair are encoded according to the follow- 519 ing BNF: 521 ::= '#' 522 | 523 | 525 ::= 'forward:' 527 ::= 'reverse:' 529 The syntactic component has the same definition as in the 530 BNF for the userCertificate attribute syntax. 532 Note that as with the "User Certificate" syntax above, values encoded in 533 this syntax are not guaranteed to be verifiable. Also, servers which 534 implement or gateway to Directory systems supporting the 1993 or later 535 editions of the X.500 specifications may not be able to generate or 536 parse LDAP authority or certificate revocation lists, as the format 537 described in this section (based on the 1988 edition of X.509) is not 538 compatible with the syntax of X.509(1993). 540 Syntax Encoding May 1996 542 5.30. Delivery Method 544 Values of type deliveryMethod are encoded according to the following 545 BNF: 547 ::= | '$' 549 ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' | 550 'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone' 552 5.31. Other Mailbox 554 Values of the type otherMailboxSyntax are encoded according to the fol- 555 lowing BNF: 557 ::= '$' 559 ::= an encoded Printable String 561 ::= an encoded IA5 String 563 In the above, represents the type of mail system in which 564 the mailbox resides, for example "Internet" or "MCIMail"; and 565 is the actual mailbox in the mail system defined by . 567 5.32. Mail Preference 569 Values of type mailPreferenceOption are encoded according to the follow- 570 ing BNF: 572 ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS" 574 5.33. MHS OR Address 576 Values of type MHS OR Address are encoded as strings, according to the 577 format defined in [10]. 579 5.34. Distribution List Submit Permission 581 Values of type DLSubmitPermission are encoded as strings, according to 582 the following BNF: 584 ::= ':' 585 | ':' 587 ::= 'group_member' 589 Syntax Encoding May 1996 591 ::= 593 ::= an encoded Distinguished Name 595 ::= 'individual' | 'dl_member' | 'pattern' 597 ::= 599 ::=

'#' 600 |
602
::= ':' 604 ::= ':' 606 = 'X400' 608 = 'X500' 610 where is as defined in RFC 1327. 612 5.35. Photo 614 Values of type Photo are encoded as if they were octet strings contain- 615 ing JPEG images in the JPEG File Interchange Format (JFIF), as described 616 in [8]. 618 5.36. Fax 620 Values of type Fax are encoded as if they were octet strings containing 621 Group 3 Fax images as defined in [7]. 623 6. Security Considerations 625 Security considerations are not discussed in this document. 627 7. Acknowledgements 629 Many of the attribute syntax encodings defined in this document are 630 adapted from those used in the QUIPU X.500 implementation. The contribu- 631 tions of the authors of the QUIPU implementation in the specification of 632 the QUIPU syntaxes [4] are gratefully acknowledged. 634 8. Bibliography 636 [1] The Directory: Selected Attribute Syntaxes. CCITT, Recommendation 637 X.520 639 Syntax Encoding May 1996 641 [2] Information Processing Systems -- Open Systems Interconnection -- 642 The Directory: Selected Attribute Syntaxes 644 [3] The COSINE and Internet X.500 Schema. Paul Barker, Steve Kille; 645 Request for Comment (RFC) 1274 647 [4] The ISO Development Environment: User's Manual -- Volume 5: QUIPU. 648 Colin Robbins, Stephen E. Kille 650 [5] A String Representation of Distinguished Names. Steve Kille, RFC 651 1779 653 [6] A String Representation for Presentation Addresses. Steve Kille; 654 Request for Comment (RFC) 1278 656 [7] Terminal Equipment and Protocols for Telematic Services - Standard- 657 ization of Group 3 facsimile apparatus for document transmission. 658 CCITT, Recommendation T.4 660 [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C-Cube 661 Microsystems, Milpitas, CA, September 1, 1992 663 [9] Lightweight Directory Access Protocol. Wengyik Yeong, Tim Howes, 664 Steve Kille, Request for Comment (RFC) XXXX 666 [10] Mapping between X.400 and RFC-822 Message Bodies. H. Alvestrand, 667 S. Kille, R. Miles, M. Rose, S. Thompson, Request for Comment 668 (RFC) 1495 670 9. Author's Addresses 672 Tim Howes 673 University of Michigan 674 ITD Research Systems 675 535 W William St. 676 Ann Arbor, MI 48103-4943 677 USA 678 +1 313 747-4454 679 tim@umich.edu 681 Steve Kille 682 ISODE Consortium 683 The Dome, The Square 684 Richmond 685 TW9 1DT 686 UK 687 +44-181-332-9091 688 S.Kille@isode.com 690 Syntax Encoding May 1996 692 Wengyik Yeong 693 PSI Inc. 694 510 Huntmar Park Drive 695 Herndon, VA 22070 696 USA 697 +1 703-450-8001 698 yeongw@psilink.com 700 Colin Robbins 701 NeXor Ltd 702 University Park 703 Nottingham 704 NG7 2RD 705 UK 707 Mark Wahl 708 ISODE Consortium Inc. 709 3925 West Braker Lane, Suite 333 710 Austin, TX 78759 711 USA 712 +1 512-305-0280 713 M.Wahl@isode.com