idnits 2.17.1 draft-ietf-asid-mime-direct-05.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-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing 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 28 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 295 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 18 instances of too long lines in the document, the longest one being 8 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 ...' == (290 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 (November 15, 1997) is 9652 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 834, but not defined == Missing Reference: 'RFC-1522' is mentioned on line 282, but not defined ** Obsolete undefined reference: RFC 1522 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) == Missing Reference: 'RFC 2045' is mentioned on line 831, but not defined == Unused Reference: 'DATETIME' is defined on line 1391, but no explicit reference was found in the text == Unused Reference: 'VCARD' is defined on line 1398, 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: Normative reference to a draft: ref. 'DATETIME' -- Possible downref: Non-RFC (?) normative reference: ref. 'VCARD' Summary: 23 errors (**), 0 flaws (~~), 15 warnings (==), 5 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-05.txt Netscape Communications Corp. 5 Frank Dawson 6 Lotus Development Corporation 7 November 15, 1997 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 1997. 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 "Person" is the same 160 as "PERSON" and "person" and "peRsOn"). 162 profile = x-token / iana-token 164 x-token = 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. Note that each value may also have an 176 inline encoding associated with it. This encoding is independent of the 177 encoding for the body part as a whole. When encoding, the backslash 178 encoding described below for text values containing special characters 179 is applied first, inline per-value encodings are performed second, then 180 Content-Transfer-Encoding is applied to the entire body part. When 181 decoding, the Content-Transfer-Encoding for the entire body part is 182 decoded, then any value-specific encodings are decoded, and finally any 183 backslash encodings are decoded. 185 The backslash encoding is used to encode special characters occurring in 186 a text value that otherwise would have special significance in the con- 187 tent type. The following table summarizes the special characters and 188 their backslash encodings. 190 special backslash 191 character encoding 192 --------- --------- 193 newline (ASCII decimal 10) \n or \N 194 comma (ASCII decimal 44) \, 195 backslash (ASCII decimal 92) \\ 197 Expires in six months INTERNET DRAFT 199 5.6. Security considerations 201 Directory information may be public or it may be protected from unau- 202 thorized access by the directory service in which it resides. Once the 203 information leaves its native service, there can be no guarantee that 204 the same care will be taken by all services handling the information. 205 Furthermore, this specification defines no access control mechanism by 206 which information may be protected, or by which access control informa- 207 tion may be conveyed. Note that the integrity and privacy of a 208 text/directory body part may be protected by enclosing it within an 209 appropriate MIME-based security mechanism. 211 5.7. Interoperability considerations 213 In order to make sense of directory information, applications must share 214 a common understanding of the types of information contained within the 215 Content-Type (the directory schema). This schema information is not 216 defined in this document, but rather in companion documents (e.g., 217 [MIME-VCARD]) that follow the requirements specified in this document, 218 or in bilateral agreements between communicating parties. 220 5.8. Published specification 222 The text/directory Content-Type contains directory information, typi- 223 cally pertaining to a single directory entity or group of entities. The 224 content consists of one or more lines in the format given below. 226 5.8.1. Line delimiting and folding 228 Individual lines within the MIME text/directory Content Type body are 229 delimited by the [RFC-822] line break, which is a CRLF sequence (ASCII 230 decimal 13, followed by ASCII decimal 10). Long logical lines of text 231 can be split into a multiple-physical-line representation using the fol- 232 lowing folding technique. 234 A logical line MAY be continued on the next physical line at any point 235 by inserting a CRLF immediately followed by a single white space charac- 236 ter (space, ASCII decimal 32, or horizontal tab, ASCII decimal 9). Any 237 sequence of CRLF followed immediately by a single white space character 238 is ignored (removed) when processing the content type. For example the 239 line: 241 DESCRIPTION:This is a long description that exists on a long line. 243 Can be represented as: 245 DESCRIPTION:This is a long description 246 that exists on a long line. 248 Expires in six months INTERNET DRAFT 250 It could also be represented as: 252 DESCRIPTION:This is a long descrip 253 tion that exists on a long line. 255 The process of moving from this folded multiple-line representation of a 256 type definition to its single line representation is called unfolding. 257 Unfolding is accomplished by regarding CRLF immediately followed by a 258 white space character (namely HTAB ASCII decimal 9 or SPACE ASCII 259 decimal 32) as equivalent to no characters at all (i.e., the CRLF and 260 single white space character are removed). 262 A formatted text line break in a value type MUST be represented as the 263 character sequence backslash (ASCII decimal 92) followed by a Latin 264 small letter n (ASCII decimal 110) or a Latin capital letter N (ASCII 265 decimal 78), that is "\n" or "\N". 267 For example a multiple line DESCRIPTION value of: 269 Mythical Manager 270 Hyjinx Software Division 271 BabsCo, Inc. 273 could be represented as: 275 DESCRIPTION: Mythical Manager\nHyjinx Software Division\n 276 BabsCo\, Inc.\n 278 demonstrating both the \n literal formatted line break technique and the 279 CRLF-followed-by-space line folding technique. 281 Data values containing the CRLF sequence may also be encoded using the 282 "B" encoding method, defined in [RFC-1522]. 284 5.8.2. BNF content-type definition 286 Using the notation of RFC 822, the syntax for this content is: 288 contentline = [group.]type [";" [ws] parameterlist] ":" [ws] valuespec 290 group = atom ; as defined in Section 3.3 of RFC 822 292 type = x-name 293 / iana-type 295 x-name = 298 Expires in six months INTERNET DRAFT 300 iana-type = 304 ws = *(HTAB / SPACE) ; ASCII decimal 9 and 32 306 parameterlist = parameter *(";" [ws] parameter) 308 parameter = encodingparm 309 / valuetypeparm 310 / languageparm 311 / contextparm 312 / [parmtype "="] parmvalues 314 encodingparm = "encoding" "=" encodingtype 316 encodingtype = "b" ; from RFC 2047 318 valuetypeparm = "value" "=" valuetype 320 valuetype = "uri" ; generic uri from RFC 1738 321 / "text" 322 / "date" 323 / "time" 324 / "date-time" ; date time 325 / "integer" 326 / "boolean" 327 / "float" 328 / x-name 329 / iana-valuetype 331 iana-valuetype : = 335 languageparm = "language" "=" language ; as defined in RFC 1766 337 contextparm = "context" "=" context 339 context = iana-token ; a token registered with IANA 340 / x-name 342 parmtype = x-name 343 / iana-parmtype 345 iana-parmtype = 349 Expires in six months INTERNET DRAFT 351 parmvalues = parmvalue *("," parmvalue) 353 parmvalue = x-name 354 / iana-parmvalue 356 iana-parmvalue = 361 valuespec = text-spec 362 / date-spec 363 / time-spec 364 / date-time-spec 365 / boolean 366 / integer 367 / float 368 / iana-valuespec 370 text-spec = text *("," [ws] text) 372 text = 377 date-spec = date *("," [ws] date) 379 time-spec = time *("," [ws] time) 381 date-time-spec = date "T" time 383 boolean = "TRUE" / "FALSE" 385 integer = [sign] 1*digit *("," [ws] [sign] 1*digit) 387 float = [sign] 1*digit ["." *digit] *("," float) 389 sign = "+" / "-" 391 digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" 393 date = date-fullyear ["-"] date-month ["-"] date-mday 395 date-fullyear = 4digit 397 date-month = 2digit ;01-12 399 Expires in six months INTERNET DRAFT 401 date-mday = 2digit ;01-28, 01-29, 01-30, 01-31 402 ;based on month/year 404 time = time-hour [":"] time-minute [":"] time-second [time-secfrac] 405 [time-zone] 407 time-hour = 2digit ;00-23 409 time-minute = 2digit ;00-59 411 time-second = 2digit ;00-59 413 time-secfrac = "," 1*digit 415 time-zone = "Z" / time-numzome 417 time-numzome = sign time-hour [":"] time-minute 419 iana-valuespec = 423 White space characters (namely HTAB and SPACE characters, ASCII decimal 424 9 and 32) may follow the SEMICOLON ';' parameter separator, the COMMA 425 ',' list value separator or the COLON ':' value separator. Note that 426 this means that if a "valuespec" begins with white space, it must be 427 encoded using either the "B" encoding method. 429 A line that begins with a white space character is a continuation of the 430 previous line, as described above. The CRLF and immediately following 431 white space character should be discarded when reconstructing the origi- 432 nal line. Note that this line-folding convention differs from that found 433 in RFC 822, in that the sequence or found 434 anywhere in the content indicates a continued line and should be 435 removed. 437 The meanings of the various type names and the format of the correspond- 438 ing values must be defined as specified in Section 11. Specifications 439 MAY impose ordering on the type constructs within a body part, though 440 none is required by default. The various x-name constructs are used for 441 bilaterally-agreed upon type names, parameter names and parameter 442 values. 444 Type names and parameter names are case insensitive (e.g., the type name 445 "cn" is the same as "CN" and "Cn"). Parameter values MAY be case sensi- 446 tive or case insensitive, depending on their definition. 448 The group construct is used to group related attributes together. The 449 Expires in six months INTERNET DRAFT 451 group name is a syntactic convention used to indicate that all type 452 names prefaced with the same group name SHOULD be grouped together when 453 displayed by an application. It has no other significance. Implementa- 454 tions that do not understand or support grouping MAY simply strip off 455 any text before a "." to the left of the type name and present the types 456 and values as normal. 458 Each attribute defined in the text/directory body MAY have multiple 459 values, if allowed in the definition of the profile in which the attri- 460 bute is used. The general rule for encoding multi-valued items is to 461 simply create a new content line for each value (including the type 462 name). However, it should be noted that some value types MAY support 463 encoding multiple values in a single content line, for example by 464 separating the values with a comma "," or other delimiter. This 465 approach has been taken for several of the content types defined above 466 (date, time, integer, float), for space-saving reasons. 468 The "language" type parameter is used to identify data in multiple 469 languages. There is no concept of "default" language, except as speci- 470 fied by any "Content-Language" MIME header parameter that MAY be 471 present. The value of the "language" type parameter is a language tag as 472 defined in Section 2 of [RFC-1766]. 474 The "context" type parameter is used to identify a context (e.g., a pro- 475 tocol) used in interpreting the value. This is used, for example, in the 476 "name" type, defined below. 478 The "encoding" type parameter is used to specify an alternate encoding 479 for a value. If the value contains a CRLF sequence (ASCII 10 followed by 480 13), it must be encoded, since CRLF is used to separate lines in the 481 content-type itself. The CRLF sequence must be encoded as the character 482 sequence backslash (ASCII decimal 92) followed by a Latin small letter n 483 (ASDII decimal 110) or a Latin capital letter N (ASCII decimal 78), that 484 is, "\n" or "\N". 486 The "B" encoding can also be useful for binary values that are mixed 487 with other text information in the body part (e.g., a certificate). 488 Using a per-value "B" encoding in this case leaves the other information 489 in a more readable form. The encoded base 64 value may be split across 490 multiple physical lines in the content type by using the line folding technique. 493 The Content-Transfer-Encoding header field is used to specify the encod- 494 ing used for the body part as a whole. The "encoding" type parameter is 495 used to specify an encoding for a particular value (e.g., a certifi- 496 cate). In this case, the Content-Transfer-Encoding header might specify 497 "8bit", while the one certificate value might specify an encoding of "B" 498 via an "encoding=B" type parameter. 500 Expires in six months INTERNET DRAFT 502 Each type has associated with it a default encoding, taken from the 503 Content-Transfer-Encoding MIME header parameter. 505 The "value" parameter is optional, and MAY be used to identify the value 506 type (data type) and format of the value. The use of these predefined 507 formats is encouraged even if the value parameter is not explicity used. 508 By defining a standard set of value types and their formats, existing 509 parsing and processing code may be leveraged. 511 Including the value type explicitly as part of each property provides an 512 extra hint to keep parsing simple and support more generalized applica- 513 tions. For example a search engine would not have to know the particu- 514 lar value types for all of the items for which it is searching. Because 515 the value type is explicit in the definition, the search engine could 516 look for dates in any item type and provide results that may still be 517 interpreted. 519 5.8.3. Predefined value formats 521 Some specific notes on the value types and formats: 523 "text": The "text" value type should be used to identify values that 524 contain human-readable text. The character set and language in which the 525 text is represented is controlled by the charset content-header and the 526 language type parameter and content-header. 528 "uri": The "uri" value type should be used to identify values that are 529 referenced by a URI (including a Content-ID URI), instead of encoded 530 in-line. These value references might be used if the value is too 531 large, or otherwise undesirable to include directly. The format for the 532 URI is as defined in RFC 1738. 534 "date", "time", and "date-time": Each of these value types is based on 535 a subset of the definitions in ISO 8601 standard. Profiles MAY place 536 further restrictions on "date" and "time" values. Multiple "date" and 537 "time" values may be specified using the comma-separated notation, 538 unless restricted by a profile. 540 Examples for "date": 541 1985-04-12 542 1996-08-05, 1996-11-11 543 19850412 545 Examples for "time": 546 10:22:00 547 102200 548 10:22:00.33 549 10:22:00.33Z 551 Expires in six months INTERNET DRAFT 553 10:22:33, 11:22:00 554 10:22:00-08:00 556 Examples for "date-time": 557 1996-10-22T14:00:00Z 558 1996-08-11T12:34:56Z 559 19960811T123456Z 560 1996-10-22T14:00:00Z, 1996-08-11T12:34:56Z 562 "boolean": The "boolean" value type is used to express boolen values. 563 These values are case insensitive. 565 Examples: TRUE 566 false 567 True 569 "integer": The "integer" value type is used to express 32-bit signed 570 integers in decimal format. The valid range for "integer" is 571 -2147483648 to 2147483647. If sign is not specified, the value is 572 assumed positive "+". Multiple "integer" values may be specified using 573 the comma-separated notation, unless restricted by a profile. 575 Examples: 1234567890 576 -1234556790 577 +1234556790, 432109876 579 "float": The "float" value type is used to express real numbers. If 580 sign is not specified, the value is assumed positive "+". Multiple 581 "float" values may be specified using the comma-separated notation, 582 unless restricted by a profile. 584 Examples: 20.30 585 1000000.0000001 586 1.333, 3.14 588 5.9. Applications which use this media type 590 Applications which use this media type: Various 592 5.10. Additional information 594 Additional information: None 596 5.11. Person & email address to contact for further information 598 Tim Howes 599 Netscape Communications Corp. 601 Expires in six months INTERNET DRAFT 603 501 East Middlefield Rd. 604 Mountain View, CA 94041 605 USA 606 howes@netscape.com 607 +1 415 937 3419 609 5.12. Intended usage 611 Intended usage: COMMON 613 5.13. Author/Change controller 615 Tim Howes 616 Netscape Communications Corp. 617 501 East Middlefield Rd. 618 Mountain View, CA 94041 619 USA 620 howes@netscape.com 621 +1 415 937 3419 623 Mark Smith 624 Netscape Communications Corp. 625 501 East Middlefield Rd. 626 Mountain View, CA 94041 627 USA 628 mcs@netscape.com 629 +1 415 937 3477 631 Frank Dawson 632 Lotus Development Corporation 633 6544 Battleford Drive 634 Raleigh, NC 27613 635 USA 636 fdawson@earthlink.net 637 +1-919-676-9515 639 6. Predefined Types 641 The following types are generally useful regardless of the profile being 642 carried and are defined below using the text/directory MIME type regis- 643 tration template defined in Section 11.1 of this document. These types 644 MAY be included in any profile, unless explicitly forbidden in the pro- 645 file definition. 647 6.1. SOURCE Type Definition 649 To: ietf-mime-direct@imc.org 650 Subject: Registration of text/directory MIME type SOURCE 652 Expires in six months INTERNET DRAFT 654 Type name: SOURCE 656 Type purpose: To identify the source of directory information con- 657 tained in the content type. 659 Type encoding: 8bit 661 Type valuetype: text containing a URI. 663 Type special notes: The SOURCE type is used to provide the means by 664 which applications knowledgable in the given directory service proto- 665 col may obtain additional or more up-to-date information from the 666 directory service. It contains a URI as defined in [RFC-1738] and/or 667 other information referencing the directory entity or entities to 668 which the information pertains. When directory information is avail- 669 able from more than one source, the sending entity may pick what it 670 considers to be the best source, or multiple SOURCE types may be 671 included. The interpretation of the value for a SOURCE type may 672 depend on the setting of the CONTEXT type parameter. 674 Type example: 675 SOURCE;CONTEXT=LDAP: ldap://ldap.host/cn=Babs%20Jensen, 676 %20o=Babsco,%20c=US 678 6.2. NAME Type Definition 680 To: ietf-mime-direct@imc.org 681 Subject: Registration of text/directory MIME type NAME 683 Type name: NAME 685 Type purpose: To identify the displayable name of the directory 686 entity to which information in the content type pertains. 688 Type encoding: 8bit 690 Type valuetype: text 692 Type special notes: The NAME type is used to convey the display name 693 of the entity to which the directory information pertains. 695 Type example: 696 NAME: Babs Jensen's Contact Information 698 6.3. PROFILE Type Definition 700 To: ietf-mime-direct@imc.org 701 Subject: Registration of text/directory MIME type PROFILE 703 Expires in six months INTERNET DRAFT 705 Type name: PROFILE 707 Type purpose: To identify the type of directory entity to which 708 information in the content type pertains. 710 Type encoding: 8bit 712 Type valuetype: text, containing a profile name, registered as 713 described in Section 9 of this document or bilaterally-agreed upon as 714 described in Section 5. 716 Type special notes: The PROFILE type is used to convey the type of 717 the entity to which the directory information in the rest of the body 718 part pertains. It should be the same as the "profile" header parame- 719 ter, if present. 721 Type example: 722 PROFILE: person 724 6.4. BEGIN Type Definition 726 To: ietf-mime-direct@imc.org 727 Subject: Registration of text/directory MIME type BEGIN 729 Type name: BEGIN 731 Type purpose: To delimit the beginning of a syntactic entity within a 732 text/directory content-type. 734 Type encoding: 8bit 736 Type valuetype: text, containing a profile name, registered as 737 described in Section 9 of this document or bilaterally-agreed upon as 738 described in Section 5. 740 Type special notes: The BEGIN type is used in conjunction with the 741 END type to delimit a profile containing a related set of properties 742 within an text/directory content-type. This construct may be used 743 instead of or in addition to wrapping separate sets of information 744 inside additional MIME headers. It is provided for applications that 745 wish to define content that may contain multiple entities within the 746 same text/directory content-type or to define content that may be 747 identifiable outside of a MIME environment. 749 Type example: 750 BEGIN: VCARD 752 Expires in six months INTERNET DRAFT 754 6.5. END Type Definition 756 To: ietf-mime-direct@imc.org 757 Subject: Registration of text/directory MIME type END 759 Type name: END 761 Type purpose: To delimit the end of a syntactic entity within a 762 text/directory content-type. 764 Type encoding: 8bit 766 Type valuetype: text, containing a profile name, registered as 767 described in Section 9 of this document or bilaterally-agreed upon as 768 described in Section 5. 770 Type special notes: The END type is used in conjunction with the 771 BEGIN type to delimit a profile containing a related set of proper- 772 ties within an text/directory content-type. This construct may be 773 used instead of or in addition to wrapping separate sets of informa- 774 tion inside additional MIME headers. It is provided for applications 775 that wish to define content that may contain multiple entities within 776 the same text/directory content-type or to define content that may be 777 identifiable outside of a MIME environment. 779 Type example: 780 END: VCARD 782 7. Use of the multipart/related Content-Type 784 The multipart/related Content-Type can be used to hold directory infor- 785 mation comprised of both text and non-text information or directory 786 information that already has a natural MIME representation. The root 787 body part within the multipart/related body part is specified as defined 788 in [RFC-2112] by a "start" parameter, or it is the first body part in 789 the absence of such a parameter. The root body part must have a 790 Content-Type of "text/directory". This part holds inline information 791 and makes reference to subsequent body parts holding additional text or 792 non-text directory information via their Content-ID URIs as explained in 793 Section 5. 795 The body parts referred to do not have to be in any particular order, 796 except as noted above for the root body part. 798 8. Examples 800 The following examples are for illustrative purposes only and are not 801 part of the definition. 803 Expires in six months INTERNET DRAFT 805 8.1. Example 1 807 The first example illustrates simple use of the text/directory Content- 808 Type. Note that no "profile" parameter is given, so an application may 809 not know what kind of directory entity the information applies to. Note 810 also the use of both hypothetical official and bilaterally agreed upon 811 types. 813 From: Whomever@wherever.com 814 To: Someone@somewhere.com 815 Subject: whatever 816 MIME-Version: 1.0 817 Message-ID: 818 Content-Type: text/directory 819 Content-ID: 821 cn: Babs Jensen 822 cn: Barbara J Jensen 823 sn: Jensen 824 email: babs@umich.edu 825 phone: +1 313 747-4454 826 x-id: 1234567890 828 8.2. Example 2 830 The next example illustrates the use of the Quoted-Printable transfer 831 encoding defined in [RFC 2045] to include non-ASCII character in some of 832 the information returned, and the use of the optional "name" and 833 "source" types. It also illustrates the use of an "encoding" type param- 834 eter to encode a certificate value in "B". A "vCard" profile [MIME- 835 VCARD] is used for the example. 837 Content-Type: text/directory; 838 charset="iso-8859-1"; 839 profile="vCard" 840 Content-ID: 841 Content-Transfer-Encoding: Quoted-Printable 843 begin: VCARD 844 source: ldap://cn=3Dbjorn%20Jensen, o=3Duniversity%20of%20Michigan, c=3DUS 845 name: Bjorn Jensen 846 fn: Bj=F8rn Jensen 847 n: Jensen;Bj=F8rn 848 email;type=3Dinternet: bjorn@umich.edu 849 tel;type=3Dwork,voice,msg:+1 313 747-4454 850 key;type=3Dx509;encoding=3DB: dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK 851 end: VCARD 853 Expires in six months INTERNET DRAFT 855 8.3. Example 3 857 The next example illustrates the use of multi-valued type parameters, 858 the "language" type parameter, the "value" type parameter, folding of 859 long lines, the \n encoding for formatted lines, attribute grouping, and 860 the inline "B" encoding. 862 Content-Type: text/directory; profile="person"; charset=iso-8859-1 863 Content-ID: 864 Content-Transfer-Encoding: Quoted-Printable 866 source: ldap://cn=Meister%20Berger,o=Universitaet%20Goerlitz,c=DE 867 name: Meister Berger 868 cn: Meister Berger 869 cn: Berger Meister 870 sn: Berger 871 age;value=integer: 33 872 o: Universit=E6t G=F6rlitz 873 title: Mayor 874 title;language=de;value=text: Burgermeister 875 description: The Mayor of the great city of 876 Goerlitz in the great country of Germany. 877 email: mb@goerlitz.de 878 home.phone;fax,voice,msg: +49 3581 123456 879 home.addr: Hufenshlagel 1234\n 880 02828 Goerlitz\n 881 Deutschland 882 certificate; encoding=b: MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkG 883 A1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRww 884 GgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29t 885 MB4XDTk3MDYwNjE5NDc1OVoXDTk3MTIwMzE5NDc1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYDVQQK 886 Ex1OZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3JwLjEYMBYGA1UEAxMPVGltb3RoeSBBIEhvd2Vz 887 MSEwHwYJKoZIhvcNAQkBFhJob3dlc0BuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dl 888 czBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2 889 dXcoX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQE 890 AwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9w0BAQQFAAOBgQBe 891 xv7o7mi3PLXadkmNP9LcIPmx93HGp0Kgyx1jIVMyNgsemeAwBM+MSlhMfcpbTrONwNjZYW8vJDSo 892 i//yrZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8VUMk1U7jt8LYpo4YULU7UZHPYVUaSgVttI 893 mOHZIKi4hlPXBOhcUQ== 895 8.4. Example 4 897 The final example illustrates the use of the multipart/related Content- 898 Type to include non-textual directory data via the "uri" encoding to 899 refer to other body parts within the same message, or to external 900 values. 902 Content-Type: multipart/related; 904 Expires in six months INTERNET DRAFT 906 boundary=woof; 907 type="text/directory"; 908 start="" 909 Content-ID: 911 --woof 912 Content-Type: text/directory; charset="iso-8859-1" 913 Content-ID: 914 Content-Transfer-Encoding: Quoted-Printable 916 source: ldap://cn=3DBjorn%20Jensen,o=3DUniversity%20of%20Michigan,c=3DUS 917 cn: Bj=F8rn Jensen 918 sn: Jensen 919 email: bjorn@umich.edu 920 image;encoding=3Duri: cid:id6@host.com 921 image;encoding=3Duri;format=3Djpeg: ftp://some.host/some/path.jpg 922 sound;encoding=3Duri: cid:id7@host.com 923 phone: +1 313 747-4454 925 --woof 926 Content-Type: image/jpeg 927 Content-ID: 929 <...image data...> 931 --woof 932 Content-Type: message/external-body; 933 name="myvoice.au"; 934 site="myhost.com"; 935 access-type=ANON-FTP; 936 directory="pub/myname"; 937 mode="image" 939 Content-Type: audio/basic 940 Content-ID: 942 --woof-- 944 9. Registration of new profiles 946 This section defines procedures by which new profiles are registered 947 with the IANA and made available to the Internet community. Note that 948 non-IANA profiles may be used by bilateral agreement, provided the asso- 949 ciated profile names follow the "X-" convention defined above. 951 The procedures defined here are designed to allow public comment and 952 review of new profiles, while posing only a small impediment to the 953 definition of new profiles. 955 Expires in six months INTERNET DRAFT 957 Registration of a new profile is accomplished by the following steps. 959 9.1. Define the profile 961 A profile is defined by completing the following template. 963 To: ietf-mime-direct@imc.org 964 Subject: Registration of text/directory MIME profile XXX 966 Profile name: 968 Profile purpose: 970 Profile types: 972 Profile special notes (optional): 974 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 976 The explanation of what goes in each field in the template follows. 978 Profile name: The name of the profile as it will appear in the 979 text/directory MIME Content-Type "profile" header parameter, or the 980 predefined "profile" type name. 982 Profile purpose: The purpose of the profile (e.g., to represent informa- 983 tion about people, printers, documents, etc.). Give a short but clear 984 description. 986 Profile types: The list of types associated with the profile. This list 987 of types is to be expected but not required in the profile, unless oth- 988 erwise noted in the profile definition. Other types not mentioned in 989 the profile definition may also be present. Note that any new types 990 referenced by the profile must be defined separately as described in 991 Section 10. 993 Profile special notes: Any special notes about the profile, how it is to 994 be used, etc. This section of the template may also be used to define an 995 ordering on the types that appear in the Content-Type, if such an order- 996 ing is required. 998 9.2. Post the profile definition 1000 The profile description must be posted to the new profile discussion 1001 list, ietf-mime-direct@imc.org 1002 Expires in six months INTERNET DRAFT 1004 9.3. Allow a comment period 1006 Discussion on the new profile must be allowed to take place on the list 1007 for a minimum of two weeks. Consensus must be reached on the profile 1008 before proceeding to step 4. 1010 9.4. Submit the profile for approval 1012 Once the two-week comment period has elapsed, and the proposer is con- 1013 vinced consensus has been reached on the profile, the registration 1014 application should be submitted to the Profile Reviewer for approval. 1015 The Profile Reviewer is appointed to the Application Area Directors and 1016 may either accept or reject the profile registration. An accepted regis- 1017 tration should be passed on by the Profile Reviewer to the IANA for 1018 inclusion in the official IANA profile registry. The registration may be 1019 rejected for any of the following reasons. 1) Insufficient comment 1020 period; 2) Consensus not reached; 3) Technical deficiencies raised on 1021 the list or elsewhere have not been addressed. The Profile Reviewer's 1022 decision to reject a profile may be appealed by the proposer to the 1023 IESG, or the objections raised can be addressed by the proposer and the 1024 profile resubmitted. 1026 10. Profile Change Control 1028 Existing profiles may be changed using the same process by which they 1029 were registered. 1031 Define the change 1033 Post the change 1035 Allow a comment period 1037 Submit the changed profile for approval 1039 Note that the original author or any other interested party may propose 1040 a change to an existing profile, but that such changes should only be 1041 proposed when there are serious omissions or errors in the published 1042 specification. The Profile Reviewer may object to a change if it is not 1043 backwards compatible, but is not required to do so. 1045 Profile definitions can never be deleted from the IANA registry, but 1046 profiles which are no longer believed to be useful can be declared 1047 OBSOLETE by a change to their "intended use" field. 1049 11. Registration of new types 1051 This section defines procedures by which new types are registered with 1052 Expires in six months INTERNET DRAFT 1054 the IANA. Note that non-IANA types may be used by bilateral agreement, 1055 provided the associated types names follow the "X-" convention defined 1056 above. 1058 The procedures defined here are designed to allow public comment and 1059 review of new types, while posing only a small impediment to the defini- 1060 tion of new types. 1062 Registration of a new type is accomplished by the following steps. 1064 11.1. Define the type 1066 A type is defined by completing the following template. 1068 To: ietf-mime-direct@imc.org 1069 Subject: Registration of text/directory MIME type XXX 1071 Type name: 1073 Type purpose: 1075 Type encoding: 1077 Type valuetype: 1079 Type special notes (optional): 1081 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1083 The meaning of each field in the template is as follows. 1085 Type name: The name of the type, as it will appear in the body of an 1086 text/directory MIME Content-Type "type: value" line to the left of the 1087 colon ":". 1089 Type purpose: The purpose of the type (e.g., to represent a name, postal 1090 address, IP address, etc.). Give a short but clear description. 1092 Type encoding: The default encoding a value of the type must have in the 1093 body of a text/directory MIME Content-Type. 1095 Type valuetype: The format a value of the type must have in the body of 1096 a text/directory MIME Content-Type. This description must be precise and 1097 must not violate the general encoding rules defined in section 5 of this 1098 document. 1100 Type special notes: Any special notes about the type, how it is to be 1101 used, etc. 1103 Expires in six months INTERNET DRAFT 1105 11.2. Post the type definition 1107 The type description must be posted to the new type discussion list, 1108 ietf-mime-direct@imc.org 1110 11.3. Allow a comment period 1112 Discussion on the new type must be allowed to take place on the list for 1113 a minimum of two weeks. Consensus must be reached on the type before 1114 proceeding to step 4. 1116 11.4. Submit the type for approval 1118 Once the two-week comment period has elapsed, and the proposer is con- 1119 vinced consensus has been reached on the type, the registration applica- 1120 tion should be submitted to the Profile Reviewer for approval. The Pro- 1121 file Reviewer is appointed to the Application Area Directors and may 1122 either accept or reject the type registration. An accepted registration 1123 should be passed on by the Profile Reviewer to the IANA for inclusion in 1124 the official IANA profile registry. The registration may be rejected for 1125 any of the following reasons. 1) Insufficient comment period; 2) Con- 1126 sensus not reached; 3) Technical deficiencies raised on the list or 1127 elsewhere have not been addressed. The Profile Reviewer's decision to 1128 reject a type may be appealed by the proposer to the IESG, or the objec- 1129 tions raised can be addressed by the proposer and the type resubmitted. 1131 12. Type Change Control 1133 Existing types may be changed using the same process by which they were 1134 registered. 1136 Define the change 1138 Post the change 1140 Allow a comment period 1142 Submit the type for approval 1144 Note that the original author or any other interested party may propose 1145 a change to an existing type, but that such changes should only be pro- 1146 posed when there are serious omissions or errors in the published 1147 specification. The Profile Reviewer may object to a change if it is not 1148 backwards compatible, but is not required to do so. 1150 Type definitions can never be deleted from the IANA registry, but types 1151 which are nolonger believed to be useful can be declared OBSOLETE by a 1152 change to their "intended use" field. 1154 Expires in six months INTERNET DRAFT 1156 13. Registration of new parameters 1158 This section defines procedures by which new parameters are registered 1159 with the IANA and made available to the Internet community. Note that 1160 non-IANA parameters may be used by bilateral agreement, provided the 1161 associated parameters names follow the "X-" convention defined above. 1163 The procedures defined here are designed to allow public comment and 1164 review of new parameters, while posing only a small impediment to the 1165 definition of new parameters. 1167 Registration of a new parameter is accomplished by the following steps. 1169 13.1. Define the parameter 1171 A parameter is defined by completing the following template. 1173 To: ietf-mime-direct@imc.org 1174 Subject: Registration of text/directory MIME type parameter XXX 1176 Parameter name: 1178 Parameter purpose: 1180 Parameter values: 1182 Parameter special notes (optional): 1184 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1186 The explanation of what goes in each field in the template follows. 1188 Parameter name: The name of the parameter as it will appear in the 1189 text/directory MIME Content-Type. 1191 Parameter purpose: The purpose of the parameter (e.g., to represent the 1192 format of an image, type of a phone number, etc.). Give a short but 1193 clear description. If defining a general paramemter like "format" or 1194 "type" keep in mind that other applications may wish to extend its use. 1196 Parameter values: The list or description of values associated with the 1197 parameter. 1199 Parameter special notes: Any special notes about the parameter, how it 1200 is to be used, etc. 1202 Expires in six months INTERNET DRAFT 1204 13.2. Post the parameter definition 1206 The parameter description must be posted to the new parameter discussion 1207 list, ietf-mime-direct@imc.org 1209 13.3. Allow a comment period 1211 Discussion on the new parameter must be allowed to take place on the 1212 list for a minimum of two weeks. Consensus must be reached on the param- 1213 eter before proceeding to step 4. 1215 13.4. Submit the parameter for approval 1217 Once the two-week comment period has elapsed, and the proposer is con- 1218 vinced consensus has been reached on the parameter, the registration 1219 application should be submitted to the Profile Reviewer for approval. 1220 The Profile Reviewer is appointed to the Application Area Directors and 1221 may either accept or reject the parameter registration. An accepted 1222 registration should be passed on by the Profile Reviewer to the IANA for 1223 inclusion in the official IANA parameter registry. The registration may 1224 be rejected for any of the following reasons. 1) Insufficient comment 1225 period; 2) Consensus not reached; 3) Technical deficiencies raised on 1226 the list or elsewhere have not been addressed. The Profile Reviewer's 1227 decision to reject a profile may be appealed by the proposer to the 1228 IESG, or the objections raised can be addressed by the proposer and the 1229 parameter registration resubmitted. 1231 14. Parameter Change Control 1233 Existing parameters may be changed using the same process by which they 1234 were registered. 1236 Define the change 1238 Post the change 1240 Allow a comment period 1242 Submit the parameter for approval 1244 Note that the original author or any other interested party may propose 1245 a change to an existing parameter, but that such changes should only be 1246 proposed when there are serious omissions or errors in the published 1247 specification. The Profile Reviewer may object to a change if it is not 1248 backwards compatible, but is not required to do so. 1250 Parameter definitions can never be deleted from the IANA registry, but 1251 parameters which are nolonger believed to be useful can be declared 1252 Expires in six months INTERNET DRAFT 1254 OBSOLETE by a change to their "intended use" field. 1256 15. Registration of new value types 1258 This section defines procedures by which new value types are registered 1259 with the IANA and made available to the Internet community. Note that 1260 non-IANA value types may be used by bilateral agreement, provided the 1261 associated value types names follow the "X-" convention defined above. 1263 The procedures defined here are designed to allow public comment and 1264 review of new value types, while posing only a small impediment to the 1265 definition of new value types. 1267 Registration of a new value types is accomplished by the following 1268 steps. 1270 15.1. Define the value type 1272 A value type is defined by completing the following template. 1274 To: ietf-mime-direct@imc.org 1275 Subject: Registration of text/directory MIME value type XXX 1277 value type name: 1279 value type purpose: 1281 value type format: 1283 value type special notes (optional): 1285 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1287 The explanation of what goes in each field in the template follows. 1289 value type name: The name of the value type as it will appear in the 1290 text/directory MIME Content-Type. 1292 value type purpose: The purpose of the value type. Give a short but 1293 clear description. 1295 value type format: The definition of the format for the value, usually 1296 using BNF grammar. 1298 value type special notes: Any special notes about the value type, how 1299 it is to be used, etc. 1301 Expires in six months INTERNET DRAFT 1303 15.2. Post the value type definition 1305 The value type description must be posted to the new value type discus- 1306 sion list, ietf-mime-direct@imc.org 1308 15.3. Allow a comment period 1310 Discussion on the new value type must be allowed to take place on the 1311 list for a minimum of two weeks. Consensus must be reached before 1312 proceeding to step 4. 1314 15.4. Submit the value type for approval 1316 Once the two-week comment period has elapsed, and the proposer is con- 1317 vinced consensus has been reached on the value type, the registra- 1318 tion application should be submitted to the Profile Reviewer for 1319 approval. The Profile Reviewer is appointed to the Application Area 1320 Directors and may either accept or reject the value type registration. 1321 An accepted registration should be passed on by the Profile Reviewer to 1322 the IANA for inclusion in the official IANA value type registry. The 1323 registration may be rejected for any of the following reasons. 1) 1324 Insufficient comment period; 2) Consensus not reached; 3) Technical 1325 deficiencies raised on the list or elsewhere have not been 1326 addressed. The Profile Reviewer's decision to reject a profile may be 1327 appealed by the proposer to the IESG, or the objections raised can 1328 be addressed by the proposer and the value type registration resubmit- 1329 ted. 1331 16. Security Considerations 1333 Internet mail is subject to many well known security attacks, including 1334 monitoring, replay, and forgery. Care should be taken by any directory 1335 service in allowing information to leave the scope of the service 1336 itself, where any access controls can no longer be guaranteed. Applica- 1337 tions should also take care to display directory data in a "safe" 1338 environment (e.g., PostScript-valued types). 1340 17. Acknowledgements 1342 The registration procedures defined here were shamelessly lifted from 1343 the MIME registration RFC. 1345 The many valuable comments contributed by members of the IETF ASID work- 1346 ing group are gratefully acknowledged, as are the contributions of the 1347 Versit Consortium.. 1349 Expires in six months INTERNET DRAFT 1351 18. References 1353 [RFC-1777] Yeong, W., Howes, T., Kille, S., "Lightweight Directory 1354 Access Protocol", Request for Comment (RFC) 1777, March 1995. 1356 [RFC-1778] Howes, T., Kille, S., Yeong, W., Robbins, C.J., "The String 1357 Representation of Standard Attribute Syntaxes", Request for 1358 Comment (RFC) 1778, March 1995. 1360 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 1361 Messages", STD 11, RFC 822, August 1982. 1363 [RFC-2045] Borenstein, N., Freed, N., "Multipurpose Internet Mail Exten- 1364 sions (MIME) Part One: Format of Internet Message Bodies", 1365 RFC 2045, November 1996. 1367 [RFC-2046] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part 1368 Two: Media Types", RFC 2046, November 1996. 1370 [RFC-2048] Freed, N., Klensin, J., Postel, J., "Multipurpose Internet 1371 Mail Extensions (MIME) Part Four: Registration Procedures", 1372 RFC 2048, November 1996 1374 [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", 1375 RFC 1766, March 1995. 1377 [RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type," RFC 1378 2112, March 1997. 1380 [X500] "Information Processing Systems - Open Systems Interconnec- 1381 tion - The Directory: Overview of Concepts, Models and Ser- 1382 vices", ISO/IEC JTC 1/SC21, International Standard 9594-1, 1383 1988. 1385 [RFC-1835] Deutsch, P., Schoultz, R., Faltstrom, P., Weider, C., "Archi- 1386 tecture of the WHOIS++ service", August 1995. 1388 [RFC-1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform 1389 Resource Locators (URL)", RFC 1738, December 1994. 1391 [DATETIME] Newman, C., "Date and Time on the Internet", Internet Draft 1392 draft-newman-datetime-01.txt, January 1997. 1394 [MIME-VCARD]F. Dawson, T. Howes, "VCard MIME Directory Profile", 1395 Internet-Draft draft-ietf-asid-mime-vcard-04.txt, November, 1396 1997. 1398 [VCARD] Versit Consortium, "vCard - The Electronic Business Card", 1399 Expires in six months INTERNET DRAFT 1401 Version 2.1, http://www.imc.com/pdi/vcard-21.txt, September, 1402 1996. 1404 [RFC-2119] "Key words for use in RFCs to Indicate Requirement Levels", 1405 RFC 2119, March 1997. 1407 19. Author's Address 1409 Tim Howes 1410 Netscape Communications Corp. 1411 501 East Middlefield Rd. 1412 Mountain View, CA 94041 1413 USA 1414 howes@netscape.com 1415 +1.415.937.3419 1417 Mark Smith 1418 Netscape Communications Corp. 1419 501 East Middlefield Rd. 1420 Mountain View, CA 94041 1421 USA 1422 mcs@netscape.com 1423 +1.415.937.3477 1425 Frank Dawson 1426 Lotus Development Corporation 1427 6544 Battleford Drive 1428 Raleigh, NC 27613 1429 USA 1430 fdawson@earthlink.net 1431 +1-919-676-9515 1433 20. Table of Contents