idnits 2.17.1 draft-wahl-know-mime-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-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 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 7 longer pages, the longest (page 3) being 62 lines 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 an Authors' Addresses Section. ** There are 92 instances of too long lines in the document, the longest one being 21 characters in excess of 72. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 21 has weird spacing: '...listing conta...' -- 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 (28 August 1996) is 10096 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 section? '7' on line 552 looks like a reference -- Missing reference section? '1' on line 534 looks like a reference -- Missing reference section? '2' on line 537 looks like a reference -- Missing reference section? '3' on line 539 looks like a reference -- Missing reference section? '4' on line 542 looks like a reference -- Missing reference section? '5' on line 545 looks like a reference -- Missing reference section? '6' on line 549 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Wahl 2 INTERNET-DRAFT Critical Angle Inc. 3 Expires in six months from 28 August 1996 5 Application/Directory Profile for LDAP and X.500 Knowledge 6 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 23 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 2. Abstract 27 This memo defines directory information profiles for representing 28 directory distribution knowledge for an X.500 or LDAP directory system, 29 to be carried in an application/directory MIME Content-Type. The 30 profiles consists of type definitions and the corresponding format of 31 values that each type is allowed to contain. They are designed for simple 32 generation and parsing by programs; the text-based format makes it 33 easier for developers and directory administrators to debug problems. 35 Additional documents will build on these specifications in defining 36 text-based protocols for distributed directory server administration. 38 3. Overview 40 The Internet White Pages Directory service currently is built from a 41 combination of X.500(88), X.500(93) and LDAP-capable servers. No 42 single server holds the entire directory tree, instead the tree is 43 partitioned among the servers. There are two basic ways that the naming 44 tree has been partitioned: 46 The first is the Entry Data Block, or "EDB" model, which is primarily 47 supported just by the QUIPU implementation. In this model, all the 48 immediate subordinates of a single entry in the tree, the context prefix, 49 are mastered together in a single server. The context prefix entry itself 50 is not part of the EDB, for it is part of the immediate superior EDB. 52 The second is the Naming Context model, supported by X.500-based 53 servers. In this model, an entry, the context prefix, and all its 54 subordinates down to either the leaves or references to subordinate 55 naming contexts are held in the same server. 57 It is expected that LDAP servers will follow the Naming Context model. 59 Knowledge is the information which describes the distribution of the 60 directory hierarchy. Each component of a servers' knowledge will 61 consist of the name of a context prefix, and the list of servers to 62 contact for progressing operations in the naming context identified 63 by that context prefix. 65 Operational bindings are defined in X.501 [7] are agreements between 66 a pair of servers. Hierarchical and Shadow operational bindings permit 67 the exchange of knowledge information. An operational binding is 68 identified by a number, unique between a pair of servers. 70 This document does not specify means to identify non-specific knowledge. 72 4. The Knowledge Profile 74 The profile is defined as follows, using the profile registration 75 template from [1]. 77 4.1. Profile Definition 79 To: ietf-mime-direct@umich.edu 80 Subject: Registration of application/directory MIME profile knowledge 82 Profile name: knowledge 84 Profile purpose: To hold information about hierarchical distribution 85 of a directory. 87 Profile types: NAME, ACCESSPOINT, BINDINGID 89 Profile special notes: 91 There are no ordering limitations on types within the content entity. 93 The default transfer encoding for the profile is 7-Bit, if only 94 US-ASCII equivalent characters are present in the content, otherwise 95 it is quoted printable or base64. 97 The default character set is ISO-10646-UTF-8 [2]. It is recommended 98 that this NOT be changed to any other character set. (UTF-8 is 99 chosen as this is the character set used in the LDAP protocol itself 100 for names and attributes. In allows for all the characters in 101 UniversalString without shifting character sets. This makes it very 102 easy for servers to handle.) 104 There is no default language. It is not expected that attributes in 105 this profile would be provided directly to end users. 107 The default location of the type values is inline with the profile 108 type. It is strongly recommended that no multimedia attributes be 109 present in contents with this profile. 111 Intended usage: COMMON 113 The associated type definitions follow, using the type registration 114 template from [1]. 116 4.2. Type definitions 118 4.2.1. NAME Type Definition 120 The NAME parameter, defined in [1], is used to convey the directory 121 name of the context prefix. There must be exactly one value of this 122 parameter in a content. 124 The value of this parameter is a UTF-8 string encoding of a Distinguished 125 Name, as defined in [3]. 127 The "PROTO" subtype parameter must be present, and its value must be "LDAP". 129 Type examples: 131 NAME;PROTO=LDAP: CN=Babs Jensen, O=Babsco, C=US 133 NAME;PROTO=LDAP: CN=#130442616273, O=#130442616273, C=US 135 4.2.2. ACCESSPOINT Type Definition 137 The ACCESSPOINT parameter is used to convey the means of access for 138 this naming context. There must be at least one value of this parameter 139 in a context. 141 The value of this parameter is encoded according to the following BNF: 143 ::= '#' '#' 145 ::= | -- or absent 147 ::= 'master' | 'shadow' | 'gateway' | 'cache' | -- or absent 149 ::= | 150 | 151 | 152 | 153 155 ::= 'X500' '#' '#' 156 [ '#' ] 158 ::= | 159 '(' ')' 161 ::= | 162 '$' 163 165 ::= 'QUIPU' '#' 167 ::= | 169 ::= 'LDAP' '#' [ ] '#' 171 ::= 'SSL-LDAP' '#' [ ] '#' 172 ::= 174 ::= [ ':' ] 176 ::= 'DNS' '#' 178 ::= 'URL' '#' 180 ::= -- a fully-qualifed domain name or an IP address 182 ::= -- a TCP or UDP port number 184 The encoding format of is given in [3], in [4], 185 in [5] and in [6]. 187 The field, if present, takes as a value an integer between 188 0 and 255 (inclusive). It permits the sender to suggest relative 189 preferences for the receiver to use when choosing between multiple values 190 of ACCESSPOINT in this content. In general, receivers should prefer 191 access points with smaller values of preference. If this field is absent, 192 the sender does not indicate any particular relative preference for this 193 value. 195 The field, if present, takes on the following values: 196 master: the server indicated in the access point holds the master 197 copy of entries in this naming context. 198 shadow: the server indicated in the access point holds a possibly 199 incomplete shadow copy of entries in this naming context. 200 gateway: substantial loss of content may occur if this server is 201 contacted. 202 cache: the server holds some information from this naming context 203 which may be out of date. 205 If the role field is absent, the sender does not indicate any particular 206 role for the server named in the access point. 208 The field specifies a single X.500 DSA. It contains 209 the DSA's Distinguished Name, presentation address, and an optional list 210 of protocol information. The DSA indicated will be able to perform 211 operations on all entries in the naming context (possibly by contacting 212 other servers or returning referrals). 214 The field specifies a single X.500 DSA by its 215 Distinguished Name. The presentation address of the DSA must be obtained 216 through other means, such as a content of profile "DSA". The DSA 217 indicated will be able to perform operations on entries subordinate to 218 the context prefix, but not on the context prefix entry itself. 220 The field specifies an LDAP server by its host name or 221 IP address, and optional port number. The default port number, 389 for 222 plain LDAP and 636 for SSL-LDAP, should be used if the port number is not 223 specified. The distinguished name of the server may optionally be provided. 224 This server will be able to perform operations on all entries in the naming 225 context (possibly by contacting other servers or returning referrals). 227 The field specifies a domain name system server by its 228 host name or IP address. The field specifies a server 229 based on its URL. These are not currently used but are reserved for 230 future extensibility. 232 Example: 234 AccessPoint: # # LDAP # # nameflow.dante.net 236 Further examples are given in section 6.1 and 6.2. 238 4.2.2.1. Why a URL is not being used 240 Not all the types of access described above have a URL scheme, and 241 additional information is associated as each of the access points 242 which are not part of today's URL definitions (such as preference). 244 "URL-Unsafe" characters such as spaces or non-ASCII characters are 245 extremely likely to occur in values, and that would lead to yet another 246 layer of quoting, even though the content itself might be using a 247 quoted-printable, base64 encoding. 249 Philsophically, there is no single "data resource", like a particular 250 entry, being identified in the access point. Instead the access point 251 could be used to access many different entries. 253 4.2.3. BINDINGID Parameter 255 This parameter should be present at most once in a content. Its value 256 is encoded according to the following BNF: 258 ::= [ '.' ] 260 ::= 262 ::= 264 For example, 266 BINDINGID: 100 268 BINDINGID: 100.10 270 This parameter is present only if there is an operational binding [7] 271 between the sender and recipient. 273 5. Related Profiles 275 A MIME message containing contents of the "knowledge" profile may 276 also carry contents with the "dsa", "subentry" or "cache-attributes" 277 profiles. Contents with these profiles may also be carried indpendently. 279 5.1. DSA Profile 281 A "DSA" profile is defined as follows, using the profile registration 282 template from [1]. 284 To: ietf-mime-direct@umich.edu 285 Subject: Registration of application/directory MIME profile DSA 287 Profile name: DSA 289 Profile purpose: To hold information about a Directory System Agent 290 (server). 292 Profile types: NAME, PRESENTATIONADDRESS, SUPPORTEDAPPLICATIONCONTEXT, 293 BINDINGID, LASTMODIFIEDTIME 295 Profile special notes: 297 There are no ordering limitations on types within the content entity. 299 The default transfer encoding for the profile is 7-Bit. 301 The default character set is ISO-10646-UTF-8 [2]. It is recommended 302 that this NOT be changed to any other character set. 304 There is no default language. It is not expected that attributes in 305 this profile would be provided directly to end users. 307 The default location of the type values is inline with the profile 308 type. It is strongly recommended that no multimedia attributes be 309 present in contents with this profile. 311 The following types are also likely to occur in this contents with 312 this profile, however their values are not used by the recipient: 313 CN, description, L, O, OU, seeAlso, knowledgeInformation, 314 lastModifiedBy 316 Intended usage: COMMON 318 The associated type definitions follow, using the type registration 319 template from [1]. 321 5.1.1. NAME Type Definition 323 The NAME parameter, defined in [1], is used to convey the directory 324 name of the server. There must be exactly one value of this 325 parameter in a content. 327 The value of this parameter is a UTF-8 string encoding of a Distinguished 328 Name, as defined in [3]. 330 The "PROTO" subtype parameter must be present, and its value must be "LDAP". 332 5.1.2. PRESENTATIONADDRESS Type Definition 334 The PRESENTATIONADDRESS parameter is used to convey the presentation address 335 of the server. There must be exactly one value of this parameter in a 336 content. 338 The value of this parameter is a Presentation Address as defined in [4]. 340 5.1.3. SUPPORTEDAPPLICATIONCONTEXT Type Definition 342 The SUPPORTEDAPPLICATIONCONTEXT parameter is used to convey the 343 application contexts supported by the server. There may be any number of 344 values of this parameter in a content. 346 The value of this parameter is a string representation of an OBJECT 347 IDENTIFIER, as described in [5]. 349 The following example values are among those likely to occur: 351 supportedApplicationContext: 2.5.3.1 -- directory access 352 supportedApplicationContext: 2.5.3.2 -- directory system 353 supportedApplicationContext: 2.5.3.4 -- shadow consumer initiated 354 supportedApplicationContext: 2.5.3.5 -- shadow supplier initiated 355 supportedApplicationContext: 0.9.2342.19200300.99.4 -- QUIPU DSP 356 supportedApplicationContext: 0.9.2342.19200300.100.8 -- Internet DSP 358 5.1.4. LASTMODIFIEDTIME Type Definition 360 The LASTMODIFIEDTIME parameter is used to convey the time this entry 361 was last modified. There may be at most one value of this parameter in 362 a content. 364 The value of the parameter is a UTCTime, as described in [5]. 366 5.2. Subentry Profile 368 A "SUBENTRY" profile is defined as follows, using the profile registration 369 template from [1]. 371 To: ietf-mime-direct@umich.edu 372 Subject: Registration of application/directory MIME profile SUBENTRY 374 Profile name: SUBENTRY 376 Profile purpose: To hold information from a subentry. 378 Profile types: NAME, BINDINGID, subtreeSpecification, CN, dseType, 379 entryACI, prescriptiveACI, 380 creatorsName, createTimestamp, modifiersName, modifyTimestamp, 381 dITStructureRules, nameForms, ditContentRules, objectClasses, 382 attributeTypes, matchingRules, matchingRuleUse, 383 collectiveLocalityName, collectiveStateOrProvinceName, 384 collectiveStreetAddress, collectiveOrganizationName, 385 collectiveOrganizationalUnitName, collectivePostalAddress, 386 collectivePostalCode, collectivePostOfficeBox, 387 collectivePhysicalDeliveryOfficeName, 388 collectiveTelephoneNumber, collectiveTelexNumber, 389 collectiveTeletexTerminalIdentifier, 390 collectiveFacsimileTelephoneNumber, 391 collectiveInternationaliSDNNumber 393 Profile special notes: 395 There are no ordering limitations on types within the content entity. 397 The default transfer encoding for the profile is 7-Bit. 399 The default character set is ISO-10646-UTF-8 [2]. It is recommended 400 that this NOT be changed to any other character set. 402 There is no default language. It is not expected that attributes in 403 this profile would be provided directly to end users. 405 The default location of the type values is inline with the profile 406 type. It is strongly recommended that no multimedia attributes be 407 present in contents with this profile. 409 Intended usage: COMMON 411 With the exception of NAME and BINDINGID, which are described above, 412 the rest of type parameters are those likely to be in subentries. They are 413 as described in [5]. 415 5.3. Attributes for Caching Profile 417 A "CACHE-ATTRIBUTES" profile is defined as follows, using the profile 418 registration template from [1]. 420 To: ietf-mime-direct@umich.edu 421 Subject: Registration of application/directory MIME profile CACHE-ATTRIBUTES 423 Profile name: CACHE-ATTRIBUTES 425 Profile purpose: To hold arbitrary attributes which may be cached 426 and used in matching search filters. 428 Profile types: NAME, BINDINGID, etc 430 Profile special notes: 432 There are no ordering limitations on types within the content entity. 434 The default transfer encoding for the profile is 7-Bit. 436 The default character set is ISO-10646-UTF-8 [2]. It is recommended 437 that this NOT be changed to any other character set. 439 There is no default language. 441 The default location of the type values is inline with the profile 442 type. It is strongly recommended that no multimedia attributes be 443 present in contents with this profile. 445 Intended usage: COMMON 447 With the exception of NAME and BINDINGID, which are described above, 448 the content may contain any attribute of [5] which the sender wishes to 449 have cached by the recipient. These could include administrativeRole, 450 accessControlScheme, objectClass, aliasedObjectName, description etc. 452 6. Examples 454 Section 6.1 is an example of what a server holding the naming context 455 "O=Foo,C=US" might send to the server holding the naming context "C=US", 456 in order to have the subordinate context added to the directory. Section 457 6.2 is an example of what the "C=US" server might return as a response. 459 6.1. 461 MIME-Version: 1.0 462 Content-Type: multipart/mixed; boundary="break" 463 Content-Description: information about O=Foo,C=US 465 --break 466 Content-Type: application/directory; profile="knowledge"; charset="iso-10646-utf-8" 468 Name;PROTO=LDAP: O=Foo, C=US 469 AccessPoint: # master # LDAP # CN=Server, O=Foo, C=US # server.foo.com 470 --break 471 Content-Type: application/directory; profile="cache-attributes"; charset="iso-10646-utf-8" 473 Name;PROTO=LDAP: O=Foo, C=US 474 O: Foo 475 Description: Makers of the Foo line of Widgets 476 --break-- 477 6.2. 479 MIME-Version: 1.0 480 Content-Type: multipart/mixed; boundary="break" 481 Content-Description: information about O=Foo,C=US and superiors 483 --break 484 Content-Type: application/directory; profile="knowledge"; charset="iso-10646-utf-8" 486 Name;PROTO=LDAP: 487 AccessPoint: # gateway # LDAP # # nameflow.dante.net 488 --break 489 Content-Type: application/directory; profile="knowledge"; charset="iso-10646-utf-8" 491 Name;PROTO=LDAP: C=US 492 AccessPoint: 30 # master # QUIPU # CN=EDB Beetle 493 AccessPoint: 10 # shadow # X500 # CN=U,C=US # "X500"/Internet=us.net+19999 494 AccessPoint: 20 # gateway # LDAP # # nameflow.dante.net 495 --break 496 Content-Type: application/directory; profile="DSA"; charset="iso-10646-utf-8" 498 Name;PROTO=LDAP: CN=EDB Beetle 499 Description: the Endangered EDB-only Beetle 500 Description: supports DAP, DSP, IDSP and QDSP 501 PresentationAddress: "X500"/Internet=us.net+17003 502 SupportedApplicationContext: 2.5.3.1 503 SupportedApplicationContext: 2.5.3.2 504 SupportedApplicationContext: 0.9.2342.19200300.99.4 505 SupportedApplicationContext: 0.9.2342.19200300.100.8 506 --break 507 Content-Type: application/directory; profile="knowledge"; charset="iso-10646-utf-8" 509 Name;PROTO=LDAP: O=Foo, C=US 510 AccessPoint: 0 # master # LDAP # CN=Server, O=Foo, C=US # server.foo.com 511 AccessPoint: 128 # gateway # X500 # CN=U,C=US # "X500"/Internet=us.net+19999 512 --break 513 Content-Type: application/directory; profile="cache-attributes"; charset="utf8" 515 Name;PROTO=LDAP: C=US 516 C: US 517 CO: United States of America 518 Description: Land of the Free 519 Description: Home of the Brave 520 --break-- 522 7. Security Considerations 524 Internet mail is subject to many well known security attacks, including 525 monitoring, replay, and forgery. Care should be taken by any directory 526 service in allowing information to leave the scope of the service 527 itself, where any access controls can no longer be guaranteed. 529 Applications should also take care to display directory data in a "safe" 530 environment (e.g., PostScript-valued types). 532 8. Bibliography 534 [1] T. Howes, M. Smith, "A MIME Content-Type for Directory Information", 535 INTERNET DRAFT , August 1996. 542 [4] S. Kille, "A String Representation for Presentation Addresses", 543 RFC 1278, University College London, November 1991. 545 [5] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "LDAP Standard and Pilot 546 Attribute Definitions", INTERNET DRAFT 547 , August 1996. 549 [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource 550 Locations (URL)", RFC 1738, December 1994. 552 [7] The Directory: Models. ITU-T Recommendation X.501, 1993. 554 Expires: February 28, 1997