idnits 2.17.1 draft-ietf-asid-mime-direct-04.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-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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 27) being 69 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 303 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 10 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 139: '...part. It SHOULD NOT be used to exclude...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...fts are worki...' == Line 13 has weird spacing: '...ments of the ...' == Line 14 has weird spacing: '...t other group...' == Line 18 has weird spacing: '...and may be ...' == Line 22 has weird spacing: '...atus of any ...' == (298 more instances...) -- 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? 'RFC-2045' on line 67 looks like a reference -- Missing reference section? 'RFC-2046' on line 1277 looks like a reference -- Missing reference section? 'RFC-1777' on line 1263 looks like a reference -- Missing reference section? 'RFC-1778' on line 1266 looks like a reference -- Missing reference section? 'RFC-1835' on line 1297 looks like a reference -- Missing reference section? 'X500' on line 1290 looks like a reference -- Missing reference section? 'RFC-1872' on line 1287 looks like a reference -- Missing reference section? 'RFC-2048' on line 1280 looks like a reference -- Missing reference section? 'MIME-VCARD' on line 760 looks like a reference -- Missing reference section? 'RFC-822' on line 1270 looks like a reference -- Missing reference section? 'RFC 2046' on line 234 looks like a reference -- Missing reference section? 'DATETIME' on line 1303 looks like a reference -- Missing reference section? 'RFC-1766' on line 1284 looks like a reference -- Missing reference section? 'RFC-1738' on line 1300 looks like a reference -- Missing reference section? 'RFC-1521' on line 1273 looks like a reference -- Missing reference section? 'VCARD' on line 1310 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tim Howes 3 Request for Comments: DRAFT Mark Smith 4 draft-ietf-asid-mime-direct-04.txt Netscape Communications Corp. 5 July, 1997 7 A MIME Content-Type for Directory Information 8 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference material 20 or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 2. Abstract 30 This document defines a MIME Content-Type for holding directory informa- 31 tion. The definition is independent of any particular directory service 32 or protocol. The text/directory Content-Type is defined for holding a 33 variety of directory information, for example, name, or email address, 34 or logo. The text/directory Content-Type can also be used as the root 35 body part in a multipart/related Content-Type for handling more compli- 36 cated situations, especially those in which non-textual information that 37 already has a natural MIME representation, for example, a photograph or 38 sound, must be represented. 40 The text/directory Content-Type defines a general framework and format 41 for holding directory information in a simple "type: value" form. 42 Mechanisms are defined to specify alternate character sets, languages, 43 encodings and other meta-information. This document also defines the 44 procedure by which particular formats, called profiles, for carrying 45 application-specific information within a text/directory Content-Type 46 may be defined and registered, and the conventions such formats must 47 Expires in six months INTERNET DRAFT 49 follow. It is expected that other documents will be produced that define 50 such formats for various applications (e.g., white pages). 52 3. Need for a MIME Directory Type 54 For purposes of this document, a directory is a special-purpose database 55 that contains typed information. A directory usually supports both read 56 and search of the information it contains, and may support modification 57 of the information as well. Directory information is usually accessed 58 far more often than it is updated. Directories may be local or global 59 in scope. They may be distributed or centralized. The information they 60 contain may be replicated, with weak or strong consistency requirements. 62 There are several situations in which users of Internet mail may wish to 63 exchange directory information: the email analogy of a "business card" 64 exchange; the conveyance of directory information to a user having only 65 email access to the Internet; the provision of machine-parseable address 66 information when purchasing goods or services over the Internet; etc. As 67 MIME [RFC-2045,RFC-2046] is used increasingly by other protocols, most 68 notably HTTP, it may also be useful for these protocols to be able to 69 carry directory information in MIME format. Such a format, for example, 70 could be used to represent URC (uniform resource characteristics) infor- 71 mation about resources on the World Wide Web, or to provide a rudimen- 72 tary directory service over HTTP. 74 4. Overview 76 The scheme defined here for representing directory information in a MIME 77 Content-Type has two parts. First, the text/directory Content-Type is 78 defined for use in holding directory information within a single body 79 part, for example name, title, or email address. In its simplest form, 80 the format uses a "type: value" approach, which should be easily pars- 81 able by existing MIME implementations and understandable by users. More 82 complicated situations can be represented also. This document defines 83 the general form the information in the Content-Type should have, and 84 the procedure by which specific types and values (properties) for par- 85 ticular applications may be defined. The framework is general enough to 86 handle information from any number of end directory services, including 87 LDAP [RFC-1777, RFC-1778], WHOIS++ [RFC-1835], and X.500 [X500]. 89 Directory entries can include far more than just textual information. 90 Some such information (e.g., an image or sound) overlaps with predefined 91 MIME Content-Types. In these cases it may be desirable to include the 92 information in its well-known MIME format. This situation is handled by 93 using a multipart/related Content-Type as defined in [RFC-1872]. The 94 root component of this type is a text/directory body part specifying any 95 in-line information, and for information contained in other Content- 96 Types, the Content-IDs (in URI form) of those types. 98 Expires in six months INTERNET DRAFT 100 In some applications, it may be useful to include a pointer (e.g, a URI) 101 to some directory information rather than the information itself. This 102 document defines a general mechanism for accomplishing this. 104 5. The text/directory Content-Type 106 The text/directory Content-Type is used to hold basic directory informa- 107 tion, URIs referencing other information, including other MIME body 108 parts holding supplementary or non-textual directory information, such 109 as an image or sound. It is defined as follows, using the MIME media 110 type registration template from [RFC-2048]. 112 To: ietf-types@uninett.no 113 Subject: Registration of MIME media type text/directory 115 5.1. MIME media type name 117 MIME media type name: text 119 5.2. MIME subtype name 121 MIME subtype name: directory 123 5.3. Required parameters 125 Required parameters: charset 127 The "charset" parameter is as defined in [RFC-2046] for other body 128 parts. It is used to identify the default character set used within the 129 body part. 131 5.4. Optional parameters 133 Optional parameters: profile 135 The "profile" parameter is used to convey the type(s) of entity(ies) to 136 which the directory information pertains and the likely set of informa- 137 tion associated with the entity(ies). It is intended only as a guide to 138 applications interpreting the information contained within the body 139 part. It SHOULD NOT be used to exclude or require particular pieces of 140 information unless a profile definition specifically calls for this 141 behavior. Unless specifically forbidden by a particular profile defini- 142 tion, a text/directory content type may contain arbitrary 143 attribute/value pairs. 145 The value of the "profile" parameter is defined as follows. Profile 146 names are case insensitive (i.e., the profile name "Person" is the same 147 as "PERSON" and "person" and "peRsOn"). 149 Expires in six months INTERNET DRAFT 151 profile := x-token / iana-token 153 x-token := 157 iana-token := 161 5.5. Encoding considerations 163 The default encoding is 8bit. Otherwise, as specified by the Content- 164 Transfer-Encoding header field. Note that each value may also have an 165 inline encoding associated with it. This encoding is independent of the 166 encoding for the body part as a whole. When encoding, inline per-value 167 encodings are performed first, then Content-Transfer-Encoding is applied 168 to the entire body part. When decoding, the Content-Transfer-Encoding 169 for the entire body part is decoded, then any value-specific encodings 170 are decoded. 172 5.6. Security considerations 174 Directory information may be public or it may be protected from unau- 175 thorized access by the directory service in which it resides. Once the 176 information leaves its native service, there can be no guarantee that 177 the same care will be taken by all services handling the information. 178 Furthermore, this specification defines no access control mechanism by 179 which information may be protected, or by which access control informa- 180 tion may be conveyed. Note that the integrity and privacy of a 181 text/directory body part may be protected by enclosing it within an 182 appropriate MIME-based security mechanism. 184 5.7. Interoperability considerations 186 In order to make sense of directory information, applications must share 187 a common understanding of the types of information contained within the 188 Content-Type (the directory schema). This schema information is not 189 defined in this document, but rather in companion documents (e.g., 190 [MIME-VCARD]) that follow the requirements specified in this document, 191 or in bilateral agreements between communicating parties. 193 5.8. Published specification 195 The text/directory Content-Type contains directory information, typi- 196 cally pertaining to a single directory entity or group of entities. The 197 content consists of one or more lines in the format given below. 199 Expires in six months INTERNET DRAFT 201 5.8.1. Line delimiting and folding 203 Individual lines within the MIME text/directory Content Type body are 204 delimited by the [RFC-822] line break, which is a CRLF sequence (ASCII 205 decimal 13, followed by ASCII decimal 10). Long logical lines of text 206 can be split into a multiple-physical-line representation using the fol- 207 lowing folding technique. 209 A logical line may be continued on the next physical line at any point 210 by inserting a CRLF immediately followed by a single white space charac- 211 ter (space, ASCII decimal 32, or horizontal tab, ASCII decimal 9). Any 212 sequence of CRLF followed immediately by a single white space character 213 is ignored (removed) when processing the content type. For example the 214 line: 216 DESCRIPTION:This is a long description that exists on a long line. 218 Can be represented as: 220 DESCRIPTION:This is a long description 221 that exists on a long line. 223 The process of moving from this folded multiple-line representation of a 224 type definition to its single line representation is called unfolding. 225 Unfolding is accomplished by regarding CRLF immediately followed by a 226 white space character as equivalent to no characters at all (i.e., the 227 CRLF and single white space character are removed). 229 A formatted text line break in an attribute value should also be speci- 230 fied by a (RFC 822) line break, which is a CRLF sequence. However, since 231 the CRLF sequence is used to delimit a content-type line, attribute 232 values with formatted line breaks (i.e., multiple lines) must be encoded 233 using an alternate encoding of either Quoted-Printable or Base64, as 234 defined in [RFC 2046]. 236 For example, in the Quoted-Printable encoding the multiple lines of for- 237 matted text are separated with a Quoted-Printable CRLF sequence of =0D 238 followed by =0A followed by a Quoted-Printable soft line break sequence 239 of =. Quoted-Printable lines of text must also be limited to less than 240 76 characters. The 76 characters does not include the CRLF [RFC 822] 241 line break sequence. For example a multiple line DESCRIPTION value of: 243 Mythical Manager 244 Hyjinx Software Division 245 BabsCo, Inc. 247 Would be represented in a Quoted-Printable encoding as: 249 Expires in six months INTERNET DRAFT 251 DESCRIPTION; encoding=QUOTED-PRINTABLE:Mythical Manager=0D=0A= 252 Hyjinx Software Division=0D=0A= 253 BabsCo, Inc. 255 5.8.2. BNF content-type definition 257 Using the notation of RFC 822, the syntax for this content is: 259 contentline := [group.]type [";" parameterlist] ":" valuespec 261 group := atom ; as defined in Section 3.3 of RFC 822 263 type := x-name 264 / iana-type 266 x-name := 269 iana-type := 273 parameterlist := parameter / parameterlist ";" parameter 275 parameter := encodingparm 276 / valuetypeparm 277 / languageparm 278 / contextparm 279 / [parmtype "="] parmvalues 281 encodingparm := "encoding" "=" encodingtype 283 encodingtype := "base64" ; from Section 6.8 of RFC 2045 284 / "quoted-printable" ; from Section 6.7 of RFC 2045 285 / "8bit" 286 / "7bit" 288 valuetypeparm := "value" "=" valuetype 290 valuetype := "uri" ; generic uri from RFC 1738 291 / "text" 292 / "date" 293 / "time" 294 / "date-time" ; date time 295 / "integer" 296 / "boolean" 297 / "float" 298 / x-name 299 Expires in six months INTERNET DRAFT 301 / iana-valuetype 303 iana-valuetype : = 307 languageparm := "language" "=" language ; as defined in RFC 1766 309 contextparm := "context" "=" context 311 context := iana-token ; a token registered with IANA 312 / x-name 314 parmtype := x-name 315 / iana-parmtype 317 iana-parmtype := 321 parmvalues := parmvalue 322 / parmvalues "," parmvalue 324 parmvalue := x-name 325 / iana-parmvalue 327 iana-parmvalue := 331 valuespec := *text ; Characters whose syntax depends on type and the 332 ; the encoding parameter. If the value contains 333 ; a CRLF sequence (ASCII 10 followed by 13), it must 334 ; be encoded using either base64 or quoted-printable. 335 / date-spec 336 / time-spec 337 / date-time-spec 338 / boolean 339 / integer 340 / float 341 / iana-valuespec 343 date-spec := date *[ "," date ] ; date as defined in [DATETIME] 345 time-spec := time *[ "," time ] ; time as defined in [DATETIME] 347 date-timed-spec := date time ; as above 348 Expires in six months INTERNET DRAFT 350 boolean := "TRUE" / "FALSE" 352 integer := [ sign ] 1*DIGIT *[ "," integer ] ; DIGIT as defined in RFC 822 354 float := [sign] 1*DIGIT ["." *DIGIT] *("," float) 356 sign := "+" / "-" 358 iana-valuespec := 362 To the left of the beginning of "value", white space characters (namely 363 HTABs and SPACEs, ASCII 9 and 32) may freely surround any symbol. Note 364 that this means that if a "value" begins with white space, it must be 365 encoded using either the base64 or quoted-printable methods. 367 A line that begins with a white space character is a continuation of the 368 previous line, as described above. The white space character and line- 369 ending CRLF should be discarded when reconstructing the original line. 370 Note that this line-folding convention differs from that found in RFC 371 822, in that the sequence found anywhere in 372 the content indicates a continued line and should be removed. 374 Since the CRLF sequence is used to separate lines within the content 375 type, if this sequence appears in a value, the value must be encoded 376 using either base64 or quoted-printable. 378 The meanings of the various type names and the format of the correspond- 379 ing values must be defined as specified in Section 11. Specifications 380 may impose ordering on the type constructs within a body part, though 381 none is required by default. The various x-name constructs are used for 382 bilaterally-agreed upon type names, parameter names and parameter 383 values. 385 Type names, parameter names, and parameter values (i.e., everything to 386 the left of the ":") are case insensitive (e.g., the type name "cn" is 387 the same as "CN" and "Cn"). 389 The group construct is used to group related attributes together. The 390 group name is a syntactic convention used to indicate that all type 391 names prefaced with the same group name should be grouped together when 392 displayed by an application. It has no other significance. Implementa- 393 tions that do not understand or support grouping may simply strip off 394 any text before a "." and present the types and values as normal. 396 Each attribute defined in the text/directory body may have multiple 397 values, if allowed in the definition of the profile in which the 398 Expires in six months INTERNET DRAFT 400 attribute is used. The general rule for encoding multi-valued items is 401 to simply create a new content line for each value (including the type 402 name). However, it should be noted that some value types may support 403 encoding multiple values in a single content line, for example by 404 separating the values with a comma "," or other delimiter. This 405 approach has been taken for several of the content types defined above 406 (date, time, integer, float), for space-saving reasons. 408 The "language" type parameter should be used to identify data in alter- 409 nate languages. There is no concept of "default" language, except as 410 specified by any "Content-Language" MIME header parameter that may be 411 present. The value of the "language" type parameter is a language tag as 412 defined in Section 2 of [RFC-1766]. 414 The "context" type parameter should be used to identify a context (e.g., 415 a protocol) used in interpreting the value. This is used, for example, 416 in the "name" type, defined below. 418 The "encoding" type parameter should be used to specify an alternate 419 encoding for a value. If the value contains a CRLF sequence (ASCII 10 420 followed by 13), it must be encoded using either "base64" or "quoted- 421 printable", since CRLF is used to separate lines in the content-type 422 itself. These encodings can also be useful for binary values that are 423 mixed with other text information in the body part (e.g., a certifi- 424 cate). Using a per-value "base64" or "quoted-printable" encoding in this 425 case leaves the other information in a more readable form. 427 The Content-Transfer-Encoding header field is used to specify the encod- 428 ing used for the body part as a whole. The "encoding" type parameter is 429 used to specify an encoding for a particular value (e.g., a certifi- 430 cate). In this case, the Content-Transfer-Encoding header might specify 431 "8bit", while the one certificate value might specify an encoding of 432 base64 via an "encoding=base64" type parameter. 434 Each type has associated with it a default encoding, which shall be used 435 in the absence of an overriding "encoding" type parameter. This default 436 encoding is given in the type definition, as defined in Section 11 of 437 this document. 439 The "value" parameter is optional, and may be used to identify the value 440 type (data type) and format of the value. The use of these predefined 441 formats is encouraged even if the value parameter is not explicity used. 442 By defining a standard set of value types and their formats, existing 443 parsing and processing code may be leveraged. 445 Including the value type explicitly as part of each property provides an 446 extra hint to keep parsing simple and support more generalized applica- 447 tions. For example a search engine would not have to know the 448 Expires in six months INTERNET DRAFT 450 particular value types for all of the items for which it is searching. 451 Because the value type is explicit in the definition, the search engine 452 could look for dates in any item type and provide good results. 454 5.8.3. Predefined value formats 456 Some specific notes on the value types and formats: 458 "text": The "text" value type should be used to identify values that 459 contain human-readable text. The character set and language in which the 460 text is represented is controlled by the charset content-header and the 461 language type parameters and content-header. 463 "uri": The "uri" value type should be used to identify values that are 464 referenced by a URI (including a Content-ID URI), instead of encoded 465 in-line. These value references might be used if the value is too 466 large, unavailable, or otherwise undesirable to include directly. The 467 format for the URI is as defined in RFC 1738. 469 "date", "time", and "date-time": Each of these value types is based on 470 the definitions in [DATETIME], which defines an Internet profile of the 471 ISO 8601 standard. Profiles may place further restrictions on "date" and 472 "time" values than are found in [DATETIME]. Multiple "date" and "time" 473 values may be specified using the comma-separated notation. 475 Examples for "date": 476 1985-04-12 477 1996-08-05, 1996-11-11 478 19850412 480 Examples for "time": 481 10:22:00 482 102200 483 10:22:00.33 484 10:22:00.33Z 485 10:22:33, 11:22:00 486 10:22:00-08:00 488 Examples for "date-time": 489 1996-10-22T14:00:00Z 490 1996-08-11T12:34:56Z 491 19960811T123456Z 492 1996-10-22T14:00:00Z, 1996-08-11T12:34:56Z 494 "boolean": The "boolean" value type is used to express boolen values. 495 These values are case insensitive. 497 Examples: TRUE 498 Expires in six months INTERNET DRAFT 500 false 501 true 503 "integer": The "integer" value type is used to express 32-bit signed 504 integers in decimal format. The valid range for "int" is -2147483648 to 505 2147483647. If sign is not specified, the value is assumed positive 506 "+". Multiple "integer" values may be specified using the comma- 507 separated notation. 509 Examples: 1234567890 510 -1234556790 511 +1234556790, 432109876 513 "float": The "float" value type is used to express real numbers. If 514 sign is not specified, the value is assumed positive "+". Multiple 515 "float" values may be specified using the comma-separated notation. 517 Examples: 20.30 518 1000000.0000001 519 1.333, 3.14 521 5.9. Applications which use this media type 523 Applications which use this media type: Various 525 5.10. Additional information 527 Additional information: None 529 5.11. Person & email address to contact for further information 531 Tim Howes 532 Netscape Communications Corp. 533 501 East Middlefield Rd. 534 Mountain View, CA 94041 535 USA 536 howes@netscape.com 537 +1 415 937 3419 539 5.12. Intended usage 541 Intended usage: COMMON 543 5.13. Author/Change controller 545 Tim Howes 546 Netscape Communications Corp. 548 Expires in six months INTERNET DRAFT 550 501 East Middlefield Rd. 551 Mountain View, CA 94041 552 USA 553 howes@netscape.com 554 +1 415 937 3419 556 Mark Smith 557 Netscape Communications Corp. 558 501 East Middlefield Rd. 559 Mountain View, CA 94041 560 USA 561 mcs@netscape.com 562 +1 415 937 3477 564 6. Predefined Types 566 The following types are generally useful regardless of the profile being 567 carried, and are defined below using the text/directory MIME type regis- 568 tration template defined in Section 11.1 of this document. These types 569 may be included in any profile, unless explicitly forbidden in the pro- 570 file definition. 572 6.1. SOURCE Type Definition 574 To: ietf-mime-direct@imc.org 575 Subject: Registration of text/directory MIME type SOURCE 577 Type name: SOURCE 579 Type purpose: To identify the source of directory information con- 580 tained in the content type. 582 Type encoding: 8bit 584 Type valuetype: text containing a URI. 586 Type special notes: The SOURCE type is used to provide the means by 587 which applications knowledgable in the given directory service proto- 588 col may obtain additional or more up-to-date information from the 589 directory service. It contains a URI as defined in [RFC-1738] 590 referencing the directory entity or entities to which the information 591 pertains. When directory information is available from more than one 592 source, the sending entity may pick what it considers to be the best 593 source, or multiple SOURCE types may be included. 595 Type example: 596 SOURCE: ldap://ldap.host/cn=Babs%20Jensen,%20o=Babsco,%20c=US 597 Expires in six months INTERNET DRAFT 599 6.2. NAME Type Definition 601 To: ietf-mime-direct@imc.org 602 Subject: Registration of text/directory MIME type NAME 604 Type name: NAME 606 Type purpose: To identify the displayable name of the directory 607 entity to which information in the content type pertains. 609 Type encoding: 8bit 611 Type valuetype: text 613 Type special notes: The NAME type is used to convey the directory 614 name of the entity to which the directory information pertains. Its 615 value depends on the setting of the "CONTEXT" type parameter, which 616 indicates the directory service protocol context in which the value 617 of the NAME parameter should be interpreted. Note that this value is 618 protocol-specific and is intended for applications knowledgable in a 619 particular directory service protocol. 621 Type example: 622 NAME;CONTEXT=LDAP: cn=Babs Jensen, o=Babsco, c=US 624 6.3. PROFILE Type Definition 626 To: ietf-mime-direct@imc.org 627 Subject: Registration of text/directory MIME type PROFILE 629 Type name: PROFILE 631 Type purpose: To identify the type of directory entity to which 632 information in the content type pertains. 634 Type encoding: 8bit 636 Type valuetype: text, containing a profile name, registered as 637 described in Section 9 of this document or bilaterally-agreed upon as 638 described in Section 5. 640 Type special notes: The PROFILE type is used to convey the type of 641 the entity to which the directory information in the rest of the body 642 part pertains. It should be the same as the "profile" header parame- 643 ter, if present. 645 Type example: 646 PROFILE: person 647 Expires in six months INTERNET DRAFT 649 6.4. BEGIN Type Definition 651 To: ietf-mime-direct@imc.org 652 Subject: Registration of text/directory MIME type BEGIN 654 Type name: BEGIN 656 Type purpose: To delimit the beginning of a syntactic entity within a 657 text/directory content-type. 659 Type encoding: 8bit 661 Type valuetype: text, containing a profile name, registered as 662 described in Section 9 of this document or bilaterally-agreed upon as 663 described in Section 5. 665 Type special notes: The BEGIN type is used in conjunction with the 666 END type to delimit a profile containing a related set of directory 667 content within an text/directory content-type. This construct may be 668 used instead of or in addition to wrapping separate sets of informa- 669 tion inside additional MIME headers. It is provided for applications 670 that wish to define content that may contain multiple entities within 671 the same text/directory content-type or to define content that may be 672 identifiable outside of a MIME environment. 674 Type example: 675 BEGIN: vcard 677 6.5. END Type Definition 679 To: ietf-mime-direct@imc.org 680 Subject: Registration of text/directory MIME type END 682 Type name: END 684 Type purpose: To identify the type of directory entity to which 685 information in the content type pertains. 687 Type encoding: 8bit 689 Type valuetype: text, containing a profile name, registered as 690 described in Section 9 of this document or bilaterally-agreed upon as 691 described in Section 5. 693 Type special notes: The END type is used in conjunction with the 694 BEGIN type to delimit a profile containing a related set of directory 695 content within an text/directory content-type. This construct may be 696 used instead of or in addition to wrapping separate sets of 697 Expires in six months INTERNET DRAFT 699 information inside additional MIME headers. It is provided for appli- 700 cations that wish to define content that may contain multiple enti- 701 ties within the same text/directory content-type or to define content 702 that may be identifiable outside of a MIME environment. 704 Type example: 705 END: vcard 707 7. Use of the multipart/related Content-Type 709 The multipart/related Content-Type can be used to hold directory infor- 710 mation comprised of both text and non-text information or directory 711 information that already has a natural MIME representation. The root 712 body part within the multipart/related body part is specified as defined 713 in [RFC-1872] by a "start" parameter, or it is the first body part in 714 the absence of such a parameter. The root body part must have a 715 Content-Type of "text/directory". This part holds inline information, 716 optionally defines the name and source of the information, and makes 717 reference to subsequent body parts holding additional text or non-text 718 directory information via their Content-ID URIs as explained in Section 719 5. 721 The body parts referred to do not have to be in any particular order, 722 except as noted above for the root body part. 724 8. Examples 726 The following examples are for illustrative purposes only and are not 727 part of the definition. 729 8.1. Example 1 731 The first example illustrates simple use of the text/directory Content- 732 Type. Note that no "profile" parameter is given, so an application may 733 not know what kind of directory entity the information applies to. Note 734 also the use of both hypothetical official and bilaterally agreed upon 735 types. 737 From: Whomever@wherever.com 738 To: Someone@somewhere.com 739 Subject: whatever 740 MIME-Version: 1.0 741 Message-ID: 742 Content-Type: text/directory 743 Content-ID: 745 cn: Babs Jensen 746 cn: Barbara J Jensen 747 Expires in six months INTERNET DRAFT 749 sn: Jensen 750 email: babs@umich.edu 751 phone: +1 313 747-4454 752 x-id: 1234567890 754 8.2. Example 2 756 The next example illustrates the use of the Quoted-Printable encoding 757 defined in [RFC 2045] to include non-ASCII character in some of the 758 information returned, and the use of the optional "name" and "source" 759 types. It also illustrates the use of an "encoding" type parameter to 760 encode a certificate value in base64. A "vCard" profile [MIME-VCARD] is 761 used for the example. 763 Content-Type: text/directory; 764 charset="iso-8859-1"; 765 profile="vCard" 766 Content-ID: 767 Content-Transfer-Encoding: Quoted-Printable 769 begin: vcard 770 source: ldap://cn=3Dbjorn%20Jensen, o=3Duniversity%20of%20Michigan, c=3DUS 771 name: cn=3Dbjorn Jensen, o=3Duniversity of Michigan, c=3DUS 772 fn: Bj=F8rn Jensen 773 n: Jensen;Bj=F8rn 774 email;type=3Dinternet: bjorn@umich.edu 775 tel;type=3Dwork,voice,msg:+1 313 747-4454 776 key;type=3Dx509;encoding=3Dbase64: dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK 777 end: vcard 779 8.3. Example 3 781 The next example illustrates the use of multi-valued type parameters, 782 the "language" type parameter, the "value" type parameter, inline 783 quoted-printable encoding to represent iso-8859-1 characters and fold 784 long lines, and attribute grouping. 786 Content-Type: text/directory; profile="person"; charset=iso-8859-1 787 Content-ID: 789 source: ldap://cn=Meister%20Berger,o=Universitaet%20Goerlitz,c=DE 790 name: cn=Meister Berger, o=Universitaet Goerlitz, c=DE 791 cn: Meister Berger 792 cn: Berger Meister 793 sn: Berger 794 age;value=integer: 33 795 o;encoding=quoted-printable: Universit=E6t G=F6rlitz 796 title: Mayor 797 Expires in six months INTERNET DRAFT 799 title;language=de;value=text: Burgermeister 800 description;encoding=quoted-printable: The Mayor of the great city of= 801 Goerlitz in the great country of Germany. 802 email: mb@goerlitz.de 803 home.phone;fax,voice,msg: +49 3581 123456 804 home.addr;encoding=quoted-printable: Hufenshlagel 1234=0A= 805 02828 Goerlitz=0A= 806 Deutschland 807 certificate;encoding=base64: dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlma... 809 8.4. Example 4 811 The final example illustrates the use of the multipart/related Content- 812 Type to include non-textual directory data via the "uri" encoding to 813 refer to other body parts within the same message, or to external 814 values. 816 Content-Type: multipart/related; 817 boundary=woof; 818 type="text/directory"; 819 start="" 820 Content-ID: 822 --woof 823 Content-Type: text/directory; charset="iso-8859-1" 824 Content-ID: 825 Content-Transfer-Encoding: Quoted-Printable 827 source: ldap://cn=3DBjorn%20Jensen,o=3DUniversity%20of%20Michigan,c=3DUS 828 cn: Bj=F8rn Jensen 829 sn: Jensen 830 email: bjorn@umich.edu 831 image;encoding=3Duri: cid:id6@host.com 832 image;encoding=3Duri;format=3Djpeg: ftp://some.host/some/path.jpg 833 sound;encoding=3Duri: cid:id7@host.com 834 phone: +1 313 747-4454 836 --woof 837 Content-Type: image/jpeg 838 Content-ID: 840 <...image data...> 842 --woof 843 Content-Type: message/external-body; 844 name="myvoice.au"; 845 site="myhost.com"; 846 access-type=ANON-FTP; 847 Expires in six months INTERNET DRAFT 849 directory="pub/myname"; 850 mode="image" 852 Content-Type: audio/basic 853 Content-ID: 855 --woof-- 857 9. Registration of new profiles 859 This section defines procedures by which new profiles are registered 860 with the IANA and made available to the Internet community. Note that 861 non-IANA profiles may be used by bilateral agreement, provided the asso- 862 ciated profile names follow the "X-" convention defined above. 864 The procedures defined here are designed to allow public comment and 865 review of new profiles, while posing only a small impediment to the 866 definition of new profiles. 868 Registration of a new profile is accomplished by the following steps. 870 9.1. Define the profile 872 A profile is defined by completing the following template. 874 To: ietf-mime-direct@imc.org 875 Subject: Registration of text/directory MIME profile XXX 877 Profile name: 879 Profile purpose: 881 Profile types: 883 Profile special notes (optional): 885 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 887 The explanation of what goes in each field in the template follows. 889 Profile name: The name of the profile as it will appear in the 890 text/directory MIME Content-Type "profile" header parameter, or the 891 predefined "profile" type name. 893 Profile purpose: The purpose of the profile (e.g., to represent informa- 894 tion about people, printers, documents, etc.). Give a short but clear 895 description. 897 Expires in six months INTERNET DRAFT 899 Profile types: The list of types associated with the profile. This list 900 of types is to be expected but not required in the profile, unless oth- 901 erwise noted in the profile definition. Other types not mentioned in 902 the profile definition may also be present. Note that any new types 903 referenced by the profile must be defined separately as described in 904 Section 10. 906 Profile special notes: Any special notes about the profile, how it is to 907 be used, etc. This section of the template may also be used to define an 908 ordering on the types that appear in the Content-Type, if such an order- 909 ing is required. 911 9.2. Post the profile definition 913 The profile description must be posted to the new profile discussion 914 list, ietf-mime-direct@imc.org 916 9.3. Allow a comment period 918 Discussion on the new profile must be allowed to take place on the list 919 for a minimum of two weeks. Consensus must be reached on the profile 920 before proceeding to step 4. 922 9.4. Submit the profile for approval 924 Once the two-week comment period has elapsed, and the proposer is con- 925 vinced consensus has been reached on the profile, the registration 926 application should be submitted to the Profile Reviewer for approval. 927 The Profile Reviewer is appointed to the Application Area Directors and 928 may either accept or reject the profile registration. An accepted regis- 929 tration should be passed on by the Profile Reviewer to the IANA for 930 inclusion in the official IANA profile registry. The registration may be 931 rejected for any of the following reasons. 1) Insufficient comment 932 period; 2) Consensus not reached; 3) Technical deficiencies raised on 933 the list or elsewhere have not been addressed. The Profile Reviewer's 934 decision to reject a profile may be appealed by the proposer to the 935 IESG, or the objections raised can be addressed by the proposer and the 936 profile resubmitted. 938 10. Profile Change Control 940 Existing profiles may be changed using the same process by which they 941 were registered. 943 Define the change 945 Post the change 946 Expires in six months INTERNET DRAFT 948 Allow a comment period 950 Submit the changed profile for approval 952 Note that the original author or any other interested party may propose 953 a change to an existing profile, but that such changes should only be 954 proposed when there are serious omissions or errors in the published 955 specification. The Profile Reviewer may object to a change if it is not 956 backwards compatible, but is not required to do so. 958 Profile definitions can never be deleted from the IANA registry, but 959 profiles which are no longer believed to be useful can be declared 960 OBSOLETE by a change to their "intended use" field. 962 11. Registration of new types 964 This section defines procedures by which new types are registered with 965 the IANA. Note that non-IANA types may be used by bilateral agreement, 966 provided the associated types names follow the "X-" convention defined 967 above. 969 The procedures defined here are designed to allow public comment and 970 review of new types, while posing only a small impediment to the defini- 971 tion of new types. 973 Registration of a new type is accomplished by the following steps. 975 11.1. Define the type 977 A type is defined by completing the following template. 979 To: ietf-mime-direct@imc.org 980 Subject: Registration of text/directory MIME type XXX 982 Type name: 984 Type purpose: 986 Type encoding: 988 Type valuetype: 990 Type special notes (optional): 992 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 994 The meaning of each field in the template is as follows. 996 Expires in six months INTERNET DRAFT 998 Type name: The name of the type, as it will appear in the body of an 999 text/directory MIME Content-Type "type: value" line to the left of the 1000 colon ":". 1002 Type purpose: The purpose of the type (e.g., to represent a name, postal 1003 address, IP address, etc.). Give a short but clear description. 1005 Type encoding: The default encoding a value of the type must have in the 1006 body of a text/directory MIME Content-Type. 1008 Type valuetype: The format a value of the type must have in the body of 1009 a text/directory MIME Content-Type. This description must be precise and 1010 must not violate the general encoding rules defined in section 5 of this 1011 document. 1013 Type special notes: Any special notes about the type, how it is to be 1014 used, etc. 1016 11.2. Post the type definition 1018 The type description must be posted to the new type discussion list, 1019 ietf-mime-direct@imc.org 1021 11.3. Allow a comment period 1023 Discussion on the new type must be allowed to take place on the list for 1024 a minimum of two weeks. Consensus must be reached on the type before 1025 proceeding to step 4. 1027 11.4. Submit the type for approval 1029 Once the two-week comment period has elapsed, and the proposer is con- 1030 vinced consensus has been reached on the type, the registration applica- 1031 tion should be submitted to the Profile Reviewer for approval. The Pro- 1032 file Reviewer is appointed to the Application Area Directors and may 1033 either accept or reject the type registration. An accepted registration 1034 should be passed on by the Profile Reviewer to the IANA for inclusion in 1035 the official IANA profile registry. The registration may be rejected for 1036 any of the following reasons. 1) Insufficient comment period; 2) Con- 1037 sensus not reached; 3) Technical deficiencies raised on the list or 1038 elsewhere have not been addressed. The Profile Reviewer's decision to 1039 reject a type may be appealed by the proposer to the IESG, or the objec- 1040 tions raised can be addressed by the proposer and the type resubmitted. 1042 12. Type Change Control 1044 Existing types may be changed using the same process by which they were 1045 registered. 1047 Expires in six months INTERNET DRAFT 1049 Define the change 1051 Post the change 1053 Allow a comment period 1055 Submit the type for approval 1057 Note that the original author or any other interested party may propose 1058 a change to an existing type, but that such changes should only be pro- 1059 posed when there are serious omissions or errors in the published 1060 specification. The Profile Reviewer may object to a change if it is not 1061 backwards compatible, but is not required to do so. 1063 Type definitions can never be deleted from the IANA registry, but types 1064 which are nolonger believed to be useful can be declared OBSOLETE by a 1065 change to their "intended use" field. 1067 13. Registration of new parameters 1069 This section defines procedures by which new parameters are registered 1070 with the IANA and made available to the Internet community. Note that 1071 non-IANA parameters may be used by bilateral agreement, provided the 1072 associated parameters names follow the "X-" convention defined above. 1074 The procedures defined here are designed to allow public comment and 1075 review of new parameters, while posing only a small impediment to the 1076 definition of new parameters. 1078 Registration of a new parameter is accomplished by the following steps. 1080 13.1. Define the parameter 1082 A parameter is defined by completing the following template. 1084 To: ietf-mime-direct@imc.org 1085 Subject: Registration of text/directory MIME type parameter XXX 1087 Parameter name: 1089 Parameter purpose: 1091 Parameter values: 1093 Parameter special notes (optional): 1095 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1096 Expires in six months INTERNET DRAFT 1098 The explanation of what goes in each field in the template follows. 1100 Parameter name: The name of the parameter as it will appear in the 1101 text/directory MIME Content-Type. 1103 Parameter purpose: The purpose of the parameter (e.g., to represent the 1104 format of an image, type of a phone number, etc.). Give a short but 1105 clear description. If defining a general paramemter like "format" or 1106 "type" keep in mind that other applications may wish to extend its use. 1108 Parameter values: The list or description of values associated with the 1109 parameter. 1111 Parameter special notes: Any special notes about the parameter, how it 1112 is to be used, etc. 1114 13.2. Post the parameter definition 1116 The parameter description must be posted to the new parameter discussion 1117 list, ietf-mime-direct@imc.org 1119 13.3. Allow a comment period 1121 Discussion on the new parameter must be allowed to take place on the 1122 list for a minimum of two weeks. Consensus must be reached on the param- 1123 eter before proceeding to step 4. 1125 13.4. Submit the parameter for approval 1127 Once the two-week comment period has elapsed, and the proposer is con- 1128 vinced consensus has been reached on the parameter, the registration 1129 application should be submitted to the Profile Reviewer for approval. 1130 The Profile Reviewer is appointed to the Application Area Directors and 1131 may either accept or reject the parameter registration. An accepted 1132 registration should be passed on by the Profile Reviewer to the IANA for 1133 inclusion in the official IANA parameter registry. The registration may 1134 be rejected for any of the following reasons. 1) Insufficient comment 1135 period; 2) Consensus not reached; 3) Technical deficiencies raised on 1136 the list or elsewhere have not been addressed. The Profile Reviewer's 1137 decision to reject a profile may be appealed by the proposer to the 1138 IESG, or the objections raised can be addressed by the proposer and the 1139 parameter registration resubmitted. 1141 14. Parameter Change Control 1143 Existing parameters may be changed using the same process by which they 1144 were registered. 1146 Expires in six months INTERNET DRAFT 1148 Define the change 1150 Post the change 1152 Allow a comment period 1154 Submit the parameter for approval 1156 Note that the original author or any other interested party may propose 1157 a change to an existing parameter, but that such changes should only be 1158 proposed when there are serious omissions or errors in the published 1159 specification. The Profile Reviewer may object to a change if it is not 1160 backwards compatible, but is not required to do so. 1162 Parameter definitions can never be deleted from the IANA registry, but 1163 parameters which are nolonger believed to be useful can be declared 1164 OBSOLETE by a change to their "intended use" field. 1166 15. Registration of new value types 1168 This section defines procedures by which new value types are registered 1169 with the IANA and made available to the Internet community. Note that 1170 non-IANA value types may be used by bilateral agreement, provided the 1171 associated value types names follow the "X-" convention defined above. 1173 The procedures defined here are designed to allow public comment and 1174 review of new value types, while posing only a small impediment to the 1175 definition of new value types. 1177 Registration of a new value types is accomplished by the following 1178 steps. 1180 15.1. Define the value type 1182 A value type is defined by completing the following template. 1184 To: ietf-mime-direct@imc.org 1185 Subject: Registration of text/directory MIME value type XXX 1187 value type name: 1189 value type purpose: 1191 value type format: 1193 value type special notes (optional): 1195 Expires in six months INTERNET DRAFT 1197 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1199 The explanation of what goes in each field in the template follows. 1201 value type name: The name of the value type as it will appear in the 1202 text/directory MIME Content-Type. 1204 value type purpose: The purpose of the value type. Give a short but 1205 clear description. 1207 value type format: The definition of the format for the value, usually 1208 using BNF grammar. 1210 value type special notes: Any special notes about the value type, how 1211 it is to be used, etc. 1213 15.2. Post the value type definition 1215 The value type description must be posted to the new value type discus- 1216 sion list, ietf-mime-direct@imc.org 1218 15.3. Allow a comment period 1220 Discussion on the new value type must be allowed to take place on the 1221 list for a minimum of two weeks. Consensus must be reached before 1222 proceeding to step 4. 1224 15.4. Submit the value type for approval 1226 Once the two-week comment period has elapsed, and the proposer is con- 1227 vinced consensus has been reached on the value type, the registra- 1228 tion application should be submitted to the Profile Reviewer for 1229 approval. The Profile Reviewer is appointed to the Application Area 1230 Directors and may either accept or reject the value type registration. 1231 An accepted registration should be passed on by the Profile Reviewer to 1232 the IANA for inclusion in the official IANA value type registry. The 1233 registration may be rejected for any of the following reasons. 1) 1234 Insufficient comment period; 2) Consensus not reached; 3) Technical 1235 deficiencies raised on the list or elsewhere have not been 1236 addressed. The Profile Reviewer's decision to reject a profile may be 1237 appealed by the proposer to the IESG, or the objections raised can 1238 be addressed by the proposer and the value type registration resubmit- 1239 ted. 1241 Expires in six months INTERNET DRAFT 1243 16. Security Considerations 1245 Internet mail is subject to many well known security attacks, including 1246 monitoring, replay, and forgery. Care should be taken by any directory 1247 service in allowing information to leave the scope of the service 1248 itself, where any access controls can no longer be guaranteed. Applica- 1249 tions should also take care to display directory data in a "safe" 1250 environment (e.g., PostScript-valued types). 1252 17. Acknowledgements 1254 The registration procedures defined here were shamelessly lifted from 1255 the MIME registration RFC. 1257 The many valuable comments contributed by members of the IETF ASID work- 1258 ing group are gratefully acknowledged, as are the contributions of the 1259 Versit Consortium.. 1261 18. Bibliography 1263 [RFC-1777] Yeong, W., Howes, T., Kille, S., "Lightweight Directory 1264 Access Protocol", Request for Comment (RFC) 1777, March 1995. 1266 [RFC-1778] Howes, T., Kille, S., Yeong, W., Robbins, C.J., "The String 1267 Representation of Standard Attribute Syntaxes", Request for 1268 Comment (RFC) 1778, March 1995. 1270 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 1271 Messages", STD 11, RFC 822, August 1982. 1273 [RFC-1521] Borenstein, N., Freed, N., "Multipurpose Internet Mail Exten- 1274 sions (MIME) Part One: Format of Internet Message Bodies", 1275 RFC 2045, November 1996. 1277 [RFC-2046] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part 1278 Two: Media Types", RFC 2046, November 1996. 1280 [RFC-2048] Freed, N., Klensin, J., Postel, J., "Multipurpose Internet 1281 Mail Extensions (MIME) Part Four: Registration Procedures", 1282 RFC 2048, November 1996 1284 [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", 1285 RFC 1766, March 1995. 1287 [RFC-1872] Levinson, E., "The MIME Multipart/Related Content-type," RFC 1288 1872, December 1995. 1290 [X500] "Information Processing Systems - Open Systems 1291 Expires in six months INTERNET DRAFT 1293 Interconnection - The Directory: Overview of Concepts, Models 1294 and Services", ISO/IEC JTC 1/SC21, International Standard 1295 9594-1, 1988. 1297 [RFC-1835] Deutsch, P., Schoultz, R., Faltstrom, P., Weider, C., "Archi- 1298 tecture of the WHOIS++ service", August 1995. 1300 [RFC-1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform 1301 Resource Locators (URL)", RFC 1738, December 1994. 1303 [DATETIME] Newman, C., "Date and Time on the Internet", Internet Draft 1304 draft-newman-datetime-01.txt, January 1997. 1306 [MIME-VCARD]F. Dawson, T. Howes, "VCard MIME Directory Profile", 1307 Internet-Draft draft-ietf-asid-mime-vcard-02.txt, March, 1308 1997. 1310 [VCARD] Versit Consortium, "vCard - The Electronic Business Card", 1311 Version 2.1, http://www.imc.com/pdi/vcard-21.txt, September, 1312 1996. 1314 19. Author's Address 1316 Tim Howes 1317 Netscape Communications Corp. 1318 501 East Middlefield Rd. 1319 Mountain View, CA 94041 1320 USA 1321 howes@netscape.com 1322 +1.415.937.3419 1324 Mark Smith 1325 Netscape Communications Corp. 1326 501 East Middlefield Rd. 1327 Mountain View, CA 94041 1328 USA 1329 mcs@netscape.com 1330 +1.415.937.3477 1332 20. Table of Contents 1334 1. Status of this Memo............................................1 1335 2. Abstract.......................................................1 1336 3. Need for a MIME Directory Type.................................2 1337 4. Overview.......................................................2 1338 5. The text/directory Content-Type................................3 1339 5.1. MIME media type name........................................3 1340 5.2. MIME subtype name...........................................3 1341 5.3. Required parameters.........................................3 1342 5.4. Optional parameters.........................................3 1343 5.5. Encoding considerations.....................................4 1344 5.6. Security considerations.....................................4 1345 5.7. Interoperability considerations.............................4 1346 5.8. Published specification.....................................4 1347 5.8.1. Line delimiting and folding..............................5 1348 5.8.2. BNF content-type definition..............................6 1349 5.8.3. Predefined value formats.................................10 1350 5.9. Applications which use this media type......................11 1351 5.10. Additional information......................................11 1352 5.11. Person & email address to contact for further information...11 1353 5.12. Intended usage..............................................11 1354 5.13. Author/Change controller....................................11 1355 6. Predefined Types...............................................12 1356 6.1. SOURCE Type Definition......................................12 1357 6.2. NAME Type Definition........................................13 1358 6.3. PROFILE Type Definition.....................................13 1359 6.4. BEGIN Type Definition.......................................14 1360 6.5. END Type Definition.........................................14 1361 7. Use of the multipart/related Content-Type......................15 1362 8. Examples.......................................................15 1363 8.1. Example 1...................................................15 1364 8.2. Example 2...................................................16 1365 8.3. Example 3...................................................16 1366 8.4. Example 4...................................................17 1367 9. Registration of new profiles...................................18 1368 9.1. Define the profile..........................................18 1369 9.2. Post the profile definition.................................19 1370 9.3. Allow a comment period......................................19 1371 9.4. Submit the profile for approval.............................19 1372 10. Profile Change Control.........................................19 1373 11. Registration of new types......................................20 1374 11.1. Define the type.............................................20 1375 11.2. Post the type definition....................................21 1376 11.3. Allow a comment period......................................21 1377 11.4. Submit the type for approval................................21 1378 12. Type Change Control............................................21 1379 13. Registration of new parameters.................................22 1380 13.1. Define the parameter........................................22 1381 13.2. Post the parameter definition...............................23 1382 13.3. Allow a comment period......................................23 1383 13.4. Submit the parameter for approval...........................23 1384 14. Parameter Change Control.......................................23 1385 15. Registration of new value types................................24 1386 15.1. Define the value type.......................................24 1387 15.2. Post the value type definition..............................25 1388 15.3. Allow a comment period......................................25 1389 15.4. Submit the value type for approval..........................25 1390 16. Security Considerations........................................26 1391 17. Acknowledgements...............................................26 1392 18. Bibliography...................................................26 1393 19. Author's Address...............................................27 1394 20. Table of Contents..............................................27