idnits 2.17.1 draft-ietf-asid-mime-direct-07.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-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 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 29 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 302 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 16 instances of lines with control characters in the document. ** 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 ...' == (297 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 (April 20, 1998) is 9503 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 865, but not defined == Missing Reference: 'RFC 2045' is mentioned on line 836, but not defined == Unused Reference: 'VCARD' is defined on line 1410, but no explicit reference was found in the text == Unused Reference: 'RFC-2234' is defined on line 1417, 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 INTERNET DRAFT Mark Smith 4 draft-ietf-asid-mime-direct-07.txt Netscape Communications Corp. 5 Frank Dawson 6 Lotus Development Corporation 7 April 20, 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), ftp.ietf.org (US East Coast, or ftp.isi.edu 27 (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, is to 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. We 47 Expires in six months INTERNET DRAFT 49 refer to "type" in this context meaning a property or attribute with 50 which the value is associated. Mechanisms are defined to specify alter- 51 nate languages, encodings and other meta-information. This document also 52 defines the procedure by which particular formats, called profiles, for 53 carrying application-specific information within a text/directory 54 Content-Type can be defined and registered, and the conventions such 55 formats must follow. It is expected that other documents will be pro- 56 duced that define such formats for various applications (e.g., white 57 pages). 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 61 document are to be interpreted as described in [RFC-2119]. 63 3. Need for a MIME Directory Type 65 For purposes of this document, a directory is a special-purpose database 66 that contains typed information. A directory usually supports both read 67 and search of the information it contains, and can support creation and 68 modification of the information as well. Directory information is usu- 69 ally accessed far more often than it is updated. Directories can be 70 local or global in scope. They can be distributed or centralized. The 71 information they contain can be replicated, with weak or strong con- 72 sistency requirements. 74 There are several situations in which users of Internet mail might wish 75 to exchange directory information: the email analogy of a "business 76 card" exchange; the conveyance of directory information to a user having 77 only email access to the Internet; the provision of machine-parseable 78 address information when purchasing goods or services over the Internet; 79 etc. As MIME [RFC-2045,RFC-2046] is used increasingly by other proto- 80 cols, most notably HTTP, it can also be useful for these protocols to 81 carry directory information in MIME format. Such a format, for example, 82 could be used to represent URC (uniform resource characteristics) infor- 83 mation about resources on the World Wide Web, or to provide a rudimen- 84 tary directory service over HTTP. 86 4. Overview 88 The scheme defined here for representing directory information in a MIME 89 Content-Type has two parts. First, the text/directory Content-Type is 90 defined for use in holding directory information within a single body 91 part, for example name, title, or email address. In its simplest form, 92 the format uses a "type:value" approach, which should be easily parse- 93 able by existing MIME implementations and understandable by users. More 94 complicated situations can be represented also. This document defines 95 the general form the information in the Content-Type should have, and 96 the procedure by which specific types and values (properties) for 97 Expires in six months INTERNET DRAFT 99 particular applications can be defined. The framework is general enough 100 to handle information from any number of end directory services, includ- 101 ing LDAP [RFC-1777, RFC-1778], WHOIS++ [RFC-1835], and X.500 [X500]. 103 Directory entries can include far more than just textual information. 104 Some such information (e.g., an image or sound) overlaps with predefined 105 MIME Content-Types. In these cases it can be desirable to include the 106 information in its well-known MIME format. This situation is handled by 107 using a multipart/related Content-Type as defined in [RFC-2112]. The 108 root component of this type is a text/directory body part specifying any 109 in-line information, and for information contained in other Content- 110 Types, the Content-IDs (in URI form) of those parts. 112 In some applications, it can be useful to include a pointer (e.g, a URI) 113 to some directory information rather than the information itself. This 114 document defines a general mechanism for accomplishing this. 116 5. The text/directory Content-Type 118 The text/directory Content-Type is used to hold basic directory informa- 119 tion and URIs referencing other information, including other MIME body 120 parts holding supplementary or non-textual directory information, such 121 as an image or sound. It is defined as follows, using the MIME media 122 type registration template from [RFC-2048]. 124 To: ietf-types@uninett.no 125 Subject: Registration of MIME media type text/directory 127 5.1. MIME media type name 129 MIME media type name: text 131 5.2. MIME subtype name 133 MIME subtype name: directory 135 5.3. Required parameters 137 Required parameters: charset 139 The "charset" parameter is as defined in [RFC-2046] for other body 140 parts. It is used to identify the default character set used within the 141 body part. 143 5.4. Optional parameters 145 Optional parameters: profile 146 Expires in six months INTERNET DRAFT 148 The "profile" parameter is used to convey the type(s) of entity(ies) to 149 which the directory information pertains and the likely set of informa- 150 tion associated with the entity(ies). It is intended only as a guide to 151 applications interpreting the information contained within the body 152 part. It SHOULD NOT be used to exclude or require particular pieces of 153 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 can 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-" 1*(ALPHA / DIGIT / "-") 165 ; Names beginning with "x-" or "X-" are 166 ; reserved for experimental use not intended for released 167 ; products, or for use in bilateral agreements. 169 iana-token = 173 5.5. Encoding considerations 175 The default encoding is 8bit. Otherwise, as specified by the Content- 176 Transfer-Encoding header field. 178 5.6. Security considerations 180 Directory information can be public or it can be protected from unau- 181 thorized access by the directory service in which it resides. Once the 182 information leaves its native service, there can be no guarantee that 183 the same care will be taken by all services handling the information. 184 Furthermore, this specification defines no access control mechanism by 185 which information can be protected, or by which access control informa- 186 tion can be conveyed. Note that the integrity and privacy of a 187 text/directory body part can be protected by enclosing it within an 188 appropriate MIME-based security mechanism. 190 5.7. Interoperability considerations 192 In order to make sense of directory information, applications must share 193 a common understanding of the types of information contained within the 194 Content-Type (the directory schema). This schema information is not 195 Expires in six months INTERNET DRAFT 197 defined in this document, but rather in companion documents (e.g., 198 [MIME-VCARD]) that follow the requirements specified in this document, 199 or in bilateral agreements between communicating parties. 201 5.8. Published specification 203 The text/directory Content-Type contains directory information, typi- 204 cally pertaining to a single directory entity or group of entities. The 205 content consists of one or more lines in the format given below. 207 5.8.1. Line delimiting and folding 209 Individual lines within the MIME text/directory Content Type body are 210 delimited by the [RFC-822] line break, which is a CRLF sequence (ASCII 211 decimal 13, followed by ASCII decimal 10). Long logical lines of text 212 can be split into a multiple-physical-line representation using the fol- 213 lowing folding technique. 215 A logical line MAY be continued on the next physical line anywhere 216 between two characters by inserting a CRLF immediately followed by a 217 single white space character (space, ASCII decimal 32, or horizontal 218 tab, ASCII decimal 9). At least one character must be present on the 219 folded line. Any sequence of CRLF followed immediately by a single white 220 space character is ignored (removed) when processing the content type. 221 For example the line: 223 DESCRIPTION:This is a long description that exists on a long line. 225 Can be represented as: 227 DESCRIPTION:This is a long description 228 that exists on a long line. 230 It could also be represented as: 232 DESCRIPTION:This is a long descrip 233 tion that exists o 234 n a long line. 236 The process of moving from this folded multiple-line representation of a 237 type definition to its single line representation is called unfolding. 238 Unfolding is accomplished by regarding CRLF immediately followed by a 239 white space character (namely HTAB ASCII decimal 9 or SPACE ASCII 240 decimal 32) as equivalent to no characters at all (i.e., the CRLF and 241 single white space character are removed). 243 Expires in six months INTERNET DRAFT 245 5.8.2. ABNF content-type definition 247 The following ABNF uses the notation of RFC 2234, which also defines 248 CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. After the unfolding of any 249 folded lines as described above, the syntax for a line of this content 250 type is as follows: 252 contentline = [group "."] name *(";" param) ":" value CRLF 253 ; When parsing a content line, folded lines MUST first 254 ; be unfolded according to the unfolding procedure 255 ; described above. 256 ; When generating a content line, lines longer than 75 257 ; characters SHOULD be folded according to the folding 258 ; procedure described above. 260 group = 1*(ALPHA / DIGIT / "-") 262 name = x-name / iana-token 264 iana-token = 1*(ALPHA / DIGIT / "-") 265 ; identifier registered with IANA 267 x-name = "x-" 1*(ALPHA / DIGIT / "-") 268 ; Names that begin with "x-" or "X-" are 269 ; reserved for experimental use, not intended for released 270 ; products, or for use in bilateral agreements. 272 param = param-name "=" param-value *("," param-value) 274 param-name = x-name / iana-token 276 param-value = ptext / quoted-string 278 ptext = *SAFE-CHAR 280 value = *VALUE-CHAR 281 / valuespec ; valuespec defined in section 5.8.4 283 quoted-string = DQUOTE *QSAFE-CHAR DQUOTE 285 NON-ASCII = %x80-FF 286 ; use restricted by charset parameter 287 ; on outer MIME object (UTF-8 preferred) 289 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII 290 ; Any character except CTLs, DQUOTE 292 SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII 294 Expires in six months INTERNET DRAFT 296 ; Any character except CTLs, DQUOTE, ";", ":", "," 298 VALUE-CHAR = WSP / VCHAR / NON-ASCII 299 ; any textual character 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 are 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 support encod- 332 ing multiple values in a single content line by separating the values 333 with a comma ",". This approach has been taken for several of the con- 334 tent types defined below (date, time, integer, float), for space-saving 335 reasons. 337 5.8.3. Pre-defined Parameters 339 The following parameters and value types are defined for general use. 341 predefined-param = encodingparm 342 / valuetypeparm 343 / languageparm 345 Expires in six months INTERNET DRAFT 347 / contextparm 349 encodingparm = "encoding" "=" encodingtype 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 is present. 380 The value of the "language" type parameter is a language tag as defined 381 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 "source" 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 Expires in six months INTERNET DRAFT 397 in a more readable form. The encoded base 64 value can be split across 398 multiple physical lines in the content type by using the line folding 399 technique described above. 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 is 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 can 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 can 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 = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR) 442 TEXT-LIST-CHAR = "\\" / "\," / "\n" 443 / 444 ; Backslashes, newlines, and commas must be encoded. 446 Expires in six months INTERNET DRAFT 448 ; \n or \N can be used to encode a newline. 450 date-list = date *("," date) 452 time-list = time *("," time) 454 date-time-list = date "T" time *("," date "T" time) 456 boolean = "TRUE" / "FALSE" 458 integer-list = integer *("," integer) 460 integer = [sign] 1*DIGIT 462 float-list = float *("," float) 464 float = [sign] 1*DIGIT ["." 1*DIGIT] 466 sign = "+" / "-" 468 date = date-fullyear ["-"] date-month ["-"] date-mday 470 date-fullyear = 4 DIGIT 472 date-month = 2 DIGIT ;01-12 474 date-mday = 2 DIGIT ;01-28, 01-29, 01-30, 01-31 475 ;based on month/year 477 time = time-hour [":"] time-minute [":"] time-second [time-secfrac] 478 [time-zone] 480 time-hour = 2 DIGIT ;00-23 482 time-minute = 2 DIGIT ;00-59 484 time-second = 2 DIGIT ;00-60 (leap second) 486 time-secfrac = "," 1*DIGIT 488 time-zone = "Z" / time-numzone 490 time-numzome = sign time-hour [":"] time-minute 492 iana-valuespec = 496 Expires in six months INTERNET DRAFT 498 Some specific notes on the value types and formats: 500 "text": The "text" value type should be used to identify values that 501 contain human-readable text. The character set and language in which the 502 text is represented is controlled by the charset content-header and the 503 language type parameter and content-header. 505 Examples for "text": 506 this is a text value 507 this is one value,this is another 508 this is a single value\, with a comma encoded 510 A formatted text line break in a text value type MUST be represented as 511 the character sequence backslash (ASCII decimal 92) followed by a Latin 512 small letter n (ASCII decimal 110) or a Latin capital letter N (ASCII 513 decimal 78), that is "\n" or "\N". 515 For example a multiple line DESCRIPTION value of: 517 Mythical Manager 518 Hyjinx Software Division 519 BabsCo, Inc. 521 could be represented as: 523 DESCRIPTION:Mythical Manager\nHyjinx Software Division\n 524 BabsCo\, Inc.\n 526 demonstrating the \n literal formatted line break technique, the CRLF- 527 followed-by-space line folding technique, and the backslash escape tech- 528 nique. 530 "uri": The "uri" value type should be used to identify values that are 531 referenced by a URI (including a Content-ID URI), instead of encoded 532 in-line. These value references might be used if the value is too 533 large, or otherwise undesirable to include directly. The format for the 534 URI is as defined in RFC 1738. 536 Examples for "uri": 537 http://www.foobar.com/my/picture.jpg 538 ldap://ldap.foobar.com/cn=babs%20jensen 540 "date", "time", and "date-time": Each of these value types is based on 541 a subset of the definitions in ISO 8601 standard. Profiles MAY place 542 further restrictions on "date" and "time" values. Multiple "date" and 543 "time" values can be specified using the comma-separated notation, 544 unless restricted by a profile. 546 Expires in six months INTERNET DRAFT 548 Examples for "date": 549 1985-04-12 550 1996-08-05,1996-11-11 551 19850412 553 Examples for "time": 554 10:22:00 555 102200 556 10:22:00.33 557 10:22:00.33Z 558 10:22:33,11:22:00 559 10:22:00-08:00 561 Examples for "date-time": 562 1996-10-22T14:00:00Z 563 1996-08-11T12:34:56Z 564 19960811T123456Z 565 1996-10-22T14:00:00Z,1996-08-11T12:34:56Z 567 "boolean": The "boolean" value type is used to express boolen values. 568 These values are case insensitive. 570 Examples: TRUE 571 false 572 True 574 "integer": The "integer" value type is used to express signed integers 575 in decimal format. If sign is not specified, the value is assumed posi- 576 tive "+". Multiple "integer" values can be specified using the comma- 577 separated notation, unless restricted by a profile. 579 Examples: 1234567890 580 -1234556790 581 +1234556790,432109876 583 "float": The "float" value type is used to express real numbers. If 584 sign is not specified, the value is assumed positive "+". Multiple 585 "float" values can be specified using the comma-separated notation, 586 unless restricted by a profile. 588 Examples: 20.30 589 1000000.0000001 590 1.333,3.14 592 5.9. Applications which use this media type 594 Applications which use this media type: Various 595 Expires in six months INTERNET DRAFT 597 5.10. Additional information 599 Additional information: None 601 5.11. Person & email address to contact for further information 603 Tim Howes 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 645 Expires in six months INTERNET DRAFT 647 registration template defined in Section 11.1 of this document. These 648 types MAY be included in any profile, unless explicitly forbidden in the 649 profile definition. 651 6.1. SOURCE Type Definition 653 To: ietf-mime-direct@imc.org 654 Subject: Registration of text/directory MIME type SOURCE 656 Type name: SOURCE 658 Type purpose: To identify the source of directory information con- 659 tained in the content type. 661 Type encoding: 8bit 663 Type valuetype: uri 665 Type special notes: The SOURCE type is used to provide the means by 666 which applications knowledgable in the given directory service proto- 667 col can obtain additional or more up-to-date information from the 668 directory service. It contains a URI as defined in [RFC-1738] and/or 669 other information referencing the directory entity or entities to 670 which the information pertains. When directory information is avail- 671 able from more than one source, the sending entity can pick what it 672 considers to be the best source, or multiple SOURCE types can be 673 included. The interpretation of the value for a SOURCE type can 674 depend on the setting of the CONTEXT type parameter. The value of the 675 CONTEXT type parameter MUST be compatible with the value of the uri 676 prefix. 678 Type example: 679 SOURCE;CONTEXT=LDAP:ldap://ldap.host/cn=Babs%20Jensen, 680 %20o=Babsco,%20c=US 682 6.2. NAME Type Definition 684 To: ietf-mime-direct@imc.org 685 Subject: Registration of text/directory MIME type NAME 687 Type name: NAME 689 Type purpose: To identify the displayable name of the directory 690 entity to which information in the content type pertains. 692 Type encoding: 8bit 694 Type valuetype: text 696 Expires in six months INTERNET DRAFT 698 Type special notes: The NAME type is used to convey the display name 699 of the entity to which the directory information pertains. 701 Type example: 702 NAME:Babs Jensen's Contact Information 704 6.3. PROFILE Type Definition 706 To: ietf-mime-direct@imc.org 707 Subject: Registration of text/directory MIME type PROFILE 709 Type name: PROFILE 711 Type purpose: To identify the type of directory entity to which 712 information in the content type pertains. 714 Type encoding: 8bit 716 Type valuetype: A profile name, registered as described in Section 9 717 of this document or bilaterally agreed upon as described in Section 718 5. 720 Type special notes: The PROFILE type is used to convey the type of 721 the entity to which the directory information in the rest of the body 722 part pertains. It should be the same as the "profile" header parame- 723 ter, if present. 725 Type example: 726 PROFILE:vCard 728 6.4. BEGIN Type Definition 730 To: ietf-mime-direct@imc.org 731 Subject: Registration of text/directory MIME type BEGIN 733 Type name: BEGIN 735 Type purpose: To denote the beginning of a syntactic entity within a 736 text/directory content-type. 738 Type encoding: 8bit 740 Type valuetype: text, containing a profile name, registered as 741 described in Section 9 of this document or bilaterally-agreed upon as 742 described in Section 5. 744 Type special notes: The BEGIN type is used in conjunction with the 745 END type to delimit a profile containing a related set of properties 747 Expires in six months INTERNET DRAFT 749 within an text/directory content-type. This construct can be used 750 instead of or in addition to wrapping separate sets of information 751 inside additional MIME headers. It is provided for applications that 752 wish to define content that can contain multiple entities within the 753 same text/directory content-type or to define content that can be 754 identifiable outside of a MIME environment. 756 Type example: 757 BEGIN:VCARD 759 6.5. END Type Definition 761 To: ietf-mime-direct@imc.org 762 Subject: Registration of text/directory MIME type END 764 Type name: END 766 Type purpose: To denote the end of a syntactic entity within a 767 text/directory content-type. 769 Type encoding: 8bit 771 Type valuetype: text, containing a profile name, registered as 772 described in Section 9 of this document or bilaterally-agreed upon as 773 described in Section 5. 775 Type special notes: The END type is used in conjunction with the 776 BEGIN type to delimit a profile containing a related set of proper- 777 ties within an text/directory content-type. This construct can be 778 used instead of or in addition to wrapping separate sets of informa- 779 tion inside additional MIME headers. It is provided for applications 780 that wish to define content that can contain multiple entities within 781 the same text/directory content-type or to define content that can be 782 identifiable outside of a MIME environment. 784 Type example: 785 END: VCARD 787 7. Use of the multipart/related Content-Type 789 The multipart/related Content-Type can be used to hold directory infor- 790 mation comprised of both text and non-text information or directory 791 information that already has a natural MIME representation. The root 792 body part within the multipart/related body part is specified as defined 793 in [RFC-2112] by a "start" parameter, or it is the first body part in 794 the absence of such a parameter. The root body part must have a 795 Content-Type of "text/directory". This part holds inline information 796 and makes reference to subsequent body parts holding additional text or 797 Expires in six months INTERNET DRAFT 799 non-text directory information via their Content-ID URIs as explained in 800 Section 5. 802 The body parts referred to do not have to be in any particular order, 803 except as noted above for the root body part. 805 8. Examples 807 The following examples are for illustrative purposes only and are not 808 part of the definition. 810 8.1. Example 1 812 The first example illustrates simple use of the text/directory Content- 813 Type. Note that no "profile" parameter is given, so an application may 814 not know what kind of directory entity the information applies to. Note 815 also the use of both hypothetical official and bilaterally agreed upon 816 types. 818 From: Whomever@wherever.com 819 To: Someone@somewhere.com 820 Subject: whatever 821 MIME-Version: 1.0 822 Message-ID: 823 Content-Type: text/directory 824 Content-ID: 826 cn:Babs Jensen 827 cn:Barbara J Jensen 828 sn:Jensen 829 email:babs@umich.edu 830 phone:+1 313 747-4454 831 x-id:1234567890 833 8.2. Example 2 835 The next example illustrates the use of the Quoted-Printable transfer 836 encoding defined in [RFC 2045] to include non-ASCII character in some of 837 the information returned, and the use of the optional "name" and 838 "source" types. It also illustrates the use of an "encoding" type param- 839 eter to encode a certificate value in "b". A "vCard" profile [MIME- 840 VCARD] is used for the example. 842 Content-Type: text/directory; 843 charset="iso-8859-1"; 844 profile="vCard" 845 Content-ID: 846 Content-Transfer-Encoding: Quoted-Printable 848 Expires in six months INTERNET DRAFT 850 begin:VCARD 851 source:ldap://cn=3Dbjorn%20Jensen, o=3Duniversity%20of%20Michigan, c=3DUS 852 name:Bjorn Jensen 853 fn:Bj=F8rn Jensen 854 n:Jensen;Bj=F8rn 855 email;type=3Dinternet:bjorn@umich.edu 856 tel;type=3Dwork,voice,msg:+1 313 747-4454 857 key;type=3Dx509;encoding=3DB:dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK 858 end:VCARD 860 8.3. Example 3 862 The next example illustrates the use of multi-valued type parameters, 863 the "language" type parameter, the "value" type parameter, folding of 864 long lines, the \n encoding for formatted lines, attribute grouping, and 865 the inline "b" encoding. A "vCard" profile [MIME-VCARD] is used for the 866 example. 868 Content-Type: text/directory; profile="vcard"; charset=iso-8859-1 869 Content-ID: 870 Content-Transfer-Encoding: Quoted-Printable 872 begin:vcard 873 source:ldap://cn=3DMeister%20Berger,o=3DUniversitaet%20Goerlitz,c=3DDE 874 name:Meister Berger 875 fn:Meister Berger 876 n:Berger;Meister 877 bday;value=3Ddate:1963-09-21 878 o:Universit=E6t G=F6rlitz 879 title:Mayor 880 title;language=3Dde;value=3Dtext:Burgermeister 881 note:The Mayor of the great city of 882 Goerlitz in the great country of Germany. 883 email;internet:mb@goerlitz.de 884 home.tel;type=3Dfax,voice,msg:+49 3581 123456 885 home.label:Hufenshlagel 1234\n 886 02828 Goerlitz\n 887 Deutschland 888 key;type=3DX509;encoding=3Db:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQ 889 AwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zI 890 ENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQD 891 ExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNjE5NDc1OVoXDTk3MTIwMzE5NDc 892 1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYDVQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW 893 9ucyBDb3JwLjEYMBYGA1UEAxMPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBF 894 hJob3dlc0BuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqG 895 SIb3DQEBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2dXc 896 oX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MBEGCWCGSAGG+E 897 IBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9 899 Expires in six months INTERNET DRAFT 901 w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIPmx93HGp0Kgyx1jIVMyNgsemeAwBM+M 902 SlhMfcpbTrONwNjZYW8vJDSoi//yrZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8V 903 UMk1U7jt8LYpo4YULU7UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ=3D=3D 904 end:vcard 906 8.4. Example 4 908 The final example illustrates the use of the multipart/related Content- 909 Type to include non-textual directory data via the "uri" encoding to 910 refer to other body parts within the same message, or to external 911 values. Note that no "profile" parameter is given, so an application 912 may not know what kind of directory entity the information applies to. 913 Note also the use of both hypothetical official and bilaterally agreed 914 upon types. 916 Content-Type: multipart/related; 917 boundary=woof; 918 type="text/directory"; 919 start="" 920 Content-ID: 922 --woof 923 Content-Type: text/directory; charset="iso-8859-1" 924 Content-ID: 925 Content-Transfer-Encoding: Quoted-Printable 927 source:ldap://cn=3DBjorn%20Jensen,o=3DUniversity%20of%20Michigan,c=3DUS 928 cn:Bj=F8rn Jensen 929 sn:Jensen 930 email:bjorn@umich.edu 931 image;value=3Duri:cid:id6@host.com 932 image;value=3Duri;format=3Djpeg:ftp://some.host/some/path.jpg 933 sound;value=3Duri:cid:id7@host.com 934 phone:+1 313 747-4454 936 --woof 937 Content-Type: image/jpeg 938 Content-ID: 940 <...image data...> 942 --woof 943 Content-Type: message/external-body; 944 name="myvoice.au"; 945 site="myhost.com"; 946 access-type=ANON-FTP; 947 directory="pub/myname"; 948 mode="image" 950 Expires in six months INTERNET DRAFT 952 Content-Type: audio/basic 953 Content-ID: 955 --woof-- 957 9. Registration of new profiles 959 This section defines procedures by which new profiles are registered 960 with the IANA and made available to the Internet community. Note that 961 non-IANA profiles can be used by bilateral agreement, provided the asso- 962 ciated profile names follow the "X-" convention defined above. 964 The procedures defined here are designed to allow public comment and 965 review of new profiles, while posing only a small impediment to the 966 definition of new profiles. 968 Registration of a new profile is accomplished by the following steps. 970 9.1. Define the profile 972 A profile is defined by completing the following template. 974 To: ietf-mime-direct@imc.org 975 Subject: Registration of text/directory MIME profile XXX 977 Profile name: 979 Profile purpose: 981 Profile types: 983 Profile special notes (optional): 985 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 987 The explanation of what goes in each field in the template follows. 989 Profile name: The name of the profile as it will appear in the 990 text/directory MIME Content-Type "profile" header parameter, or the 991 predefined "profile" type name. 993 Profile purpose: The purpose of the profile (e.g., to represent informa- 994 tion about people, printers, documents, etc.). Give a short but clear 995 description. 997 Profile types: The list of types associated with the profile. This list 998 of types is to be expected but not required in the profile, unless oth- 999 erwise noted in the profile definition. Other types not mentioned in 1000 Expires in six months INTERNET DRAFT 1002 the profile definition MAY also be present. Note that any new types 1003 referenced by the profile MUST be defined separately as described in 1004 Section 10. 1006 Profile special notes: Any special notes about the profile, how it is to 1007 be used, etc. This section of the template can also be used to define an 1008 ordering on the types that appear in the Content-Type, if such an order- 1009 ing is required. 1011 9.2. Post the profile definition 1013 The profile description must be posted to the new profile discussion 1014 list, ietf-mime-direct@imc.org 1016 9.3. Allow a comment period 1018 Discussion on the new profile must be allowed to take place on the list 1019 for a minimum of two weeks. Consensus must be reached on the profile 1020 before proceeding to step 4. 1022 9.4. Submit the profile for approval 1024 Once the two-week comment period has elapsed, and the proposer is con- 1025 vinced consensus has been reached on the profile, the registration 1026 application should be submitted to the Profile Reviewer for approval. 1027 The Profile Reviewer is appointed by the Application Area Directors and 1028 can either accept or reject the profile registration. An accepted regis- 1029 tration is passed on by the Profile Reviewer to the IANA for inclusion 1030 in the official IANA profile registry. The registration may be rejected 1031 for any of the following reasons. 1) Insufficient comment period; 2) 1032 Consensus not reached; 3) Technical deficiencies raised on the list or 1033 elsewhere have not been addressed. The Profile Reviewer's decision to 1034 reject a profile can be appealed by the proposer to the IESG, or the 1035 objections raised can be addressed by the proposer and the profile 1036 resubmitted. 1038 10. Profile Change Control 1040 Existing profiles can be changed using the same process by which they 1041 were registered. 1043 Define the change 1045 Post the change 1047 Allow a comment period 1049 Submit the changed profile for approval 1051 Expires in six months INTERNET DRAFT 1053 Note that the original author or any other interested party can propose 1054 a change to an existing profile, but that such changes should only be 1055 proposed when there are serious omissions or errors in the published 1056 specification. The Profile Reviewer can object to a change if it is not 1057 backwards compatible, but is not required to do so. 1059 Profile definitions can never be deleted from the IANA registry, but 1060 profiles which are no longer believed to be useful can be declared 1061 OBSOLETE by a change to their "intended use" field. 1063 11. Registration of new types 1065 This section defines procedures by which new types are registered with 1066 the IANA. Note that non-IANA types can be used by bilateral agreement, 1067 provided the associated types names follow the "X-" convention defined 1068 above. 1070 The procedures defined here are designed to allow public comment and 1071 review of new types, while posing only a small impediment to the defini- 1072 tion of new types. 1074 Registration of a new type is accomplished by the following steps. 1076 11.1. Define the type 1078 A type is defined by completing the following template. 1080 To: ietf-mime-direct@imc.org 1081 Subject: Registration of text/directory MIME type XXX 1083 Type name: 1085 Type purpose: 1087 Type encoding: 1089 Type valuetype: 1091 Type special notes (optional): 1093 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1095 The meaning of each field in the template is as follows. 1097 Type name: The name of the type, as it will appear in the body of an 1098 text/directory MIME Content-Type "type: value" line to the left of the 1099 colon ":". 1101 Expires in six months INTERNET DRAFT 1103 Type purpose: The purpose of the type (e.g., to represent a name, postal 1104 address, IP address, etc.). Give a short but clear description. 1106 Type encoding: The default encoding a value of the type must have in the 1107 body of a text/directory MIME Content-Type. 1109 Type valuetype: The format a value of the type must have in the body of 1110 a text/directory MIME Content-Type. This description must be precise and 1111 must not violate the general encoding rules defined in section 5 of this 1112 document. 1114 Type special notes: Any special notes about the type, how it is to be 1115 used, etc. 1117 11.2. Post the type definition 1119 The type description must be posted to the new type discussion list, 1120 ietf-mime-direct@imc.org 1122 11.3. Allow a comment period 1124 Discussion on the new type must be allowed to take place on the list for 1125 a minimum of two weeks. Consensus must be reached on the type before 1126 proceeding to step 4. 1128 11.4. Submit the type for approval 1130 Once the two-week comment period has elapsed, and the proposer is con- 1131 vinced consensus has been reached on the type, the registration applica- 1132 tion should be submitted to the Profile Reviewer for approval. The Pro- 1133 file Reviewer is appointed by the Application Area Directors and can 1134 either accept or reject the type registration. An accepted registration 1135 is passed on by the Profile Reviewer to the IANA for inclusion in the 1136 official IANA profile registry. The registration can be rejected for any 1137 of the following reasons. 1) Insufficient comment period; 2) Consensus 1138 not reached; 3) Technical deficiencies raised on the list or elsewhere 1139 have not been addressed. The Profile Reviewer's decision to reject a 1140 type can be appealed by the proposer to the IESG, or the objections 1141 raised can be addressed by the proposer and the type resubmitted. 1143 12. Type Change Control 1145 Existing types can be changed using the same process by which they were 1146 registered. 1148 Define the change 1150 Post the change 1152 Expires in six months INTERNET DRAFT 1154 Allow a comment period 1156 Submit the type for approval 1158 Note that the original author or any other interested party can propose 1159 a change to an existing type, but that such changes should only be pro- 1160 posed when there are serious omissions or errors in the published 1161 specification. The Profile Reviewer can object to a change if it is not 1162 backwards compatible, but is not required to do so. 1164 Type definitions can never be deleted from the IANA registry, but types 1165 which are nolonger believed to be useful can be declared OBSOLETE by a 1166 change to their "intended use" field. 1168 13. Registration of new parameters 1170 This section defines procedures by which new parameters are registered 1171 with the IANA and made available to the Internet community. Note that 1172 non-IANA parameters can be used by bilateral agreement, provided the 1173 associated parameters names follow the "X-" convention defined above. 1175 The procedures defined here are designed to allow public comment and 1176 review of new parameters, while posing only a small impediment to the 1177 definition of new parameters. 1179 Registration of a new parameter is accomplished by the following steps. 1181 13.1. Define the parameter 1183 A parameter is defined by completing the following template. 1185 To: ietf-mime-direct@imc.org 1186 Subject: Registration of text/directory MIME type parameter XXX 1188 Parameter name: 1190 Parameter purpose: 1192 Parameter values: 1194 Parameter special notes (optional): 1196 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1198 The explanation of what goes in each field in the template follows. 1200 Parameter name: The name of the parameter as it will appear in the 1201 text/directory MIME Content-Type. 1203 Expires in six months INTERNET DRAFT 1205 Parameter purpose: The purpose of the parameter (e.g., to represent the 1206 format of an image, type of a phone number, etc.). Give a short but 1207 clear description. If defining a general paramemter like "format" or 1208 "type" keep in mind that other applications might wish to extend its 1209 use. 1211 Parameter values: The list or description of values associated with the 1212 parameter. 1214 Parameter special notes: Any special notes about the parameter, how it 1215 is to be used, etc. 1217 13.2. Post the parameter definition 1219 The parameter description must be posted to the new parameter discussion 1220 list, ietf-mime-direct@imc.org 1222 13.3. Allow a comment period 1224 Discussion on the new parameter must be allowed to take place on the 1225 list for a minimum of two weeks. Consensus must be reached on the param- 1226 eter before proceeding to step 4. 1228 13.4. Submit the parameter for approval 1230 Once the two-week comment period has elapsed, and the proposer is con- 1231 vinced consensus has been reached on the parameter, the registration 1232 application should be submitted to the Profile Reviewer for approval. 1233 The Profile Reviewer is appointed by the Application Area Directors and 1234 can either accept or reject the parameter registration. An accepted 1235 registration is passed on by the Profile Reviewer to the IANA for inclu- 1236 sion in the official IANA parameter registry. The registration can be 1237 rejected for any of the following reasons. 1) Insufficient comment 1238 period; 2) Consensus not reached; 3) Technical deficiencies raised on 1239 the list or elsewhere have not been addressed. The Profile Reviewer's 1240 decision to reject a profile can be appealed by the proposer to the 1241 IESG, or the objections raised can be addressed by the proposer and the 1242 parameter registration resubmitted. 1244 14. Parameter Change Control 1246 Existing parameters can be changed using the same process by which they 1247 were registered. 1249 Define the change 1251 Post the change 1253 Expires in six months INTERNET DRAFT 1255 Allow a comment period 1257 Submit the parameter for approval 1259 Note that the original author or any other interested party can propose 1260 a change to an existing parameter, but that such changes should only be 1261 proposed when there are serious omissions or errors in the published 1262 specification. The Profile Reviewer can object to a change if it is not 1263 backwards compatible, but is not required to do so. 1265 Parameter definitions can never be deleted from the IANA registry, but 1266 parameters which are nolonger believed to be useful can be declared 1267 OBSOLETE by a change to their "intended use" field. 1269 15. Registration of new value types 1271 This section defines procedures by which new value types are registered 1272 with the IANA and made available to the Internet community. Note that 1273 non-IANA value types can be used by bilateral agreement, provided the 1274 associated value types names follow the "X-" convention defined above. 1276 The procedures defined here are designed to allow public comment and 1277 review of new value types, while posing only a small impediment to the 1278 definition of new value types. 1280 Registration of a new value types is accomplished by the following 1281 steps. 1283 15.1. Define the value type 1285 A value type is defined by completing the following template. 1287 To: ietf-mime-direct@imc.org 1288 Subject: Registration of text/directory MIME value type XXX 1290 value type name: 1292 value type purpose: 1294 value type format: 1296 value type special notes (optional): 1298 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1300 The explanation of what goes in each field in the template follows. 1302 Expires in six months INTERNET DRAFT 1304 value type name: The name of the value type as it will appear in the 1305 text/directory MIME Content-Type. 1307 value type purpose: The purpose of the value type. Give a short but 1308 clear description. 1310 value type format: The definition of the format for the value, usually 1311 using ABNF grammar. 1313 value type special notes: Any special notes about the value type, how 1314 it is to be used, etc. 1316 15.2. Post the value type definition 1318 The value type description must be posted to the new value type discus- 1319 sion list, ietf-mime-direct@imc.org 1321 15.3. Allow a comment period 1323 Discussion on the new value type must be allowed to take place on the 1324 list for a minimum of two weeks. Consensus must be reached before 1325 proceeding to step 4. 1327 15.4. Submit the value type for approval 1329 Once the two-week comment period has elapsed, and the proposer is con- 1330 vinced consensus has been reached on the value type, the registra- 1331 tion application should be submitted to the Profile Reviewer for 1332 approval. The Profile Reviewer is appointed by the Application Area 1333 Directors and can either accept or reject the value type registration. 1334 An accepted registration should be passed on by the Profile Reviewer to 1335 the IANA for inclusion in the official IANA value type registry. The 1336 registration can be rejected for any of the following reasons. 1) 1337 Insufficient comment period; 2) Consensus not reached; 3) Technical 1338 deficiencies raised on the list or elsewhere have not been 1339 addressed. The Profile Reviewer's decision to reject a profile can be 1340 appealed by the proposer to the IESG, or the objections raised can 1341 be addressed by the proposer and the value type registration resubmit- 1342 ted. 1344 16. Security Considerations 1346 Internet mail is subject to many well known security attacks, including 1347 monitoring, replay, and forgery. Care should be taken by any directory 1348 service in allowing information to leave the scope of the service 1349 Expires in six months INTERNET DRAFT 1351 itself, where any access controls can no longer be guaranteed. Applica- 1352 tions should also take care to display directory data in a "safe" 1353 environment (e.g., PostScript-valued types). 1355 17. Acknowledgements 1357 The registration procedures defined here were shamelessly lifted from 1358 the MIME registration RFC. 1360 The many valuable comments contributed by members of the IETF ASID work- 1361 ing group are gratefully acknowledged, as are the contributions of the 1362 Versit Consortium. Chris Newman was especially helpful in navigating the 1363 intricacies of ABNF lore. 1365 18. References 1367 [RFC-1777] Yeong, W., Howes, T., Kille, S., "Lightweight Directory 1368 Access Protocol", Request for Comment (RFC) 1777, March 1995. 1370 [RFC-1778] Howes, T., Kille, S., Yeong, W., Robbins, C.J., "The String 1371 Representation of Standard Attribute Syntaxes", Request for 1372 Comment (RFC) 1778, March 1995. 1374 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 1375 Messages", STD 11, RFC 822, August 1982. 1377 [RFC-2045] Borenstein, N., Freed, N., "Multipurpose Internet Mail Exten- 1378 sions (MIME) Part One: Format of Internet Message Bodies", 1379 RFC 2045, November 1996. 1381 [RFC-2046] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part 1382 Two: Media Types", RFC 2046, November 1996. 1384 [RFC-2048] Freed, N., Klensin, J., Postel, J., "Multipurpose Internet 1385 Mail Extensions (MIME) Part Four: Registration Procedures", 1386 RFC 2048, November 1996 1388 [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", 1389 RFC 1766, March 1995. 1391 [RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type," RFC 1392 2112, March 1997. 1394 [X500] "Information Processing Systems - Open Systems Interconnec- 1395 tion - The Directory: Overview of Concepts, Models and Ser- 1396 vices", ISO/IEC JTC 1/SC21, International Standard 9594-1, 1397 1988. 1399 Expires in six months INTERNET DRAFT 1401 [RFC-1835] Deutsch, P., Schoultz, R., Faltstrom, P., Weider, C., "Archi- 1402 tecture of the WHOIS++ service", August 1995. 1404 [RFC-1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform 1405 Resource Locators (URL)", RFC 1738, December 1994. 1407 [MIME-VCARD]F. Dawson, T. Howes, "VCard MIME Directory Profile", RFC 1408 XXXX, March 1998. 1410 [VCARD] Internet Mail Consortium, "vCard - The Electronic Business 1411 Card", Version 2.1, http://www.imc.com/pdi/vcard-21.txt, Sep- 1412 tember, 1996. 1414 [RFC-2119] "Key words for use in RFCs to Indicate Requirement Levels", 1415 RFC 2119, March 1997. 1417 [RFC-2234] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifi- 1418 cations: ABNF", RFC 2234, November 1997. 1420 19. Authors' Addresses 1422 Tim Howes 1423 Netscape Communications Corp. 1424 501 East Middlefield Rd. 1425 Mountain View, CA 94041 1426 USA 1427 howes@netscape.com 1428 +1.415.937.3419 1430 Mark Smith 1431 Netscape Communications Corp. 1432 501 East Middlefield Rd. 1433 Mountain View, CA 94041 1434 USA 1435 mcs@netscape.com 1436 +1.415.937.3477 1438 Frank Dawson 1439 Lotus Development Corporation 1440 6544 Battleford Drive 1441 Raleigh, NC 27613 1442 USA 1443 frank_dawson@lotus.com 1444 +1-919-676-9515 1446 Expires in six months INTERNET DRAFT 1448 20. Table of Contents 1450 1. Status of this Memo..............................................1 1451 2. Abstract.........................................................1 1452 3. Need for a MIME Directory Type...................................2 1453 4. Overview.........................................................2 1454 5. The text/directory Content-Type..................................3 1455 5.1. MIME media type name...........................................3 1456 5.2. MIME subtype name..............................................3 1457 5.3. Required parameters............................................3 1458 5.4. Optional parameters............................................3 1459 5.5. Encoding considerations........................................4 1460 5.6. Security considerations........................................4 1461 5.7. Interoperability considerations................................4 1462 5.8. Published specification........................................5 1463 5.8.1. Line delimiting and folding..................................5 1464 5.8.2. ABNF content-type definition.................................6 1465 5.8.3. Pre-defined Parameters.......................................7 1466 5.8.4. Pre-defined Value Types......................................9 1467 5.9. Applications which use this media type.........................12 1468 5.10. Additional information........................................13 1469 5.11. Person & email address to contact for further information.....13 1470 5.12. Intended usage................................................13 1471 5.13. Author/Change controller......................................13 1472 6. Predefined Types.................................................13 1473 6.1. SOURCE Type Definition.........................................14 1474 6.2. NAME Type Definition...........................................14 1475 6.3. PROFILE Type Definition........................................15 1476 6.4. BEGIN Type Definition..........................................15 1477 6.5. END Type Definition............................................16 1478 7. Use of the multipart/related Content-Type........................16 1479 8. Examples.........................................................17 1480 8.1. Example 1......................................................17 1481 8.2. Example 2......................................................17 1482 8.3. Example 3......................................................18 1483 8.4. Example 4......................................................19 1484 9. Registration of new profiles.....................................20 1485 9.1. Define the profile.............................................20 1486 9.2. Post the profile definition....................................21 1487 9.3. Allow a comment period.........................................21 1488 9.4. Submit the profile for approval................................21 1489 10. Profile Change Control..........................................21 1490 11. Registration of new types.......................................22 1491 11.1. Define the type...............................................22 1492 11.2. Post the type definition......................................23 1493 11.3. Allow a comment period........................................23 1494 11.4. Submit the type for approval..................................23 1495 12. Type Change Control.............................................23 1496 Expires in six months INTERNET DRAFT 1498 13. Registration of new parameters..................................24 1499 13.1. Define the parameter..........................................24 1500 13.2. Post the parameter definition.................................25 1501 13.3. Allow a comment period........................................25 1502 13.4. Submit the parameter for approval.............................25 1503 14. Parameter Change Control........................................25 1504 15. Registration of new value types.................................26 1505 15.1. Define the value type.........................................26 1506 15.2. Post the value type definition................................27 1507 15.3. Allow a comment period........................................27 1508 15.4. Submit the value type for approval............................27 1509 16. Security Considerations.........................................27 1510 17. Acknowledgements................................................28 1511 18. References......................................................28 1512 19. Authors' Addresses..............................................29 1513 20. Table of Contents...............................................30