idnits 2.17.1 draft-ietf-asid-mime-direct-06.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. Found some kind of copyright notice around line 31 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-25) 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 30 longer pages, the longest (page 30) being 60 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 290 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 9 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([RFC-2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 13 has weird spacing: '...fts are worki...' == Line 14 has weird spacing: '...ments of the ...' == Line 15 has weird spacing: '...t other group...' == Line 19 has weird spacing: '...and may be ...' == Line 23 has weird spacing: '...atus of any ...' == (285 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The 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 (March 8, 1998) is 9545 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: 'MIME-VCARD' is mentioned on line 864, but not defined == Missing Reference: 'RFC 2045' is mentioned on line 834, but not defined == Unused Reference: 'VCARD' is defined on line 1407, but no explicit reference was found in the text == Unused Reference: 'RFC-2234' is defined on line 1414, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1777 (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1778 (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2112 (Obsoleted by RFC 2387) -- Possible downref: Non-RFC (?) normative reference: ref. 'X500' ** Downref: Normative reference to an Historic RFC: RFC 1835 ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. 'VCARD' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 23 errors (**), 0 flaws (~~), 14 warnings (==), 4 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-06.txt Netscape Communications Corp. 5 Frank Dawson 6 Lotus Development Corporation 7 March 8, 1998 9 A MIME Content-Type for Directory Information 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working docu- 14 ments of the Internet Engineering Task Force (IETF), its areas, and its 15 working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference material 21 or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Distribution of this memo is unlimited. 31 Copyright (C) The Internet Society 1998. All Rights Reserved. 33 2. Abstract 35 This document defines a MIME Content-Type for holding directory informa- 36 tion. The definition is independent of any particular directory service 37 or protocol. The text/directory Content-Type is defined for holding a 38 variety of directory information, for example, name, or email address, 39 or logo. The text/directory Content-Type can also be used as the root 40 body part in a multipart/related Content-Type for handling more compli- 41 cated situations, especially those in which non-textual information that 42 already has a natural MIME representation, for example, a photograph or 43 sound, must be represented. 45 The text/directory Content-Type defines a general framework and format 46 for holding directory information in a simple "type: value" form. 48 Expires in six months INTERNET DRAFT 50 Mechanisms are defined to specify alternate languages, encodings and 51 other meta-information. This document also defines the procedure by 52 which particular formats, called profiles, for carrying application- 53 specific information within a text/directory Content-Type may be defined 54 and registered, and the conventions such formats must follow. It is 55 expected that other documents will be produced that define such formats 56 for various applications (e.g., white pages). 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 60 document are to be interopreted as described in [RFC-2119]. 62 3. Need for a MIME Directory Type 64 For purposes of this document, a directory is a special-purpose database 65 that contains typed information. A directory usually supports both read 66 and search of the information it contains, and may support creation and 67 modification of the information as well. Directory information is usu- 68 ally accessed far more often than it is updated. Directories may be 69 local or global in scope. They may be distributed or centralized. The 70 information they contain may be replicated, with weak or strong con- 71 sistency requirements. 73 There are several situations in which users of Internet mail may wish to 74 exchange directory information: the email analogy of a "business card" 75 exchange; the conveyance of directory information to a user having only 76 email access to the Internet; the provision of machine-parseable address 77 information when purchasing goods or services over the Internet; etc. As 78 MIME [RFC-2045,RFC-2046] is used increasingly by other protocols, most 79 notably HTTP, it may also be useful for these protocols to be able to 80 carry directory information in MIME format. Such a format, for example, 81 could be used to represent URC (uniform resource characteristics) infor- 82 mation about resources on the World Wide Web, or to provide a rudimen- 83 tary directory service over HTTP. 85 4. Overview 87 The scheme defined here for representing directory information in a MIME 88 Content-Type has two parts. First, the text/directory Content-Type is 89 defined for use in holding directory information within a single body 90 part, for example name, title, or email address. In its simplest form, 91 the format uses a "type: value" approach, which should be easily pars- 92 able by existing MIME implementations and understandable by users. More 93 complicated situations can be represented also. This document defines 94 the general form the information in the Content-Type should have, and 95 the procedure by which specific types and values (properties) for par- 96 ticular applications may be defined. The framework is general enough to 97 handle information from any number of end directory services, including 98 Expires in six months INTERNET DRAFT 100 LDAP [RFC-1777, RFC-1778], WHOIS++ [RFC-1835], and X.500 [X500]. 102 Directory entries can include far more than just textual information. 103 Some such information (e.g., an image or sound) overlaps with predefined 104 MIME Content-Types. In these cases it may be desirable to include the 105 information in its well-known MIME format. This situation is handled by 106 using a multipart/related Content-Type as defined in [RFC-2112]. The 107 root component of this type is a text/directory body part specifying any 108 in-line information, and for information contained in other Content- 109 Types, the Content-IDs (in URI form) of those types. 111 In some applications, it may be useful to include a pointer (e.g, a URI) 112 to some directory information rather than the information itself. This 113 document defines a general mechanism for accomplishing this. 115 5. The text/directory Content-Type 117 The text/directory Content-Type is used to hold basic directory informa- 118 tion, URIs referencing other information, including other MIME body 119 parts holding supplementary or non-textual directory information, such 120 as an image or sound. It is defined as follows, using the MIME media 121 type registration template from [RFC-2048]. 123 To: ietf-types@uninett.no 124 Subject: Registration of MIME media type text/directory 126 5.1. MIME media type name 128 MIME media type name: text 130 5.2. MIME subtype name 132 MIME subtype name: directory 134 5.3. Required parameters 136 Required parameters: charset 138 The "charset" parameter is as defined in [RFC-2046] for other body 139 parts. It is used to identify the default character set used within the 140 body part. 142 5.4. Optional parameters 144 Optional parameters: profile 146 The "profile" parameter is used to convey the type(s) of entity(ies) to 147 which the directory information pertains and the likely set of 148 Expires in six months INTERNET DRAFT 150 information associated with the entity(ies). It is intended only as a 151 guide to applications interpreting the information contained within the 152 body part. It SHOULD NOT be used to exclude or require particular pieces 153 of information unless a profile definition specifically calls for this 154 behavior. Unless specifically forbidden by a particular profile defini- 155 tion, a text/directory content type may contain arbitrary 156 attribute/value pairs. 158 The value of the "profile" parameter is defined as follows. Profile 159 names are case insensitive (i.e., the profile name "vCard" is the same 160 as "VCARD" and "vcard" and "vcArD"). 162 profile = x-name / iana-token 164 x-name = ("x-" / "X-") 1*(ALPHA / DIGIT / "-") 165 ; Reservered for experimental use, not intended for released 166 ; products, or for use in bilateral agreements. 168 iana-token = 172 5.5. Encoding considerations 174 The default encoding is 8bit. Otherwise, as specified by the Content- 175 Transfer-Encoding header field. 177 5.6. Security considerations 179 Directory information may be public or it may be protected from unau- 180 thorized access by the directory service in which it resides. Once the 181 information leaves its native service, there can be no guarantee that 182 the same care will be taken by all services handling the information. 183 Furthermore, this specification defines no access control mechanism by 184 which information may be protected, or by which access control informa- 185 tion may be conveyed. Note that the integrity and privacy of a 186 text/directory body part may be protected by enclosing it within an 187 appropriate MIME-based security mechanism. 189 5.7. Interoperability considerations 191 In order to make sense of directory information, applications must share 192 a common understanding of the types of information contained within the 193 Content-Type (the directory schema). This schema information is not 194 defined in this document, but rather in companion documents (e.g., 195 [MIME-VCARD]) that follow the requirements specified in this document, 196 or in bilateral agreements between communicating parties. 198 Expires in six months INTERNET DRAFT 200 5.8. Published specification 202 The text/directory Content-Type contains directory information, typi- 203 cally pertaining to a single directory entity or group of entities. The 204 content consists of one or more lines in the format given below. 206 5.8.1. Line delimiting and folding 208 Individual lines within the MIME text/directory Content Type body are 209 delimited by the [RFC-822] line break, which is a CRLF sequence (ASCII 210 decimal 13, followed by ASCII decimal 10). Long logical lines of text 211 MAY be split into a multiple-physical-line representation using the fol- 212 lowing folding technique. 214 A logical line MAY be continued on the next physical line at any point 215 by inserting a CRLF immediately followed by a single white space charac- 216 ter (space, ASCII decimal 32, or horizontal tab, ASCII decimal 9). At 217 least one character must be present on the folded line. Any sequence of 218 CRLF followed immediately by a single white space character is ignored 219 (removed) when processing the content type. For example the line: 221 DESCRIPTION:This is a long description that exists on a long line. 223 Can be represented as: 225 DESCRIPTION:This is a long description 226 that exists on a long line. 228 It could also be represented as: 230 DESCRIPTION:This is a long descrip 231 tion that exists o 232 n a long line. 234 The process of moving from this folded multiple-line representation of a 235 type definition to its single line representation is called unfolding. 236 Unfolding is accomplished by regarding CRLF immediately followed by a 237 white space character (namely HTAB ASCII decimal 9 or SPACE ASCII 238 decimal 32) as equivalent to no characters at all (i.e., the CRLF and 239 single white space character are removed). 241 5.8.2. ABNF content-type definition 243 The following ABNF uses the notation of RFC 2234, which also defines 244 CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. After the unfolding of any 245 folded lines as described above, the syntax for a line of this content 246 type is as follows: 248 Expires in six months INTERNET DRAFT 250 contentline = [group "."] name *(";" *WSP param) ":" value CRLF 251 ; When parsing a content line, folded lines must first 252 ; be unfolded according to the unfolding procedure 253 ; described above. 254 ; When generating a content line, lines longer than 75 255 ; characters should be folded according to the folding 256 ; procedure described above. 258 group = 1*(ALPHA / DIGIT / "-") 260 name = x-name / iana-token 262 iana-token = 1*(ALPHA / DIGIT / "-") 263 ; identifier registered with IANA 265 x-name = ("x-" / "X-") 1*(ALPHA / DIGIT / "-") 266 ; Reservered for experimental use, not intended for released 267 ; products, or for use in bilateral agreements. 269 param = param-name "=" param-value *("," *WSP param-value) 271 param-name = x-name / iana-token 273 param-value = text / quoted-string 275 text = *SAFE-CHAR 277 value = *VALUE-CHAR 279 quoted-string = DQUOTE 1*qtext DQUOTE 281 qtext = QSAFE-CHAR / QUOTED-CHAR 283 NON-ASCII = %x80-FF 284 ; use restricted by charset parameter 285 ; on outer MIME object (UTF-8 preferred) 287 QSAFE-CHAR = WSP / %x21 / %x23-5B / %x5D-7E / NON-ASCII 288 ; Any character except CTLs, DQUOTE, or "\" 290 QUOTED-CHAR = "\" ("\" / DQUOTE) 291 ; \\ encodes \, \" encodes " 293 SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII 294 ; Any character except CTLs, DQUOTE, ";", ":", "," 296 VALUE-CHAR = WSP / VCHAR / NON-ASCII 297 ; any textual character 299 Expires in six months INTERNET DRAFT 301 A line that begins with a white space character is a continuation of the 302 previous line, as described above. The white space character and immedi- 303 ately preceeding CRLF should be discarded when reconstructing the origi- 304 nal line. Note that this line-folding convention differs from that found 305 in RFC 822, in that the sequence found anywhere in the con- 306 tent indicates a continued line and should be removed. 308 Various type names and the format of the corresponding values MUST be 309 defined as specified in Section 11. Specifications MAY impose ordering 310 on the type constructs within a body part, though none is required by 311 default. The various x-name constructs are used for bilaterally-agreed 312 upon type names, parameter names and parameter values, or for use in 313 experimental settings. 315 Type names and parameter names are case insensitive (e.g., the type name 316 "fn" is the same as "FN" and "Fn"). Parameter values MAY be case sensi- 317 tive or case insensitive, depending on their definition. 319 The group construct is used to group related attributes together. The 320 group name is a syntactic convention used to indicate that all type 321 names prefaced with the same group name SHOULD be grouped together when 322 displayed by an application. It has no other significance. Implementa- 323 tions that do not understand or support grouping MAY simply strip off 324 any text before a "." to the left of the type name and present the types 325 and values as normal. 327 Each attribute defined in the text/directory body MAY have multiple 328 values, if allowed in the definition of the profile in which the attri- 329 bute is used. The general rule for encoding multi-valued items is to 330 simply create a new content line for each value (including the type 331 name). However, it should be noted that some value types MAY support 332 encoding multiple values in a single content line, for example by 333 separating the values with a comma "," or other delimiter. This 334 approach has been taken for several of the content types defined below 335 (date, time, integer, float), for space-saving reasons. 337 5.8.3. Pre-defined Parameters 339 The following parameters and value types are defined as they may be of 340 general purpose use. 342 predefined-param = encodingparm 343 / valuetypeparm 344 / languageparm 345 / contextparm 347 encodingparm = "encoding" "=" encodingtype 349 Expires in six months INTERNET DRAFT 351 encodingtype = "b" ; from RFC 2047 352 / iana-token ; registered as described in 353 ; section 15 of this document 355 valuetypeparm = "value" "=" valuetype 357 valuetype = "uri" ; genericurl from secion 5 of RFC 1738 358 / "text" 359 / "date" 360 / "time" 361 / "date-time" ; date time 362 / "integer" 363 / "boolean" 364 / "float" 365 / x-name 366 / iana-token ; registered as described in 367 ; section 15 of this document 369 languageparm = "language" "=" Language-Tag 370 ; Language-Tag is defined in section 2 of RFC 1766 372 contextparm = "context" "=" context 374 context = x-name 375 / iana-token 377 The "language" type parameter is used to identify data in multiple 378 languages. There is no concept of "default" language, except as speci- 379 fied by any "Content-Language" MIME header parameter that MAY be 380 present. The value of the "language" type parameter is a language tag as 381 defined in Section 2 of [RFC-1766]. 383 The "context" type parameter is used to identify a context (e.g., a pro- 384 tocol) used in interpreting the value. This is used, for example, in the 385 "name" type, defined below. 387 The "encoding" type parameter is used to specify an alternate encoding 388 for a value. If the value contains a CRLF, it must be encoded, since 389 CRLF is used to separate lines in the content-type itself. Currently, 390 only the "b" encoding is supported. 392 The "b" encoding can also be useful for binary values that are mixed 393 with other text information in the body part (e.g., a certificate). 394 Using a per-value "b" encoding in this case leaves the other information 395 in a more readable form. The encoded base 64 value may be split across 396 multiple physical lines in the content type by using the line folding 397 technique described above. 399 Expires in six months INTERNET DRAFT 401 The Content-Transfer-Encoding header field is used to specify the encod- 402 ing used for the body part as a whole. The "encoding" type parameter is 403 used to specify an encoding for a particular value (e.g., a certifi- 404 cate). In this case, the Content-Transfer-Encoding header might specify 405 "8bit", while the one certificate value might specify an encoding of "b" 406 via an "encoding=b" type parameter. 408 Each type has associated with it a default encoding, taken from the 409 Content-Transfer-Encoding MIME header parameter. 411 The "value" parameter is optional, and MAY be used to identify the value 412 type (data type) and format of the value. The use of these predefined 413 formats is encouraged even if the value parameter is not explicity used. 414 By defining a standard set of value types and their formats, existing 415 parsing and processing code may be leveraged. 417 Including the value type explicitly as part of each property provides an 418 extra hint to keep parsing simple and support more generalized applica- 419 tions. For example a search engine would not have to know the particu- 420 lar value types for all of the items for which it is searching. Because 421 the value type is explicit in the definition, the search engine could 422 look for dates in any item type and provide results that may still be 423 interpreted. 425 5.8.4. Pre-defined Value Types 427 The format for values corresponding to the predefined valuetype specifi- 428 cations given above are defined. 430 valuespec = text-list 431 / genericurl ; from section 5 of RFC 1738 432 / date-list 433 / time-list 434 / date-time-list 435 / boolean 436 / integer-list 437 / float-list 438 / iana-valuespec 440 text-list = 1*TEXT-LIST-CHAR *("," *WSP 1*TEXT-LIST-CHAR) 442 TEXT-LIST-CHAR = "\," / "\n" / "\N" 443 / 444 ; newlines and commas must be encoded 446 date-list = date *("," *WSP date) 448 time-list = time *("," *WSP time) 450 Expires in six months INTERNET DRAFT 452 date-time-list = date "T" time 454 boolean = "TRUE" / "FALSE" 456 integer-list = integer *("," *WSP integer) 458 integer = [sign] 1*DIGIT 460 float-list = float *("," *WSP float) 462 float = [sign] 1*DIGIT ["." 1*DIGIT] 464 sign = "+" / "-" 466 date = date-fullyear ["-"] date-month ["-"] date-mday 468 date-fullyear = 4 DIGIT 470 date-month = 2 DIGIT ;01-12 472 date-mday = 2 DIGIT ;01-28, 01-29, 01-30, 01-31 473 ;based on month/year 475 time = time-hour [":"] time-minute [":"] time-second [time-secfrac] 476 [time-zone] 478 time-hour = 2 DIGIT ;00-23 480 time-minute = 2 DIGIT ;00-59 482 time-second = 2 DIGIT ;00-59 484 time-secfrac = "," 1*DIGIT 486 time-zone = "Z" / time-numzome 488 time-numzome = sign time-hour [":"] time-minute 490 iana-valuespec = 494 Some specific notes on the value types and formats: 496 "text": The "text" value type should be used to identify values that 497 contain human-readable text. The character set and language in which the 498 text is represented is controlled by the charset content-header and the 499 language type parameter and content-header. 501 Expires in six months INTERNET DRAFT 503 Examples for "text": 504 this is a text value 505 this is one value, this is another 506 this is a single value\, with a comma encoded 508 A formatted text line break in a text value type MUST be represented as 509 the character sequence backslash (ASCII decimal 92) followed by a Latin 510 small letter n (ASCII decimal 110) or a Latin capital letter N (ASCII 511 decimal 78), that is "\n" or "\N". 513 For example a multiple line DESCRIPTION value of: 515 Mythical Manager 516 Hyjinx Software Division 517 BabsCo, Inc. 519 could be represented as: 521 DESCRIPTION: Mythical Manager\nHyjinx Software Division\n 522 BabsCo\, Inc.\n 524 demonstrating both the \n literal formatted line break technique and the 525 CRLF-followed-by-space line folding technique. 527 "uri": The "uri" value type should be used to identify values that are 528 referenced by a URI (including a Content-ID URI), instead of encoded 529 in-line. These value references might be used if the value is too 530 large, or otherwise undesirable to include directly. The format for the 531 URI is as defined in RFC 1738. 533 Examples for "uri": 534 http://www.foobar.com/my/picture.jpg 535 ldap://ldap.foobar.com/cn=babs%20jensen 537 "date", "time", and "date-time": Each of these value types is based on 538 a subset of the definitions in ISO 8601 standard. Profiles MAY place 539 further restrictions on "date" and "time" values. Multiple "date" and 540 "time" values may be specified using the comma-separated notation, 541 unless restricted by a profile. 543 Examples for "date": 544 1985-04-12 545 1996-08-05, 1996-11-11 546 19850412 548 Examples for "time": 549 10:22:00 550 102200 552 Expires in six months INTERNET DRAFT 554 10:22:00.33 555 10:22:00.33Z 556 10:22:33, 11:22:00 557 10:22:00-08:00 559 Examples for "date-time": 560 1996-10-22T14:00:00Z 561 1996-08-11T12:34:56Z 562 19960811T123456Z 563 1996-10-22T14:00:00Z, 1996-08-11T12:34:56Z 565 "boolean": The "boolean" value type is used to express boolen values. 566 These values are case insensitive. 568 Examples: TRUE 569 false 570 True 572 "integer": The "integer" value type is used to express signed integers 573 in decimal format. If sign is not specified, the value is assumed posi- 574 tive "+". Multiple "integer" values may be specified using the comma- 575 separated notation, unless restricted by a profile. 577 Examples: 1234567890 578 -1234556790 579 +1234556790, 432109876 581 "float": The "float" value type is used to express real numbers. If 582 sign is not specified, the value is assumed positive "+". Multiple 583 "float" values may be specified using the comma-separated notation, 584 unless restricted by a profile. 586 Examples: 20.30 587 1000000.0000001 588 1.333, 3.14 590 5.9. Applications which use this media type 592 Applications which use this media type: Various 594 5.10. Additional information 596 Additional information: None 598 5.11. Person & email address to contact for further information 600 Tim Howes 602 Expires in six months INTERNET DRAFT 604 Netscape Communications Corp. 605 501 East Middlefield Rd. 606 Mountain View, CA 94041 607 USA 608 howes@netscape.com 609 +1 415 937 3419 611 5.12. Intended usage 613 Intended usage: COMMON 615 5.13. Author/Change controller 617 Tim Howes 618 Netscape Communications Corp. 619 501 East Middlefield Rd. 620 Mountain View, CA 94041 621 USA 622 howes@netscape.com 623 +1 415 937 3419 625 Mark Smith 626 Netscape Communications Corp. 627 501 East Middlefield Rd. 628 Mountain View, CA 94041 629 USA 630 mcs@netscape.com 631 +1 415 937 3477 633 Frank Dawson 634 Lotus Development Corporation 635 6544 Battleford Drive 636 Raleigh, NC 27613-3502 637 USA 638 frank_dawson@lotus.com 639 +1-919-676-9515 641 6. Predefined Types 643 The following types are generally useful regardless of the profile being 644 carried and are defined below using the text/directory MIME type regis- 645 tration template defined in Section 11.1 of this document. These types 646 MAY be included in any profile, unless explicitly forbidden in the pro- 647 file definition. 649 6.1. SOURCE Type Definition 651 To: ietf-mime-direct@imc.org 653 Expires in six months INTERNET DRAFT 655 Subject: Registration of text/directory MIME type SOURCE 657 Type name: SOURCE 659 Type purpose: To identify the source of directory information con- 660 tained in the content type. 662 Type encoding: 8bit 664 Type valuetype: text containing a URI. 666 Type special notes: The SOURCE type is used to provide the means by 667 which applications knowledgable in the given directory service proto- 668 col may obtain additional or more up-to-date information from the 669 directory service. It contains a URI as defined in [RFC-1738] and/or 670 other information referencing the directory entity or entities to 671 which the information pertains. When directory information is avail- 672 able from more than one source, the sending entity may pick what it 673 considers to be the best source, or multiple SOURCE types may be 674 included. The interpretation of the value for a SOURCE type may 675 depend on the setting of the CONTEXT type parameter. 677 Type example: 678 SOURCE;CONTEXT=LDAP: ldap://ldap.host/cn=Babs%20Jensen, 679 %20o=Babsco,%20c=US 681 6.2. NAME Type Definition 683 To: ietf-mime-direct@imc.org 684 Subject: Registration of text/directory MIME type NAME 686 Type name: NAME 688 Type purpose: To identify the displayable name of the directory 689 entity to which information in the content type pertains. 691 Type encoding: 8bit 693 Type valuetype: text 695 Type special notes: The NAME type is used to convey the display name 696 of the entity to which the directory information pertains. 698 Type example: 699 NAME: Babs Jensen's Contact Information 701 Expires in six months INTERNET DRAFT 703 6.3. PROFILE Type Definition 705 To: ietf-mime-direct@imc.org 706 Subject: Registration of text/directory MIME type PROFILE 708 Type name: PROFILE 710 Type purpose: To identify the type of directory entity to which 711 information in the content type pertains. 713 Type encoding: 8bit 715 Type valuetype: text, containing a profile name, registered as 716 described in Section 9 of this document or bilaterally-agreed upon as 717 described in Section 5. 719 Type special notes: The PROFILE type is used to convey the type of 720 the entity to which the directory information in the rest of the body 721 part pertains. It should be the same as the "profile" header parame- 722 ter, if present. 724 Type example: 725 PROFILE: vCard 727 6.4. BEGIN Type Definition 729 To: ietf-mime-direct@imc.org 730 Subject: Registration of text/directory MIME type BEGIN 732 Type name: BEGIN 734 Type purpose: To delimit the beginning of a syntactic entity within a 735 text/directory content-type. 737 Type encoding: 8bit 739 Type valuetype: text, containing a profile name, registered as 740 described in Section 9 of this document or bilaterally-agreed upon as 741 described in Section 5. 743 Type special notes: The BEGIN type is used in conjunction with the 744 END type to delimit a profile containing a related set of properties 745 within an text/directory content-type. This construct may be used 746 instead of or in addition to wrapping separate sets of information 747 inside additional MIME headers. It is provided for applications that 748 wish to define content that may contain multiple entities within the 749 same text/directory content-type or to define content that may be 750 identifiable outside of a MIME environment. 752 Expires in six months INTERNET DRAFT 754 Type example: 755 BEGIN: VCARD 757 6.5. END Type Definition 759 To: ietf-mime-direct@imc.org 760 Subject: Registration of text/directory MIME type END 762 Type name: END 764 Type purpose: To delimit the end of a syntactic entity within a 765 text/directory content-type. 767 Type encoding: 8bit 769 Type valuetype: text, containing a profile name, registered as 770 described in Section 9 of this document or bilaterally-agreed upon as 771 described in Section 5. 773 Type special notes: The END type is used in conjunction with the 774 BEGIN type to delimit a profile containing a related set of proper- 775 ties within an text/directory content-type. This construct may be 776 used instead of or in addition to wrapping separate sets of informa- 777 tion inside additional MIME headers. It is provided for applications 778 that wish to define content that may contain multiple entities within 779 the same text/directory content-type or to define content that may be 780 identifiable outside of a MIME environment. 782 Type example: 783 END: VCARD 785 7. Use of the multipart/related Content-Type 787 The multipart/related Content-Type can be used to hold directory infor- 788 mation comprised of both text and non-text information or directory 789 information that already has a natural MIME representation. The root 790 body part within the multipart/related body part is specified as defined 791 in [RFC-2112] by a "start" parameter, or it is the first body part in 792 the absence of such a parameter. The root body part must have a 793 Content-Type of "text/directory". This part holds inline information 794 and makes reference to subsequent body parts holding additional text or 795 non-text directory information via their Content-ID URIs as explained in 796 Section 5. 798 The body parts referred to do not have to be in any particular order, 799 except as noted above for the root body part. 801 Expires in six months INTERNET DRAFT 803 8. Examples 805 The following examples are for illustrative purposes only and are not 806 part of the definition. 808 8.1. Example 1 810 The first example illustrates simple use of the text/directory Content- 811 Type. Note that no "profile" parameter is given, so an application may 812 not know what kind of directory entity the information applies to. Note 813 also the use of both hypothetical official and bilaterally agreed upon 814 types. 816 From: Whomever@wherever.com 817 To: Someone@somewhere.com 818 Subject: whatever 819 MIME-Version: 1.0 820 Message-ID: 821 Content-Type: text/directory 822 Content-ID: 824 cn: Babs Jensen 825 cn: Barbara J Jensen 826 sn: Jensen 827 email: babs@umich.edu 828 phone: +1 313 747-4454 829 x-id: 1234567890 831 8.2. Example 2 833 The next example illustrates the use of the Quoted-Printable transfer 834 encoding defined in [RFC 2045] to include non-ASCII character in some of 835 the information returned, and the use of the optional "name" and 836 "source" types. It also illustrates the use of an "encoding" type param- 837 eter to encode a certificate value in "b". A "vCard" profile [MIME- 838 VCARD] is used for the example. 840 Content-Type: text/directory; 841 charset="iso-8859-1"; 842 profile="vCard" 843 Content-ID: 844 Content-Transfer-Encoding: Quoted-Printable 846 begin: VCARD 847 source: ldap://cn=3Dbjorn%20Jensen, o=3Duniversity%20of%20Michigan, c=3DUS 848 name: Bjorn Jensen 849 fn: Bj=F8rn Jensen 850 n: Jensen;Bj=F8rn 852 Expires in six months INTERNET DRAFT 854 email;type=3Dinternet: bjorn@umich.edu 855 tel;type=3Dwork,voice,msg:+1 313 747-4454 856 key;type=3Dx509;encoding=3DB: dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK 857 end: VCARD 859 8.3. Example 3 861 The next example illustrates the use of multi-valued type parameters, 862 the "language" type parameter, the "value" type parameter, folding of 863 long lines, the \n encoding for formatted lines, attribute grouping, and 864 the inline "b" encoding. A "vCard" profile [MIME-VCARD] is used for the 865 example. 867 Content-Type: text/directory; profile="vcard"; charset=iso-8859-1 868 Content-ID: 869 Content-Transfer-Encoding: Quoted-Printable 871 begin: vcard 872 source: ldap://cn=Meister%20Berger,o=Universitaet%20Goerlitz,c=DE 873 name: Meister Berger 874 fn: Meister Berger 875 n: Berger;Meister 876 bday;value=date: 1963-09-21 877 o: Universit=E6t G=F6rlitz 878 title: Mayor 879 title;language=de;value=text: Burgermeister 880 note: The Mayor of the great city of 881 Goerlitz in the great country of Germany. 882 email;internet: mb@goerlitz.de 883 home.tel;fax,voice,msg: +49 3581 123456 884 home.label: Hufenshlagel 1234\n 885 02828 Goerlitz\n 886 Deutschland 887 key;type=X509;encoding=b: MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQ 888 AwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zI 889 ENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQD 890 ExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNjE5NDc1OVoXDTk3MTIwMzE5NDc 891 1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYDVQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW 892 9ucyBDb3JwLjEYMBYGA1UEAxMPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBF 893 hJob3dlc0BuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqG 894 SIb3DQEBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2dXc 895 oX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MBEGCWCGSAGG+E 896 IBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9 897 w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIPmx93HGp0Kgyx1jIVMyNgsemeAwBM+M 898 SlhMfcpbTrONwNjZYW8vJDSoi//yrZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8V 899 UMk1U7jt8LYpo4YULU7UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ== 900 end: vcard 902 Expires in six months INTERNET DRAFT 904 8.4. Example 4 906 The final example illustrates the use of the multipart/related Content- 907 Type to include non-textual directory data via the "uri" encoding to 908 refer to other body parts within the same message, or to external 909 values. Note that no "profile" parameter is given, so an application 910 may not know what kind of directory entity the information applies to. 911 Note also the use of both hypothetical official and bilaterally agreed 912 upon types. 914 Content-Type: multipart/related; 915 boundary=woof; 916 type="text/directory"; 917 start="" 918 Content-ID: 920 --woof 921 Content-Type: text/directory; charset="iso-8859-1" 922 Content-ID: 923 Content-Transfer-Encoding: Quoted-Printable 925 source: ldap://cn=3DBjorn%20Jensen,o=3DUniversity%20of%20Michigan,c=3DUS 926 cn: Bj=F8rn Jensen 927 sn: Jensen 928 email: bjorn@umich.edu 929 image;encoding=3Duri: cid:id6@host.com 930 image;encoding=3Duri;format=3Djpeg: ftp://some.host/some/path.jpg 931 sound;encoding=3Duri: cid:id7@host.com 932 phone: +1 313 747-4454 934 --woof 935 Content-Type: image/jpeg 936 Content-ID: 938 <...image data...> 940 --woof 941 Content-Type: message/external-body; 942 name="myvoice.au"; 943 site="myhost.com"; 944 access-type=ANON-FTP; 945 directory="pub/myname"; 946 mode="image" 948 Content-Type: audio/basic 949 Content-ID: 951 --woof-- 953 Expires in six months INTERNET DRAFT 955 9. Registration of new profiles 957 This section defines procedures by which new profiles are registered 958 with the IANA and made available to the Internet community. Note that 959 non-IANA profiles may be used by bilateral agreement, provided the asso- 960 ciated profile names follow the "X-" convention defined above. 962 The procedures defined here are designed to allow public comment and 963 review of new profiles, while posing only a small impediment to the 964 definition of new profiles. 966 Registration of a new profile is accomplished by the following steps. 968 9.1. Define the profile 970 A profile is defined by completing the following template. 972 To: ietf-mime-direct@imc.org 973 Subject: Registration of text/directory MIME profile XXX 975 Profile name: 977 Profile purpose: 979 Profile types: 981 Profile special notes (optional): 983 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 985 The explanation of what goes in each field in the template follows. 987 Profile name: The name of the profile as it will appear in the 988 text/directory MIME Content-Type "profile" header parameter, or the 989 predefined "profile" type name. 991 Profile purpose: The purpose of the profile (e.g., to represent informa- 992 tion about people, printers, documents, etc.). Give a short but clear 993 description. 995 Profile types: The list of types associated with the profile. This list 996 of types is to be expected but not required in the profile, unless oth- 997 erwise noted in the profile definition. Other types not mentioned in 998 the profile definition may also be present. Note that any new types 999 referenced by the profile must be defined separately as described in 1000 Section 10. 1002 Profile special notes: Any special notes about the profile, how it is to 1003 Expires in six months INTERNET DRAFT 1005 be used, etc. This section of the template may also be used to define an 1006 ordering on the types that appear in the Content-Type, if such an order- 1007 ing is required. 1009 9.2. Post the profile definition 1011 The profile description must be posted to the new profile discussion 1012 list, ietf-mime-direct@imc.org 1014 9.3. Allow a comment period 1016 Discussion on the new profile must be allowed to take place on the list 1017 for a minimum of two weeks. Consensus must be reached on the profile 1018 before proceeding to step 4. 1020 9.4. Submit the profile for approval 1022 Once the two-week comment period has elapsed, and the proposer is con- 1023 vinced consensus has been reached on the profile, the registration 1024 application should be submitted to the Profile Reviewer for approval. 1025 The Profile Reviewer is appointed to the Application Area Directors and 1026 may either accept or reject the profile registration. An accepted regis- 1027 tration should be passed on by the Profile Reviewer to the IANA for 1028 inclusion in the official IANA profile registry. The registration may be 1029 rejected for any of the following reasons. 1) Insufficient comment 1030 period; 2) Consensus not reached; 3) Technical deficiencies raised on 1031 the list or elsewhere have not been addressed. The Profile Reviewer's 1032 decision to reject a profile may be appealed by the proposer to the 1033 IESG, or the objections raised can be addressed by the proposer and the 1034 profile resubmitted. 1036 10. Profile Change Control 1038 Existing profiles may be changed using the same process by which they 1039 were registered. 1041 Define the change 1043 Post the change 1045 Allow a comment period 1047 Submit the changed profile for approval 1049 Note that the original author or any other interested party may propose 1050 a change to an existing profile, but that such changes should only be 1051 proposed when there are serious omissions or errors in the published 1052 specification. The Profile Reviewer may object to a change if it is not 1053 Expires in six months INTERNET DRAFT 1055 backwards compatible, but is not required to do so. 1057 Profile definitions can never be deleted from the IANA registry, but 1058 profiles which are no longer believed to be useful can be declared 1059 OBSOLETE by a change to their "intended use" field. 1061 11. Registration of new types 1063 This section defines procedures by which new types are registered with 1064 the IANA. Note that non-IANA types may be used by bilateral agreement, 1065 provided the associated types names follow the "X-" convention defined 1066 above. 1068 The procedures defined here are designed to allow public comment and 1069 review of new types, while posing only a small impediment to the defini- 1070 tion of new types. 1072 Registration of a new type is accomplished by the following steps. 1074 11.1. Define the type 1076 A type is defined by completing the following template. 1078 To: ietf-mime-direct@imc.org 1079 Subject: Registration of text/directory MIME type XXX 1081 Type name: 1083 Type purpose: 1085 Type encoding: 1087 Type valuetype: 1089 Type special notes (optional): 1091 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1093 The meaning of each field in the template is as follows. 1095 Type name: The name of the type, as it will appear in the body of an 1096 text/directory MIME Content-Type "type: value" line to the left of the 1097 colon ":". 1099 Type purpose: The purpose of the type (e.g., to represent a name, postal 1100 address, IP address, etc.). Give a short but clear description. 1102 Type encoding: The default encoding a value of the type must have in the 1103 Expires in six months INTERNET DRAFT 1105 body of a text/directory MIME Content-Type. 1107 Type valuetype: The format a value of the type must have in the body of 1108 a text/directory MIME Content-Type. This description must be precise and 1109 must not violate the general encoding rules defined in section 5 of this 1110 document. 1112 Type special notes: Any special notes about the type, how it is to be 1113 used, etc. 1115 11.2. Post the type definition 1117 The type description must be posted to the new type discussion list, 1118 ietf-mime-direct@imc.org 1120 11.3. Allow a comment period 1122 Discussion on the new type must be allowed to take place on the list for 1123 a minimum of two weeks. Consensus must be reached on the type before 1124 proceeding to step 4. 1126 11.4. Submit the type for approval 1128 Once the two-week comment period has elapsed, and the proposer is con- 1129 vinced consensus has been reached on the type, the registration applica- 1130 tion should be submitted to the Profile Reviewer for approval. The Pro- 1131 file Reviewer is appointed to the Application Area Directors and may 1132 either accept or reject the type registration. An accepted registration 1133 should be passed on by the Profile Reviewer to the IANA for inclusion in 1134 the official IANA profile registry. The registration may be rejected for 1135 any of the following reasons. 1) Insufficient comment period; 2) Con- 1136 sensus not reached; 3) Technical deficiencies raised on the list or 1137 elsewhere have not been addressed. The Profile Reviewer's decision to 1138 reject a type may be appealed by the proposer to the IESG, or the objec- 1139 tions raised can be addressed by the proposer and the type resubmitted. 1141 12. Type Change Control 1143 Existing types may be changed using the same process by which they were 1144 registered. 1146 Define the change 1148 Post the change 1150 Allow a comment period 1152 Submit the type for approval 1154 Expires in six months INTERNET DRAFT 1156 Note that the original author or any other interested party may propose 1157 a change to an existing type, but that such changes should only be pro- 1158 posed 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 Type definitions can never be deleted from the IANA registry, but types 1163 which are nolonger believed to be useful can be declared OBSOLETE by a 1164 change to their "intended use" field. 1166 13. Registration of new parameters 1168 This section defines procedures by which new parameters are registered 1169 with the IANA and made available to the Internet community. Note that 1170 non-IANA parameters may be used by bilateral agreement, provided the 1171 associated parameters names follow the "X-" convention defined above. 1173 The procedures defined here are designed to allow public comment and 1174 review of new parameters, while posing only a small impediment to the 1175 definition of new parameters. 1177 Registration of a new parameter is accomplished by the following steps. 1179 13.1. Define the parameter 1181 A parameter is defined by completing the following template. 1183 To: ietf-mime-direct@imc.org 1184 Subject: Registration of text/directory MIME type parameter XXX 1186 Parameter name: 1188 Parameter purpose: 1190 Parameter values: 1192 Parameter special notes (optional): 1194 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1196 The explanation of what goes in each field in the template follows. 1198 Parameter name: The name of the parameter as it will appear in the 1199 text/directory MIME Content-Type. 1201 Parameter purpose: The purpose of the parameter (e.g., to represent the 1202 format of an image, type of a phone number, etc.). Give a short but 1203 clear description. If defining a general paramemter like "format" or 1204 Expires in six months INTERNET DRAFT 1206 "type" keep in mind that other applications may wish to extend its use. 1208 Parameter values: The list or description of values associated with the 1209 parameter. 1211 Parameter special notes: Any special notes about the parameter, how it 1212 is to be used, etc. 1214 13.2. Post the parameter definition 1216 The parameter description must be posted to the new parameter discussion 1217 list, ietf-mime-direct@imc.org 1219 13.3. Allow a comment period 1221 Discussion on the new parameter must be allowed to take place on the 1222 list for a minimum of two weeks. Consensus must be reached on the param- 1223 eter before proceeding to step 4. 1225 13.4. Submit the parameter for approval 1227 Once the two-week comment period has elapsed, and the proposer is con- 1228 vinced consensus has been reached on the parameter, the registration 1229 application should be submitted to the Profile Reviewer for approval. 1230 The Profile Reviewer is appointed to the Application Area Directors and 1231 may either accept or reject the parameter registration. An accepted 1232 registration should be passed on by the Profile Reviewer to the IANA for 1233 inclusion in the official IANA parameter registry. The registration may 1234 be rejected for any of the following reasons. 1) Insufficient comment 1235 period; 2) Consensus not reached; 3) Technical deficiencies raised on 1236 the list or elsewhere have not been addressed. The Profile Reviewer's 1237 decision to reject a profile may be appealed by the proposer to the 1238 IESG, or the objections raised can be addressed by the proposer and the 1239 parameter registration resubmitted. 1241 14. Parameter Change Control 1243 Existing parameters may be changed using the same process by which they 1244 were registered. 1246 Define the change 1248 Post the change 1250 Allow a comment period 1252 Submit the parameter for approval 1254 Expires in six months INTERNET DRAFT 1256 Note that the original author or any other interested party may propose 1257 a change to an existing parameter, but that such changes should only be 1258 proposed when there are serious omissions or errors in the published 1259 specification. The Profile Reviewer may object to a change if it is not 1260 backwards compatible, but is not required to do so. 1262 Parameter definitions can never be deleted from the IANA registry, but 1263 parameters which are nolonger believed to be useful can be declared 1264 OBSOLETE by a change to their "intended use" field. 1266 15. Registration of new value types 1268 This section defines procedures by which new value types are registered 1269 with the IANA and made available to the Internet community. Note that 1270 non-IANA value types may be used by bilateral agreement, provided the 1271 associated value types names follow the "X-" convention defined above. 1273 The procedures defined here are designed to allow public comment and 1274 review of new value types, while posing only a small impediment to the 1275 definition of new value types. 1277 Registration of a new value types is accomplished by the following 1278 steps. 1280 15.1. Define the value type 1282 A value type is defined by completing the following template. 1284 To: ietf-mime-direct@imc.org 1285 Subject: Registration of text/directory MIME value type XXX 1287 value type name: 1289 value type purpose: 1291 value type format: 1293 value type special notes (optional): 1295 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1297 The explanation of what goes in each field in the template follows. 1299 value type name: The name of the value type as it will appear in the 1300 text/directory MIME Content-Type. 1302 value type purpose: The purpose of the value type. Give a short but 1303 Expires in six months INTERNET DRAFT 1305 clear description. 1307 value type format: The definition of the format for the value, usually 1308 using ABNF grammar. 1310 value type special notes: Any special notes about the value type, how 1311 it is to be used, etc. 1313 15.2. Post the value type definition 1315 The value type description must be posted to the new value type discus- 1316 sion list, ietf-mime-direct@imc.org 1318 15.3. Allow a comment period 1320 Discussion on the new value type must be allowed to take place on the 1321 list for a minimum of two weeks. Consensus must be reached before 1322 proceeding to step 4. 1324 15.4. Submit the value type for approval 1326 Once the two-week comment period has elapsed, and the proposer is con- 1327 vinced consensus has been reached on the value type, the registra- 1328 tion application should be submitted to the Profile Reviewer for 1329 approval. The Profile Reviewer is appointed to the Application Area 1330 Directors and may either accept or reject the value type registration. 1331 An accepted registration should be passed on by the Profile Reviewer to 1332 the IANA for inclusion in the official IANA value type registry. The 1333 registration may be rejected for any of the following reasons. 1) 1334 Insufficient comment period; 2) Consensus not reached; 3) Technical 1335 deficiencies raised on the list or elsewhere have not been 1336 addressed. The Profile Reviewer's decision to reject a profile may be 1337 appealed by the proposer to the IESG, or the objections raised can 1338 be addressed by the proposer and the value type registration resubmit- 1339 ted. 1341 16. Security Considerations 1343 Internet mail is subject to many well known security attacks, including 1344 monitoring, replay, and forgery. Care should be taken by any directory 1345 service in allowing information to leave the scope of the service 1346 itself, where any access controls can no longer be guaranteed. Applica- 1347 tions should also take care to display directory data in a "safe" 1348 environment (e.g., PostScript-valued types). 1350 Expires in six months INTERNET DRAFT 1352 17. Acknowledgements 1354 The registration procedures defined here were shamelessly lifted from 1355 the MIME registration RFC. 1357 The many valuable comments contributed by members of the IETF ASID work- 1358 ing group are gratefully acknowledged, as are the contributions of the 1359 Versit Consortium. Chris Newman was especially helpful in navigating the 1360 intricacies of ABNF lore. 1362 18. References 1364 [RFC-1777] Yeong, W., Howes, T., Kille, S., "Lightweight Directory 1365 Access Protocol", Request for Comment (RFC) 1777, March 1995. 1367 [RFC-1778] Howes, T., Kille, S., Yeong, W., Robbins, C.J., "The String 1368 Representation of Standard Attribute Syntaxes", Request for 1369 Comment (RFC) 1778, March 1995. 1371 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 1372 Messages", STD 11, RFC 822, August 1982. 1374 [RFC-2045] Borenstein, N., Freed, N., "Multipurpose Internet Mail Exten- 1375 sions (MIME) Part One: Format of Internet Message Bodies", 1376 RFC 2045, November 1996. 1378 [RFC-2046] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part 1379 Two: Media Types", RFC 2046, November 1996. 1381 [RFC-2048] Freed, N., Klensin, J., Postel, J., "Multipurpose Internet 1382 Mail Extensions (MIME) Part Four: Registration Procedures", 1383 RFC 2048, November 1996 1385 [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", 1386 RFC 1766, March 1995. 1388 [RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type," RFC 1389 2112, March 1997. 1391 [X500] "Information Processing Systems - Open Systems Interconnec- 1392 tion - The Directory: Overview of Concepts, Models and Ser- 1393 vices", ISO/IEC JTC 1/SC21, International Standard 9594-1, 1394 1988. 1396 [RFC-1835] Deutsch, P., Schoultz, R., Faltstrom, P., Weider, C., "Archi- 1397 tecture of the WHOIS++ service", August 1995. 1399 [RFC-1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform 1400 Expires in six months INTERNET DRAFT 1402 Resource Locators (URL)", RFC 1738, December 1994. 1404 [MIME-VCARD]F. Dawson, T. Howes, "VCard MIME Directory Profile", RFC 1405 XXXX, March 1998. 1407 [VCARD] Internet Mail Consortium, "vCard - The Electronic Business 1408 Card", Version 2.1, http://www.imc.com/pdi/vcard-21.txt, Sep- 1409 tember, 1996. 1411 [RFC-2119] "Key words for use in RFCs to Indicate Requirement Levels", 1412 RFC 2119, March 1997. 1414 [RFC-2234] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifi- 1415 cations: ABNF", RFC 2234, November 1997. 1417 19. Author's Address 1419 Tim Howes 1420 Netscape Communications Corp. 1421 501 East Middlefield Rd. 1422 Mountain View, CA 94041 1423 USA 1424 howes@netscape.com 1425 +1.415.937.3419 1427 Mark Smith 1428 Netscape Communications Corp. 1429 501 East Middlefield Rd. 1430 Mountain View, CA 94041 1431 USA 1432 mcs@netscape.com 1433 +1.415.937.3477 1435 Frank Dawson 1436 Lotus Development Corporation 1437 6544 Battleford Drive 1438 Raleigh, NC 27613 1439 USA 1440 frank_dawson@lotus.com 1441 +1-919-676-9515 1443 Expires in six months INTERNET DRAFT 1445 20. Table of Contents 1447 1. Status of this Memo..............................................1 1448 2. Abstract.........................................................1 1449 3. Need for a MIME Directory Type...................................2 1450 4. Overview.........................................................2 1451 5. The text/directory Content-Type..................................3 1452 5.1. MIME media type name...........................................3 1453 5.2. MIME subtype name..............................................3 1454 5.3. Required parameters............................................3 1455 5.4. Optional parameters............................................3 1456 5.5. Encoding considerations........................................4 1457 5.6. Security considerations........................................4 1458 5.7. Interoperability considerations................................4 1459 5.8. Published specification........................................5 1460 5.8.1. Line delimiting and folding..................................5 1461 5.8.2. ABNF content-type definition.................................5 1462 5.8.3. Pre-defined Parameters.......................................7 1463 5.8.4. Pre-defined Value Types......................................9 1464 5.9. Applications which use this media type.........................12 1465 5.10. Additional information........................................12 1466 5.11. Person & email address to contact for further information.....12 1467 5.12. Intended usage................................................13 1468 5.13. Author/Change controller......................................14 1469 6. Predefined Types.................................................13 1470 6.1. SOURCE Type Definition.........................................13 1471 6.2. NAME Type Definition...........................................14 1472 6.3. PROFILE Type Definition........................................15 1473 6.4. BEGIN Type Definition..........................................15 1474 6.5. END Type Definition............................................16 1475 7. Use of the multipart/related Content-Type........................16 1476 8. Examples.........................................................17 1477 8.1. Example 1......................................................17 1478 8.2. Example 2......................................................17 1479 8.3. Example 3......................................................18 1480 8.4. Example 4......................................................19 1481 9. Registration of new profiles.....................................20 1482 9.1. Define the profile.............................................20 1483 9.2. Post the profile definition....................................21 1484 9.3. Allow a comment period.........................................21 1485 9.4. Submit the profile for approval................................21 1486 10. Profile Change Control..........................................21 1487 11. Registration of new types.......................................22 1488 11.1. Define the type...............................................22 1489 11.2. Post the type definition......................................23 1490 11.3. Allow a comment period........................................23 1491 11.4. Submit the type for approval..................................23 1492 12. Type Change Control.............................................23 1493 Expires in six months INTERNET DRAFT 1495 13. Registration of new parameters..................................24 1496 13.1. Define the parameter..........................................24 1497 13.2. Post the parameter definition.................................25 1498 13.3. Allow a comment period........................................25 1499 13.4. Submit the parameter for approval.............................25 1500 14. Parameter Change Control........................................25 1501 15. Registration of new value types.................................26 1502 15.1. Define the value type.........................................26 1503 15.2. Post the value type definition................................27 1504 15.3. Allow a comment period........................................27 1505 15.4. Submit the value type for approval............................27 1506 16. Security Considerations.........................................27 1507 17. Acknowledgements................................................28 1508 18. References......................................................28 1509 19. Author's Address................................................29 1510 20. Table of Contents...............................................30