rfc2425.txt (64428B)
1 2 3 4 5 6 7 Network Working Group T. Howes 8 Request for Comments: 2425 M. Smith 9 Category: Standards Track Netscape Communications Corp. 10 F. Dawson 11 Lotus Development Corporation 12 September 1998 13 14 15 A MIME Content-Type for Directory Information 16 17 Status of this Memo 18 19 This document specifies an Internet standards track protocol for the 20 Internet community, and requests discussion and suggestions for 21 improvements. Please refer to the current edition of the "Internet 22 Official Protocol Standards" (STD 1) for the standardization state 23 and status of this protocol. Distribution of this memo is unlimited. 24 25 Copyright Notice 26 27 Copyright (C) The Internet Society (1998). All Rights Reserved. 28 29 1. Abstract 30 31 This document defines a MIME Content-Type for holding directory 32 information. The definition is independent of any particular 33 directory service or protocol. The text/directory Content-Type is 34 defined for holding a variety of directory information, for example, 35 name, or email address, or logo. The text/directory Content-Type can 36 also be used as the root body part in a multipart/related Content- 37 Type for handling more complicated situations, especially those in 38 which non-textual information that already has a natural MIME 39 representation, for example, a photograph or sound, is to be 40 represented. 41 42 The text/directory Content-Type defines a general framework and 43 format for holding directory information in a simple "type:value" 44 form. We refer to "type" in this context meaning a property or 45 attribute with which the value is associated. Mechanisms are defined 46 to specify alternate languages, encodings and other meta-information. 47 This document also defines the procedure by which particular formats, 48 called profiles, for carrying application-specific information within 49 a text/directory Content-Type can be defined and registered, and the 50 conventions such formats must follow. It is expected that other 51 documents will be produced that define such formats for various 52 applications (e.g., white pages). 53 54 55 56 57 58 Howes, et. al. Standards Track [Page 1] 59 60 RFC 2425 MIME Content-Type for Directory Information September 1998 61 62 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC-2119]. 66 67 2. Table of Contents 68 69 Status of the Memo................................................ 1 70 Copyright Notice.................................................. 1 71 1. Abstract...................................................... 1 72 2. Table of Contents............................................. 2 73 3. Need for a MIME Directory Type................................ 3 74 4. Overview...................................................... 4 75 5. The text/directory Content-Type............................... 4 76 5.1. MIME media type name........................................ 4 77 5.2. MIME subtype name........................................... 5 78 5.3. Required parameters......................................... 5 79 5.4. Optional parameters......................................... 5 80 5.5. Encoding considerations..................................... 5 81 5.6. Security considerations..................................... 6 82 5.7. Interoperability considerations............................. 6 83 5.8. Published specification..................................... 6 84 5.8.1. Line delimiting and folding............................... 6 85 5.8.2. ABNF content-type definition.............................. 7 86 5.8.3. Pre-defined Parameters.................................... 9 87 5.8.4. Pre-defined Value Types...................................11 88 5.9. Applications which use this media type......................14 89 5.10. Additional information.....................................14 90 5.11. Person & email address to contact for further information..14 91 5.12. Intended usage.............................................14 92 5.13. Author/Change controller...................................15 93 6. Predefined Types..............................................15 94 6.1. SOURCE Type Definition......................................15 95 6.2. NAME Type Definition........................................16 96 6.3. PROFILE Type Definition.....................................16 97 6.4. BEGIN Type Definition.......................................17 98 6.5. END Type Definition.........................................17 99 7. Use of the multipart/related Content-Type.....................18 100 8. Examples.......................................................18 101 8.1. Example 1...................................................19 102 8.2. Example 2...................................................19 103 8.3. Example 3...................................................20 104 8.4. Example 4...................................................21 105 9. Registration of new profiles..................................22 106 9.1. Define the profile..........................................22 107 9.2. Post the profile definition.................................23 108 9.3. Allow a comment period......................................23 109 9.4. Submit the profile for approval.............................23 110 10. Profile Change Control.......................................23 111 112 113 114 Howes, et. al. Standards Track [Page 2] 115 116 RFC 2425 MIME Content-Type for Directory Information September 1998 117 118 119 11. Registration of new types....................................24 120 11.1. Define the type............................................24 121 11.2. Post the type definition...................................25 122 11.3. Allow a comment period.....................................25 123 11.4. Submit the type for approval...............................25 124 12. Type Change Control..........................................25 125 13. Registration of new parameters...............................26 126 13.1. Define the parameter.......................................26 127 13.2. Post the parameter definition..............................27 128 13.3. Allow a comment period.....................................27 129 13.4. Submit the parameter for approval..........................27 130 14. Parameter Change Control.....................................28 131 15. Registration of new value types..............................28 132 15.1. Define the value type......................................28 133 15.2. Post the value type definition.............................29 134 15.3. Allow a comment period.....................................29 135 15.4. Submit the value type for approval.........................29 136 16. Security Considerations......................................30 137 17. Acknowledgements..............................................30 138 18. References....................................................30 139 19. Authors' Addresses...........................................32 140 20. Full Copyright Statement......................................33 141 142 3. Need for a MIME Directory Type 143 144 For purposes of this document, a directory is a special-purpose 145 database that contains typed information. A directory usually 146 supports both read and search of the information it contains, and can 147 support creation and modification of the information as well. 148 Directory information is usually accessed far more often than it is 149 updated. Directories can be local or global in scope. They can be 150 distributed or centralized. The information they contain can be 151 replicated, with weak or strong consistency requirements. 152 153 There are several situations in which users of Internet mail might 154 wish to exchange directory information: the email analogy of a 155 "business card" exchange; the conveyance of directory information to 156 a user having only email access to the Internet; the provision of 157 machine-parseable address information when purchasing goods or 158 services over the Internet; etc. As MIME [RFC-2045, RFC-2046] is 159 used increasingly by other protocols, most notably HTTP, it can also 160 be useful for these protocols to carry directory information in MIME 161 format. Such a format, for example, could be used to represent URC 162 (uniform resource characteristics) information about resources on the 163 World Wide Web, or to provide a rudimentary directory service over 164 HTTP. 165 166 167 168 169 170 Howes, et. al. Standards Track [Page 3] 171 172 RFC 2425 MIME Content-Type for Directory Information September 1998 173 174 175 4. Overview 176 177 The scheme defined here for representing directory information in a 178 MIME Content-Type has two parts. First, the text/directory Content- 179 Type is defined for use in holding directory information within a 180 single body part, for example name, title, or email address. In its 181 simplest form, the format uses a "type:value" approach, which should 182 be easily parseable by existing MIME implementations and 183 understandable by users. More complicated situations can be 184 represented also. This document defines the general form the 185 information in the Content-Type should have, and the procedure by 186 which specific types and values (properties) for particular 187 applications can be defined. The framework is general enough to 188 handle information from any number of end directory services, 189 including LDAP [RFC-1777, RFC-1778], WHOIS++ [RFC-1835], and X.500 190 [X500]. 191 192 Directory entries can include far more than just textual information. 193 Some such information (e.g., an image or sound) overlaps with 194 predefined MIME Content-Types. In these cases it can be desirable to 195 include the information in its well-known MIME format. This situation 196 is handled by using a multipart/related Content-Type as defined in 197 [RFC-2112]. The root component of this type is a text/directory body 198 part specifying any in-line information, and for information 199 contained in other Content-Types, the Content-IDs (in URI form) of 200 those parts. 201 202 In some applications, it can be useful to include a pointer (e.g, a 203 URI) to some directory information rather than the information 204 itself. This document defines a general mechanism for accomplishing 205 this. 206 207 5. The text/directory Content-Type 208 209 The text/directory Content-Type is used to hold basic directory 210 information and URIs referencing other information, including other 211 MIME body parts holding supplementary or non-textual directory 212 information, such as an image or sound. It is defined as follows, 213 using the MIME media type registration template from [RFC-2048]. 214 215 To: ietf-types@uninett.no 216 Subject: Registration of MIME media type text/directory 217 218 5.1. MIME media type name 219 220 MIME media type name: text 221 222 223 224 225 226 Howes, et. al. Standards Track [Page 4] 227 228 RFC 2425 MIME Content-Type for Directory Information September 1998 229 230 231 5.2. MIME subtype name 232 233 MIME subtype name: directory 234 235 5.3. Required parameters 236 237 Required parameters: charset 238 239 The "charset" parameter is as defined in [RFC-2046] for other body 240 parts. It is used to identify the default character set used within 241 the body part. 242 243 5.4. Optional parameters 244 245 Optional parameters: profile 246 247 The "profile" parameter is used to convey the type(s) of entity(ies) 248 to which the directory information pertains and the likely set of 249 information associated with the entity(ies). It is intended only as a 250 guide to applications interpreting the information contained within 251 the body part. It SHOULD NOT be used to exclude or require particular 252 pieces of information unless a profile definition specifically calls 253 for this behavior. Unless specifically forbidden by a particular 254 profile definition, a text/directory content type can contain 255 arbitrary attribute/value pairs. 256 257 The value of the "profile" parameter is defined as follows. Profile 258 names are case insensitive (i.e., the profile name "vCard" is the 259 same as "VCARD" and "vcard" and "vcArD"). 260 261 profile = x-name / iana-token 262 263 x-name = "x-" 1*(ALPHA / DIGIT / "-") 264 ; Names beginning with "x-" or "X-" are 265 ; reserved for experimental use not intended for released 266 ; products, or for use in bilateral agreements. 267 268 iana-token = <a publicly-defined extension token, registered 269 with IANA, as specified in Section 9 of this 270 document> 271 272 5.5. Encoding considerations 273 274 The default encoding is 8bit. Otherwise, as specified by the 275 Content-Transfer-Encoding header field. 276 277 278 279 280 281 282 Howes, et. al. Standards Track [Page 5] 283 284 RFC 2425 MIME Content-Type for Directory Information September 1998 285 286 287 5.6. Security considerations 288 289 Directory information can be public or it can be protected from 290 unauthorized access by the directory service in which it resides. 291 Once the information leaves its native service, there can be no 292 guarantee that the same care will be taken by all services handling 293 the information. Furthermore, this specification defines no access 294 control mechanism by which information can be protected, or by which 295 access control information can be conveyed. Note that the integrity 296 and privacy of a text/directory body part can be protected by 297 enclosing it within an appropriate MIME-based security mechanism. 298 299 5.7. Interoperability considerations 300 301 In order to make sense of directory information, applications must 302 share a common understanding of the types of information contained 303 within the Content-Type (the directory schema). This schema 304 information is not defined in this document, but rather in companion 305 documents (e.g., [MIME-VCARD]) that follow the requirements specified 306 in this document, or in bilateral agreements between communicating 307 parties. 308 309 5.8. Published specification 310 311 The text/directory Content-Type contains directory information, 312 typically pertaining to a single directory entity or group of 313 entities. The content consists of one or more lines in the format 314 given below. 315 316 5.8.1. Line delimiting and folding 317 318 Individual lines within the MIME text/directory Content Type body are 319 delimited by the [RFC-822] line break, which is a CRLF sequence 320 (ASCII decimal 13, followed by ASCII decimal 10). Long logical lines 321 of text can be split into a multiple-physical-line representation 322 using the following folding technique. 323 324 A logical line MAY be continued on the next physical line anywhere 325 between two characters by inserting a CRLF immediately followed by a 326 single white space character (space, ASCII decimal 32, or horizontal 327 tab, ASCII decimal 9). At least one character must be present on the 328 folded line. Any sequence of CRLF followed immediately by a single 329 white space character is ignored (removed) when processing the 330 content type. For example the line: 331 332 DESCRIPTION:This is a long description that exists on a long line. 333 334 Can be represented as: 335 336 337 338 Howes, et. al. Standards Track [Page 6] 339 340 RFC 2425 MIME Content-Type for Directory Information September 1998 341 342 343 DESCRIPTION:This is a long description 344 that exists on a long line. 345 346 It could also be represented as: 347 348 DESCRIPTION:This is a long descrip 349 tion that exists o 350 n a long line. 351 352 The process of moving from this folded multiple-line representation 353 of a type definition to its single line representation is called 354 unfolding. Unfolding is accomplished by regarding CRLF immediately 355 followed by a white space character (namely HTAB ASCII decimal 9 or 356 SPACE ASCII decimal 32) as equivalent to no characters at all (i.e., 357 the CRLF and single white space character are removed). 358 359 5.8.2. ABNF content-type definition 360 361 The following ABNF uses the notation of RFC 2234, which also defines 362 CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. After the unfolding of 363 any folded lines as described above, the syntax for a line of this 364 content type is as follows: 365 366 contentline = [group "."] name *(";" param) ":" value CRLF 367 ; When parsing a content line, folded lines MUST first 368 ; be unfolded according to the unfolding procedure 369 ; described above. 370 ; When generating a content line, lines longer than 75 371 ; characters SHOULD be folded according to the folding 372 ; procedure described above. 373 374 group = 1*(ALPHA / DIGIT / "-") 375 376 name = x-name / iana-token 377 378 iana-token = 1*(ALPHA / DIGIT / "-") 379 ; identifier registered with IANA 380 381 x-name = "x-" 1*(ALPHA / DIGIT / "-") 382 ; Names that begin with "x-" or "X-" are 383 ; reserved for experimental use, not intended for released 384 ; products, or for use in bilateral agreements. 385 386 param = param-name "=" param-value *("," param-value) 387 388 param-name = x-name / iana-token 389 390 param-value = ptext / quoted-string 391 392 393 394 Howes, et. al. Standards Track [Page 7] 395 396 RFC 2425 MIME Content-Type for Directory Information September 1998 397 398 399 ptext = *SAFE-CHAR 400 401 value = *VALUE-CHAR 402 / valuespec ; valuespec defined in section 5.8.4 403 404 quoted-string = DQUOTE *QSAFE-CHAR DQUOTE 405 406 NON-ASCII = %x80-FF 407 ; use restricted by charset parameter 408 ; on outer MIME object (UTF-8 preferred) 409 410 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII 411 ; Any character except CTLs, DQUOTE 412 413 SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII 414 ; Any character except CTLs, DQUOTE, ";", ":", "," 415 416 VALUE-CHAR = WSP / VCHAR / NON-ASCII 417 ; any textual character 418 419 A line that begins with a white space character is a continuation of 420 the previous line, as described above. The white space character and 421 immediately preceeding CRLF should be discarded when reconstructing 422 the original line. Note that this line-folding convention differs 423 from that found in RFC 822, in that the sequence <CRLF><WSP> found 424 anywhere in the content indicates a continued line and should be 425 removed. 426 427 Various type names and the format of the corresponding values are 428 defined as specified in Section 11. Specifications MAY impose 429 ordering on the type constructs within a body part, though none is 430 required by default. The various x-name constructs are used for 431 bilaterally-agreed upon type names, parameter names and parameter 432 values, or for use in experimental settings. 433 434 Type names and parameter names are case insensitive (e.g., the type 435 name "fn" is the same as "FN" and "Fn"). Parameter values MAY be case 436 sensitive or case insensitive, depending on their definition. 437 438 The group construct is used to group related attributes together. 439 The group name is a syntactic convention used to indicate that all 440 type names prefaced with the same group name SHOULD be grouped 441 together when displayed by an application. It has no other 442 significance. Implementations that do not understand or support 443 grouping MAY simply strip off any text before a "." to the left of 444 the type name and present the types and values as normal. 445 446 447 448 449 450 Howes, et. al. Standards Track [Page 8] 451 452 RFC 2425 MIME Content-Type for Directory Information September 1998 453 454 455 Each attribute defined in the text/directory body MAY have multiple 456 values, if allowed in the definition of the profile in which the 457 attribute is used. The general rule for encoding multi-valued items 458 is to simply create a new content line for each value (including the 459 type name). However, it should be noted that some value types 460 support encoding multiple values in a single content line by 461 separating the values with a comma ",". This approach has been taken 462 for several of the content types defined below (date, time, integer, 463 float), for space-saving reasons. 464 465 5.8.3. Pre-defined Parameters 466 467 The following parameters and value types are defined for general use. 468 469 predefined-param = encodingparm 470 / valuetypeparm 471 / languageparm 472 / contextparm 473 474 encodingparm = "encoding" "=" encodingtype 475 476 encodingtype = "b" ; from RFC 2047 477 / iana-token ; registered as described in 478 ; section 15 of this document 479 480 valuetypeparm = "value" "=" valuetype 481 482 valuetype = "uri" ; genericurl from secion 5 of RFC 1738 483 / "text" 484 / "date" 485 / "time" 486 / "date-time" ; date time 487 / "integer" 488 / "boolean" 489 / "float" 490 / x-name 491 / iana-token ; registered as described in 492 ; section 15 of this document 493 494 languageparm = "language" "=" Language-Tag 495 ; Language-Tag is defined in section 2 of RFC 1766 496 497 contextparm = "context" "=" context 498 499 context = x-name 500 / iana-token 501 502 503 504 505 506 Howes, et. al. Standards Track [Page 9] 507 508 RFC 2425 MIME Content-Type for Directory Information September 1998 509 510 511 The "language" type parameter is used to identify data in multiple 512 languages. There is no concept of "default" language, except as 513 specified by any "Content-Language" MIME header parameter that is 514 present. The value of the "language" type parameter is a language 515 tag as defined in Section 2 of [RFC-1766]. 516 517 The "context" type parameter is used to identify a context (e.g., a 518 protocol) used in interpreting the value. This is used, for example, 519 in the "source" type, defined below. 520 521 The "encoding" type parameter is used to specify an alternate 522 encoding for a value. If the value contains a CRLF, it must be 523 encoded, since CRLF is used to separate lines in the content-type 524 itself. Currently, only the "b" encoding is supported. 525 526 The "b" encoding can also be useful for binary values that are mixed 527 with other text information in the body part (e.g., a certificate). 528 Using a per-value "b" encoding in this case leaves the other 529 information in a more readable form. The encoded base 64 value can be 530 split across multiple physical lines in the content type by using the 531 line folding technique described above. 532 533 The Content-Transfer-Encoding header field is used to specify the 534 encoding used for the body part as a whole. The "encoding" type 535 parameter is used to specify an encoding for a particular value 536 (e.g., a certificate). In this case, the Content-Transfer-Encoding 537 header might specify "8bit", while the one certificate value might 538 specify an encoding of "b" via an "encoding=b" type parameter. 539 540 The Content-Transfer-Encoding and the encodings of individual types 541 given by the "encoding" type parameter are independent of one 542 another. When encoding a text/directory body part for transmission, 543 individual type encodings are performed first, then the entire body 544 part is encoded according to the Content-Transfer-Encoding. When 545 decoding a text/directory body part, the Content-Transfer-Encoding is 546 decoded first, and then any individual types with an "encoding" type 547 parameter are decoded. 548 549 The "value" parameter is optional, and is used to identify the value 550 type (data type) and format of the value. The use of these 551 predefined formats is encouraged even if the value parameter is not 552 explicity used. By defining a standard set of value types and their 553 formats, existing parsing and processing code can be leveraged. 554 555 Including the value type explicitly as part of each property provides 556 an extra hint to keep parsing simple and support more generalized 557 applications. For example a search engine would not have to know the 558 particular value types for all of the items for which it is 559 560 561 562 Howes, et. al. Standards Track [Page 10] 563 564 RFC 2425 MIME Content-Type for Directory Information September 1998 565 566 567 searching. Because the value type is explicit in the definition, the 568 search engine could look for dates in any item type and provide 569 results that can still be interpreted. 570 571 5.8.4. Pre-defined Value Types 572 573 The format for values corresponding to the predefined valuetype 574 specifications given above are defined. 575 576 valuespec = text-list 577 / genericurl ; from section 5 of RFC 1738 578 / date-list 579 / time-list 580 / date-time-list 581 / boolean 582 / integer-list 583 / float-list 584 / iana-valuespec 585 586 text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR) 587 588 TEXT-LIST-CHAR = "\\" / "\," / "\n" 589 / <any VALUE-CHAR except , or \ or newline> 590 ; Backslashes, newlines, and commas must be encoded. 591 ; \n or \N can be used to encode a newline. 592 593 date-list = date *("," date) 594 595 time-list = time *("," time) 596 597 date-time-list = date "T" time *("," date "T" time) 598 599 boolean = "TRUE" / "FALSE" 600 601 integer-list = integer *("," integer) 602 603 integer = [sign] 1*DIGIT 604 605 float-list = float *("," float) 606 607 float = [sign] 1*DIGIT ["." 1*DIGIT] 608 609 sign = "+" / "-" 610 611 date = date-fullyear ["-"] date-month ["-"] date-mday 612 613 date-fullyear = 4 DIGIT 614 615 616 617 618 Howes, et. al. Standards Track [Page 11] 619 620 RFC 2425 MIME Content-Type for Directory Information September 1998 621 622 623 date-month = 2 DIGIT ;01-12 624 625 date-mday = 2 DIGIT ;01-28, 01-29, 01-30, 01-31 626 ;based on month/year 627 628 time = time-hour [":"] time-minute [":"] time-second [time-secfrac] 629 [time-zone] 630 631 time-hour = 2 DIGIT ;00-23 632 633 time-minute = 2 DIGIT ;00-59 634 635 time-second = 2 DIGIT ;00-60 (leap second) 636 637 time-secfrac = "," 1*DIGIT 638 639 time-zone = "Z" / time-numzone 640 641 time-numzome = sign time-hour [":"] time-minute 642 643 iana-valuespec = <a publicly-defined valuetype format, registered 644 with IANA, as defined in section 15 of this 645 document> 646 647 Some specific notes on the value types and formats: 648 649 "text": The "text" value type should be used to identify values that 650 contain human-readable text. The character set and language in which 651 the text is represented is controlled by the charset content-header 652 and the language type parameter and content-header. 653 654 Examples for "text": 655 this is a text value 656 this is one value,this is another 657 this is a single value\, with a comma encoded 658 659 A formatted text line break in a text value type MUST be represented 660 as the character sequence backslash (ASCII decimal 92) followed by a 661 Latin small letter n (ASCII decimal 110) or a Latin capital letter N 662 (ASCII decimal 78), that is "\n" or "\N". 663 664 For example a multiple line DESCRIPTION value of: 665 666 Mythical Manager 667 Hyjinx Software Division 668 BabsCo, Inc. 669 670 could be represented as: 671 672 673 674 Howes, et. al. Standards Track [Page 12] 675 676 RFC 2425 MIME Content-Type for Directory Information September 1998 677 678 679 DESCRIPTION:Mythical Manager\nHyjinx Software Division\n 680 BabsCo\, Inc.\n 681 682 demonstrating the \n literal formatted line break technique, the 683 CRLF-followed-by-space line folding technique, and the backslash 684 escape technique. 685 686 "uri": The "uri" value type should be used to identify values that 687 are referenced by a URI (including a Content-ID URI), instead of 688 encoded in-line. These value references might be used if the value is 689 too large, or otherwise undesirable to include directly. The format 690 for the URI is as defined in RFC 1738. 691 692 Examples for "uri": 693 http://www.foobar.com/my/picture.jpg 694 ldap://ldap.foobar.com/cn=babs%20jensen 695 696 "date", "time", and "date-time": Each of these value types is based 697 on a subset of the definitions in ISO 8601 standard. Profiles MAY 698 place further restrictions on "date" and "time" values. Multiple 699 "date" and "time" values can be specified using the comma-separated 700 notation, unless restricted by a profile. 701 702 Examples for "date": 703 1985-04-12 704 1996-08-05,1996-11-11 705 19850412 706 707 Examples for "time": 708 10:22:00 709 102200 710 10:22:00.33 711 10:22:00.33Z 712 10:22:33,11:22:00 713 10:22:00-08:00 714 715 Examples for "date-time": 716 1996-10-22T14:00:00Z 717 1996-08-11T12:34:56Z 718 19960811T123456Z 719 1996-10-22T14:00:00Z,1996-08-11T12:34:56Z 720 721 "boolean": The "boolean" value type is used to express boolen values. 722 These values are case insensitive. 723 724 Examples: TRUE 725 false 726 True 727 728 729 730 Howes, et. al. Standards Track [Page 13] 731 732 RFC 2425 MIME Content-Type for Directory Information September 1998 733 734 735 "integer": The "integer" value type is used to express signed 736 integers in decimal format. If sign is not specified, the value is 737 assumed positive "+". Multiple "integer" values can be specified 738 using the comma-separated notation, unless restricted by a profile. 739 740 Examples: 1234567890 741 -1234556790 742 +1234556790,432109876 743 744 "float": The "float" value type is used to express real numbers. If 745 sign is not specified, the value is assumed positive "+". Multiple 746 "float" values can be specified using the comma-separated notation, 747 unless restricted by a profile. 748 749 Examples: 20.30 750 1000000.0000001 751 1.333,3.14 752 753 5.9. Applications which use this media type 754 755 Applications which use this media type: Various 756 757 5.10. Additional information 758 759 Additional information: None 760 761 5.11. Person & email address to contact for further information 762 763 Tim Howes 764 Netscape Communications Corp. 765 501 East Middlefield Rd. 766 Mountain View, CA 94041 767 USA 768 howes@netscape.com 769 +1 415 937 3419 770 771 5.12. Intended usage 772 773 Intended usage: COMMON 774 775 776 777 778 779 780 781 782 783 784 785 786 Howes, et. al. Standards Track [Page 14] 787 788 RFC 2425 MIME Content-Type for Directory Information September 1998 789 790 791 5.13. Author/Change controller 792 793 Tim Howes 794 Netscape Communications Corp. 795 501 East Middlefield Rd. 796 Mountain View, CA 94041 797 USA 798 howes@netscape.com 799 +1 415 937 3419 800 801 Mark Smith 802 Netscape Communications Corp. 803 501 East Middlefield Rd. 804 Mountain View, CA 94041 805 USA 806 mcs@netscape.com 807 +1 415 937 3477 808 809 Frank Dawson 810 Lotus Development Corporation 811 6544 Battleford Drive 812 Raleigh, NC 27613-3502 813 USA 814 frank_dawson@lotus.com 815 +1-919-676-9515 816 817 6. Predefined Types 818 819 The following types are generally useful regardless of the profile 820 being carried and are defined below using the text/directory MIME 821 type registration template defined in Section 11.1 of this document. 822 These types MAY be included in any profile, unless explicitly 823 forbidden in the profile definition. 824 825 6.1. SOURCE Type Definition 826 827 To: ietf-mime-direct@imc.org 828 Subject: Registration of text/directory MIME type SOURCE 829 830 Type name: SOURCE 831 832 Type purpose: To identify the source of directory information 833 contained in the content type. 834 835 Type encoding: 8bit 836 837 Type valuetype: uri 838 839 840 841 842 Howes, et. al. Standards Track [Page 15] 843 844 RFC 2425 MIME Content-Type for Directory Information September 1998 845 846 847 Type special notes: The SOURCE type is used to provide the means by 848 which applications knowledgable in the given directory service 849 protocol can obtain additional or more up-to-date information from 850 the directory service. It contains a URI as defined in [RFC-1738] 851 and/or other information referencing the directory entity or entities 852 to which the information pertains. When directory information is 853 available from more than one source, the sending entity can pick what 854 it considers to be the best source, or multiple SOURCE types can be 855 included. The interpretation of the value for a SOURCE type can 856 depend on the setting of the CONTEXT type parameter. The value of the 857 CONTEXT type parameter MUST be compatible with the value of the uri 858 prefix. 859 860 Type example: 861 SOURCE;CONTEXT=LDAP:ldap://ldap.host/cn=Babs%20Jensen, 862 %20o=Babsco,%20c=US 863 864 6.2. NAME Type Definition 865 866 To: ietf-mime-direct@imc.org 867 Subject: Registration of text/directory MIME type NAME 868 869 Type name: NAME 870 871 Type purpose: To identify the displayable name of the directory 872 entity to which information in the content type pertains. 873 874 Type encoding: 8bit 875 876 Type valuetype: text 877 878 Type special notes: The NAME type is used to convey the display name 879 of the entity to which the directory information pertains. 880 881 Type example: 882 NAME:Babs Jensen's Contact Information 883 884 6.3. PROFILE Type Definition 885 886 To: ietf-mime-direct@imc.org 887 Subject: Registration of text/directory MIME type PROFILE 888 889 Type name: PROFILE 890 891 Type purpose: To identify the type of directory entity to which 892 information in the content type pertains. 893 894 Type encoding: 8bit 895 896 897 898 Howes, et. al. Standards Track [Page 16] 899 900 RFC 2425 MIME Content-Type for Directory Information September 1998 901 902 903 Type valuetype: A profile name, registered as described in Section 9 904 of this document or bilaterally agreed upon as described in Section 905 5. 906 907 Type special notes: The PROFILE type is used to convey the type of 908 the entity to which the directory information in the rest of the body 909 part pertains. It should be the same as the "profile" header 910 parameter, if present. 911 912 Type example: 913 PROFILE:vCard 914 915 6.4. BEGIN Type Definition 916 917 To: ietf-mime-direct@imc.org 918 Subject: Registration of text/directory MIME type BEGIN 919 920 Type name: BEGIN 921 922 Type purpose: To denote the beginning of a syntactic entity within a 923 text/directory content-type. 924 925 Type encoding: 8bit 926 927 Type valuetype: text, containing a profile name, registered as 928 described in Section 9 of this document or bilaterally-agreed upon as 929 described in Section 5. 930 931 Type special notes: The BEGIN type is used in conjunction with the 932 END type to delimit a profile containing a related set of properties 933 within an text/directory content-type. This construct can be used 934 instead of or in addition to wrapping separate sets of information 935 inside additional MIME headers. It is provided for applications that 936 wish to define content that can contain multiple entities within the 937 same text/directory content-type or to define content that can be 938 identifiable outside of a MIME environment. 939 940 Type example: 941 BEGIN:VCARD 942 943 6.5. END Type Definition 944 945 To: ietf-mime-direct@imc.org 946 Subject: Registration of text/directory MIME type END 947 948 Type name: END 949 950 951 952 953 954 Howes, et. al. Standards Track [Page 17] 955 956 RFC 2425 MIME Content-Type for Directory Information September 1998 957 958 959 Type purpose: To denote the end of a syntactic entity within a 960 text/directory content-type. 961 962 Type encoding: 8bit 963 964 Type valuetype: text, containing a profile name, registered as 965 described in Section 9 of this document or bilaterally-agreed upon as 966 described in Section 5. 967 968 Type special notes: The END type is used in conjunction with the 969 BEGIN type to delimit a profile containing a related set of 970 properties within an text/directory content-type. This construct can 971 be used instead of or in addition to wrapping separate sets of 972 information inside additional MIME headers. It is provided for 973 applications that wish to define content that can contain multiple 974 entities within the same text/directory content-type or to define 975 content that can be identifiable outside of a MIME environment. 976 977 Type example: 978 END: VCARD 979 980 7. Use of the multipart/related Content-Type 981 982 The multipart/related Content-Type can be used to hold directory 983 information comprised of both text and non-text information or 984 directory information that already has a natural MIME representation. 985 The root body part within the multipart/related body part is 986 specified as defined in [RFC-2112] by a "start" parameter, or it is 987 the first body part in the absence of such a parameter. The root 988 body part must have a Content-Type of "text/directory". This part 989 holds inline information and makes reference to subsequent body parts 990 holding additional text or non-text directory information via their 991 Content-ID URIs as explained in Section 5. 992 993 The body parts referred to do not have to be in any particular order, 994 except as noted above for the root body part. 995 996 8. Examples 997 998 The following examples are for illustrative purposes only and are not 999 part of the definition. 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 Howes, et. al. Standards Track [Page 18] 1011 1012 RFC 2425 MIME Content-Type for Directory Information September 1998 1013 1014 1015 8.1. Example 1 1016 1017 The first example illustrates simple use of the text/directory 1018 Content-Type. Note that no "profile" parameter is given, so an 1019 application may not know what kind of directory entity the 1020 information applies to. Note also the use of both hypothetical 1021 official and bilaterally agreed upon types. 1022 1023 From: Whomever@wherever.com 1024 To: Someone@somewhere.com 1025 Subject: whatever 1026 MIME-Version: 1.0 1027 Message-ID: <id1@host.net> 1028 Content-Type: text/directory 1029 Content-ID: <id2@host.com> 1030 1031 cn:Babs Jensen 1032 cn:Barbara J Jensen 1033 sn:Jensen 1034 email:babs@umich.edu 1035 phone:+1 313 747-4454 1036 x-id:1234567890 1037 1038 8.2. Example 2 1039 1040 The next example illustrates the use of the Quoted-Printable transfer 1041 encoding defined in [RFC 2045] to include non-ASCII character in some 1042 of the information returned, and the use of the optional "name" and 1043 "source" types. It also illustrates the use of an "encoding" type 1044 parameter to encode a certificate value in "b". A "vCard" profile 1045 [MIME- VCARD] is used for the example. 1046 1047 Content-Type: text/directory; 1048 charset="iso-8859-1"; 1049 profile="vCard" 1050 Content-ID: <id3@host.com> 1051 Content-Transfer-Encoding: Quoted-Printable 1052 1053 begin:VCARD 1054 source:ldap://cn=bjorn%20Jensen, o=university%20of%20Michigan, c=US 1055 name:Bjorn Jensen 1056 fn:Bj=F8rn Jensen 1057 n:Jensen;Bj=F8rn 1058 email;type=internet:bjorn@umich.edu 1059 tel;type=work,voice,msg:+1 313 747-4454 1060 key;type=x509;encoding=B:dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK 1061 end:VCARD 1062 1063 1064 1065 1066 Howes, et. al. Standards Track [Page 19] 1067 1068 RFC 2425 MIME Content-Type for Directory Information September 1998 1069 1070 1071 8.3. Example 3 1072 1073 The next example illustrates the use of multi-valued type parameters, 1074 the "language" type parameter, the "value" type parameter, folding of 1075 long lines, the \n encoding for formatted lines, attribute grouping, 1076 and the inline "b" encoding. A "vCard" profile [MIME-VCARD] is used 1077 for the example. 1078 1079 Content-Type: text/directory; profile="vcard"; charset=iso-8859-1 1080 Content-ID: <id3@host.com> 1081 Content-Transfer-Encoding: Quoted-Printable 1082 1083 begin:vcard 1084 source:ldap://cn=Meister%20Berger,o=Universitaet%20Goerlitz,c=DE 1085 name:Meister Berger 1086 fn:Meister Berger 1087 n:Berger;Meister 1088 bday;value=date:1963-09-21 1089 o:Universit=E6t G=F6rlitz 1090 title:Mayor 1091 title;language=de;value=text:Burgermeister 1092 note:The Mayor of the great city of 1093 Goerlitz in the great country of Germany. 1094 email;internet:mb@goerlitz.de 1095 home.tel;type=fax,voice,msg:+49 3581 123456 1096 home.label:Hufenshlagel 1234\n 1097 02828 Goerlitz\n 1098 Deutschland 1099 key;type=X509;encoding=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQ 1100 AwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zI 1101 ENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQD 1102 ExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNjE5NDc1OVoXDTk3MTIwMzE5NDc 1103 1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYDVQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW 1104 9ucyBDb3JwLjEYMBYGA1UEAxMPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBF 1105 hJob3dlc0BuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqG 1106 SIb3DQEBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2dXc 1107 oX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MBEGCWCGSAGG+E 1108 IBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9 1109 w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIPmx93HGp0Kgyx1jIVMyNgsemeAwBM+M 1110 SlhMfcpbTrONwNjZYW8vJDSoi//yrZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8V 1111 UMk1U7jt8LYpo4YULU7UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ== 1112 end:vcard 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 Howes, et. al. Standards Track [Page 20] 1123 1124 RFC 2425 MIME Content-Type for Directory Information September 1998 1125 1126 1127 8.4. Example 4 1128 1129 The final example illustrates the use of the multipart/related 1130 Content-Type to include non-textual directory data via the "uri" 1131 encoding to refer to other body parts within the same message, or to 1132 external values. Note that no "profile" parameter is given, so an 1133 application may not know what kind of directory entity the 1134 information applies to. Note also the use of both hypothetical 1135 official and bilaterally agreed upon types. 1136 1137 Content-Type: multipart/related; 1138 boundary=woof; 1139 type="text/directory"; 1140 start="<id5@host.com>" 1141 Content-ID: <id4@host.com> 1142 1143 --woof 1144 Content-Type: text/directory; charset="iso-8859-1" 1145 Content-ID: <id5@host.com> 1146 Content-Transfer-Encoding: Quoted-Printable 1147 1148 source:ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US 1149 cn:Bj=F8rn Jensen 1150 sn:Jensen 1151 email:bjorn@umich.edu 1152 image;value=uri:cid:id6@host.com 1153 image;value=uri;format=jpeg:ftp://some.host/some/path.jpg 1154 sound;value=uri:cid:id7@host.com 1155 phone:+1 313 747-4454 1156 1157 --woof 1158 Content-Type: image/jpeg 1159 Content-ID: <id6@host.com> 1160 1161 <...image data...> 1162 1163 --woof 1164 Content-Type: message/external-body; 1165 name="myvoice.au"; 1166 site="myhost.com"; 1167 access-type=ANON-FTP; 1168 directory="pub/myname"; 1169 mode="image" 1170 1171 Content-Type: audio/basic 1172 Content-ID: <id7@host.com> 1173 1174 --woof-- 1175 1176 1177 1178 Howes, et. al. Standards Track [Page 21] 1179 1180 RFC 2425 MIME Content-Type for Directory Information September 1998 1181 1182 1183 9. Registration of new profiles 1184 1185 This section defines procedures by which new profiles are registered 1186 with the IANA and made available to the Internet community. Note that 1187 non-IANA profiles can be used by bilateral agreement, provided the 1188 associated profile names follow the "X-" convention defined above. 1189 1190 The procedures defined here are designed to allow public comment and 1191 review of new profiles, while posing only a small impediment to the 1192 definition of new profiles. 1193 1194 Registration of a new profile is accomplished by the following steps. 1195 1196 9.1. Define the profile 1197 1198 A profile is defined by completing the following template. 1199 1200 To: ietf-mime-direct@imc.org 1201 Subject: Registration of text/directory MIME profile XXX 1202 1203 Profile name: 1204 1205 Profile purpose: 1206 1207 Profile types: 1208 1209 Profile special notes (optional): 1210 1211 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1212 1213 The explanation of what goes in each field in the template follows. 1214 1215 Profile name: The name of the profile as it will appear in the 1216 text/directory MIME Content-Type "profile" header parameter, or the 1217 predefined "profile" type name. 1218 1219 Profile purpose: The purpose of the profile (e.g., to represent 1220 information about people, printers, documents, etc.). Give a short 1221 but clear description. 1222 1223 Profile types: The list of types associated with the profile. This 1224 list of types is to be expected but not required in the profile, 1225 unless otherwise noted in the profile definition. Other types not 1226 mentioned in the profile definition MAY also be present. Note that 1227 any new types referenced by the profile MUST be defined separately as 1228 described in Section 10. 1229 1230 1231 1232 1233 1234 Howes, et. al. Standards Track [Page 22] 1235 1236 RFC 2425 MIME Content-Type for Directory Information September 1998 1237 1238 1239 Profile special notes: Any special notes about the profile, how it is 1240 to be used, etc. This section of the template can also be used to 1241 define an ordering on the types that appear in the Content-Type, if 1242 such an ordering is required. 1243 1244 9.2. Post the profile definition 1245 1246 The profile description must be posted to the new profile discussion 1247 list, ietf-mime-direct@imc.org 1248 1249 9.3. Allow a comment period 1250 1251 Discussion on the new profile must be allowed to take place on the 1252 list for a minimum of two weeks. Consensus must be reached on the 1253 profile before proceeding to step 4. 1254 1255 9.4. Submit the profile for approval 1256 1257 Once the two-week comment period has elapsed, and the proposer is 1258 convinced consensus has been reached on the profile, the registration 1259 application should be submitted to the Profile Reviewer for approval. 1260 The Profile Reviewer is appointed by the Application Area Directors 1261 and can either accept or reject the profile registration. An accepted 1262 registration is passed on by the Profile Reviewer to the IANA for 1263 inclusion in the official IANA profile registry. The registration may 1264 be rejected for any of the following reasons. 1) Insufficient comment 1265 period; 2) Consensus not reached; 3) Technical deficiencies raised on 1266 the list or elsewhere have not been addressed. The Profile Reviewer's 1267 decision to reject a profile can be appealed by the proposer to the 1268 IESG, or the objections raised can be addressed by the proposer and 1269 the profile resubmitted. 1270 1271 10. Profile Change Control 1272 1273 Existing profiles can be changed using the same process by which they 1274 were registered. 1275 1276 Define the change 1277 1278 Post the change 1279 1280 Allow a comment period 1281 1282 Submit the changed profile for approval 1283 1284 1285 1286 1287 1288 1289 1290 Howes, et. al. Standards Track [Page 23] 1291 1292 RFC 2425 MIME Content-Type for Directory Information September 1998 1293 1294 1295 Note that the original author or any other interested party can 1296 propose a change to an existing profile, but that such changes should 1297 only be proposed when there are serious omissions or errors in the 1298 published specification. The Profile Reviewer can object to a change 1299 if it is not backwards compatible, but is not required to do so. 1300 1301 Profile definitions can never be deleted from the IANA registry, but 1302 profiles which are no longer believed to be useful can be declared 1303 OBSOLETE by a change to their "intended use" field. 1304 1305 11. Registration of new types 1306 1307 This section defines procedures by which new types are registered 1308 with the IANA. Note that non-IANA types can be used by bilateral 1309 agreement, provided the associated types names follow the "X-" 1310 convention defined above. 1311 1312 The procedures defined here are designed to allow public comment and 1313 review of new types, while posing only a small impediment to the 1314 definition of new types. 1315 1316 Registration of a new type is accomplished by the following steps. 1317 1318 11.1. Define the type 1319 1320 A type is defined by completing the following template. 1321 1322 To: ietf-mime-direct@imc.org 1323 Subject: Registration of text/directory MIME type XXX 1324 1325 Type name: 1326 1327 Type purpose: 1328 1329 Type encoding: 1330 1331 Type valuetype: 1332 1333 Type special notes (optional): 1334 1335 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1336 1337 The meaning of each field in the template is as follows. 1338 1339 Type name: The name of the type, as it will appear in the body of an 1340 text/directory MIME Content-Type "type: value" line to the left of 1341 the colon ":". 1342 1343 1344 1345 1346 Howes, et. al. Standards Track [Page 24] 1347 1348 RFC 2425 MIME Content-Type for Directory Information September 1998 1349 1350 1351 Type purpose: The purpose of the type (e.g., to represent a name, 1352 postal address, IP address, etc.). Give a short but clear 1353 description. 1354 1355 Type encoding: The default encoding a value of the type must have in 1356 the body of a text/directory MIME Content-Type. 1357 1358 Type valuetype: The format a value of the type must have in the body 1359 of a text/directory MIME Content-Type. This description must be 1360 precise and must not violate the general encoding rules defined in 1361 section 5 of this document. 1362 1363 Type special notes: Any special notes about the type, how it is to be 1364 used, etc. 1365 1366 11.2. Post the type definition 1367 1368 The type description must be posted to the new type discussion list, 1369 ietf-mime-direct@imc.org 1370 1371 11.3. Allow a comment period 1372 1373 Discussion on the new type must be allowed to take place on the list 1374 for a minimum of two weeks. Consensus must be reached on the type 1375 before proceeding to step 4. 1376 1377 11.4. Submit the type for approval 1378 1379 Once the two-week comment period has elapsed, and the proposer is 1380 convinced consensus has been reached on the type, the registration 1381 application should be submitted to the Profile Reviewer for approval. 1382 The Profile Reviewer is appointed by the Application Area Directors 1383 and can either accept or reject the type registration. An accepted 1384 registration is passed on by the Profile Reviewer to the IANA for 1385 inclusion in the official IANA profile registry. The registration can 1386 be rejected for any of the following reasons. 1) Insufficient comment 1387 period; 2) Consensus not reached; 3) Technical deficiencies raised on 1388 the list or elsewhere have not been addressed. The Profile 1389 Reviewer's decision to reject a type can be appealed by the proposer 1390 to the IESG, or the objections raised can be addressed by the 1391 proposer and the type resubmitted. 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 Howes, et. al. Standards Track [Page 25] 1403 1404 RFC 2425 MIME Content-Type for Directory Information September 1998 1405 1406 1407 12. Type Change Control 1408 1409 Existing types can be changed using the same process by which they 1410 were registered. 1411 1412 Define the change 1413 1414 Post the change 1415 1416 Allow a comment period 1417 1418 Submit the type for approval 1419 1420 Note that the original author or any other interested party can 1421 propose a change to an existing type, but that such changes should 1422 only be proposed when there are serious omissions or errors in the 1423 published specification. The Profile Reviewer can object to a change 1424 if it is not backwards compatible, but is not required to do so. 1425 1426 Type definitions can never be deleted from the IANA registry, but 1427 types which are nolonger believed to be useful can be declared 1428 OBSOLETE by a change to their "intended use" field. 1429 1430 13. Registration of new parameters 1431 1432 This section defines procedures by which new parameters are 1433 registered with the IANA and made available to the Internet 1434 community. Note that non-IANA parameters can be used by bilateral 1435 agreement, provided the associated parameters names follow the "X-" 1436 convention defined above. 1437 1438 The procedures defined here are designed to allow public comment and 1439 review of new parameters, while posing only a small impediment to the 1440 definition of new parameters. 1441 1442 Registration of a new parameter is accomplished by the following 1443 steps. 1444 1445 13.1. Define the parameter 1446 1447 A parameter is defined by completing the following template. 1448 1449 To: ietf-mime-direct@imc.org 1450 Subject: Registration of text/directory MIME type parameter XXX 1451 1452 Parameter name: 1453 1454 Parameter purpose: 1455 1456 1457 1458 Howes, et. al. Standards Track [Page 26] 1459 1460 RFC 2425 MIME Content-Type for Directory Information September 1998 1461 1462 1463 Parameter values: 1464 1465 Parameter special notes (optional): 1466 1467 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1468 1469 The explanation of what goes in each field in the template follows. 1470 1471 Parameter name: The name of the parameter as it will appear in the 1472 text/directory MIME Content-Type. 1473 1474 Parameter purpose: The purpose of the parameter (e.g., to represent 1475 the format of an image, type of a phone number, etc.). Give a short 1476 but clear description. If defining a general paramemter like "format" 1477 or "type" keep in mind that other applications might wish to extend 1478 its use. 1479 1480 Parameter values: The list or description of values associated with 1481 the parameter. 1482 1483 Parameter special notes: Any special notes about the parameter, how 1484 it is to be used, etc. 1485 1486 13.2. Post the parameter definition 1487 1488 The parameter description must be posted to the new parameter 1489 discussion list, ietf-mime-direct@imc.org 1490 1491 13.3. Allow a comment period 1492 1493 Discussion on the new parameter must be allowed to take place on the 1494 list for a minimum of two weeks. Consensus must be reached on the 1495 parameter before proceeding to step 4. 1496 1497 13.4. Submit the parameter for approval 1498 1499 Once the two-week comment period has elapsed, and the proposer is 1500 convinced consensus has been reached on the parameter, the 1501 registration application should be submitted to the Profile Reviewer 1502 for approval. The Profile Reviewer is appointed by the Application 1503 Area Directors and can either accept or reject the parameter 1504 registration. An accepted registration is passed on by the Profile 1505 Reviewer to the IANA for inclusion in the official IANA parameter 1506 registry. The registration can be rejected for any of the following 1507 reasons. 1) Insufficient comment period; 2) Consensus not reached; 3) 1508 Technical deficiencies raised on the list or elsewhere have not been 1509 addressed. The Profile Reviewer's decision to reject a profile can be 1510 appealed by the proposer to the IESG, or the objections raised can be 1511 1512 1513 1514 Howes, et. al. Standards Track [Page 27] 1515 1516 RFC 2425 MIME Content-Type for Directory Information September 1998 1517 1518 1519 addressed by the proposer and the parameter registration resubmitted. 1520 1521 14. Parameter Change Control 1522 1523 Existing parameters can be changed using the same process by which 1524 they were registered. 1525 1526 Define the change 1527 1528 Post the change 1529 1530 Allow a comment period 1531 1532 Submit the parameter for approval 1533 1534 Note that the original author or any other interested party can 1535 propose a change to an existing parameter, but that such changes 1536 should only be proposed when there are serious omissions or errors in 1537 the published specification. The Profile Reviewer can object to a 1538 change if it is not backwards compatible, but is not required to do 1539 so. 1540 1541 Parameter definitions can never be deleted from the IANA registry, 1542 but parameters which are nolonger believed to be useful can be 1543 declared OBSOLETE by a change to their "intended use" field. 1544 1545 15. Registration of new value types 1546 1547 This section defines procedures by which new value types are 1548 registered with the IANA and made available to the Internet 1549 community. Note that non-IANA value types can be used by bilateral 1550 agreement, provided the associated value types names follow the "X-" 1551 convention defined above. 1552 1553 The procedures defined here are designed to allow public comment and 1554 review of new value types, while posing only a small impediment to 1555 the definition of new value types. 1556 1557 Registration of a new value types is accomplished by the following 1558 steps. 1559 1560 15.1. Define the value type 1561 1562 A value type is defined by completing the following template. 1563 1564 To: ietf-mime-direct@imc.org 1565 Subject: Registration of text/directory MIME value type XXX 1566 1567 1568 1569 1570 Howes, et. al. Standards Track [Page 28] 1571 1572 RFC 2425 MIME Content-Type for Directory Information September 1998 1573 1574 1575 value type name: 1576 1577 value type purpose: 1578 1579 value type format: 1580 1581 value type special notes (optional): 1582 1583 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 1584 1585 The explanation of what goes in each field in the template follows. 1586 1587 value type name: The name of the value type as it will appear in the 1588 text/directory MIME Content-Type. 1589 1590 value type purpose: The purpose of the value type. Give a short but 1591 clear description. 1592 1593 value type format: The definition of the format for the value, 1594 usually using ABNF grammar. 1595 1596 value type special notes: Any special notes about the value type, how 1597 it is to be used, etc. 1598 1599 15.2. Post the value type definition 1600 1601 The value type description must be posted to the new value type 1602 discussion list, ietf-mime-direct@imc.org 1603 1604 15.3. Allow a comment period 1605 1606 Discussion on the new value type must be allowed to take place on the 1607 list for a minimum of two weeks. Consensus must be reached before 1608 proceeding to step 4. 1609 1610 15.4. Submit the value type for approval 1611 1612 Once the two-week comment period has elapsed, and the proposer is 1613 convinced consensus has been reached on the value type, the 1614 registration application should be submitted to the Profile Reviewer 1615 for approval. The Profile Reviewer is appointed by the Application 1616 Area Directors and can either accept or reject the value type 1617 registration. An accepted registration should be passed on by the 1618 Profile Reviewer to the IANA for inclusion in the official IANA value 1619 type registry. The registration can be rejected for any of the 1620 following reasons. 1) Insufficient comment period; 2) Consensus not 1621 reached; 3) Technical deficiencies raised on the list or elsewhere 1622 have not been addressed. The Profile Reviewer's decision to reject a 1623 1624 1625 1626 Howes, et. al. Standards Track [Page 29] 1627 1628 RFC 2425 MIME Content-Type for Directory Information September 1998 1629 1630 1631 profile can be appealed by the proposer to the IESG, or the 1632 objections raised can be addressed by the proposer and the value type 1633 registration resubmitted. 1634 1635 16. Security Considerations 1636 1637 Internet mail is subject to many well known security attacks, 1638 including monitoring, replay, and forgery. Care should be taken by 1639 any directory service in allowing information to leave the scope of 1640 the service itself, where any access controls can no longer be 1641 guaranteed. Applications should also take care to display directory 1642 data in a "safe" environment (e.g., PostScript-valued types). 1643 1644 17. Acknowledgements 1645 1646 The registration procedures defined here were shamelessly lifted from 1647 the MIME registration RFC. 1648 1649 The many valuable comments contributed by members of the IETF ASID 1650 working group are gratefully acknowledged, as are the contributions 1651 of the Versit Consortium. Chris Newman was especially helpful in 1652 navigating the intricacies of ABNF lore. 1653 1654 18. References 1655 1656 [RFC-1777] Yeong, W., Howes, T., and S. Kille, "Lightweight 1657 Directory Access Protocol", RFC 1777, March 1995. 1658 1659 [RFC-1778] Howes, T., Kille, S., Yeong, W., and C. Robbins, "The 1660 String Representation of Standard Attribute Syntaxes", 1661 RFC 1778, March 1995. 1662 1663 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet 1664 Text Messages", STD 11, RFC 822, August 1982. 1665 1666 [RFC-2045] Borenstein, N., and N. Freed, "Multipurpose Internet 1667 Mail Extensions (MIME) Part One: Format of Internet 1668 Message Bodies", RFC 2045, November 1996. 1669 1670 [RFC-2046] Moore, K., "Multipurpose Internet Mail Extensions (MIME) 1671 Part Two: Media Types", RFC 2046, November 1996. 1672 1673 [RFC-2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 1674 Internet Mail Extensions (MIME) Part Four: Registration 1675 Procedures", RFC 2048, November 1996. 1676 1677 [RFC-1766] Alvestrand, H., "Tags for the Identification of 1678 Languages", RFC 1766, March 1995. 1679 1680 1681 1682 Howes, et. al. Standards Track [Page 30] 1683 1684 RFC 2425 MIME Content-Type for Directory Information September 1998 1685 1686 1687 [RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type", 1688 RFC 2112, March 1997. 1689 1690 [X500] "Information Processing Systems - Open Systems 1691 Interconnection - The Directory: Overview of Concepts, 1692 Models and Services", ISO/IEC JTC 1/SC21, International 1693 Standard 9594-1, 1988. 1694 1695 [RFC-1835] Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider, 1696 "Architecture of the WHOIS++ service", RFC 1835, August 1697 1995. 1698 1699 [RFC-1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 1700 Resource Locators (URL)", RFC 1738, December 1994. 1701 1702 [MIME-VCARD] Dawson, F., and T. Howes, "VCard MIME Directory 1703 Profile", RFC 2426, September 1998. 1704 1705 [VCARD] Internet Mail Consortium, "vCard - The Electronic 1706 Business Card", Version 2.1, 1707 http://www.imc.com/pdi/vcard-21.txt, September, 1996. 1708 1709 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1710 Requirement Levels", BCP 14, RFC 2119, March 1997. 1711 1712 [RFC-2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 1713 Specifications: ABNF", RFC 2234, November 1997. 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 Howes, et. al. Standards Track [Page 31] 1739 1740 RFC 2425 MIME Content-Type for Directory Information September 1998 1741 1742 1743 19. Authors' Addresses 1744 1745 Tim Howes 1746 Netscape Communications Corp. 1747 501 East Middlefield Rd. 1748 Mountain View, CA 94041 1749 USA 1750 1751 Phone: +1.415.937.3419 1752 EMail: howes@netscape.com 1753 1754 1755 Mark Smith 1756 Netscape Communications Corp. 1757 501 East Middlefield Rd. 1758 Mountain View, CA 94041 1759 USA 1760 1761 Phone: +1.415.937.3477 1762 EMail: mcs@netscape.com 1763 1764 1765 Frank Dawson 1766 Lotus Development Corporation 1767 6544 Battleford Drive 1768 Raleigh, NC 27613 1769 USA 1770 1771 Phone: +1-919-676-9515 1772 EMail: frank_dawson@lotus.com 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 Howes, et. al. Standards Track [Page 32] 1795 1796 RFC 2425 MIME Content-Type for Directory Information September 1998 1797 1798 1799 20. Full Copyright Statement 1800 1801 Copyright (C) The Internet Society (1998). All Rights Reserved. 1802 1803 This document and translations of it may be copied and furnished to 1804 others, and derivative works that comment on or otherwise explain it 1805 or assist in its implementation may be prepared, copied, published 1806 and distributed, in whole or in part, without restriction of any 1807 kind, provided that the above copyright notice and this paragraph are 1808 included on all such copies and derivative works. However, this 1809 document itself may not be modified in any way, such as by removing 1810 the copyright notice or references to the Internet Society or other 1811 Internet organizations, except as needed for the purpose of 1812 developing Internet standards in which case the procedures for 1813 copyrights defined in the Internet Standards process must be 1814 followed, or as required to translate it into languages other than 1815 English. 1816 1817 The limited permissions granted above are perpetual and will not be 1818 revoked by the Internet Society or its successors or assigns. 1819 1820 This document and the information contained herein is provided on an 1821 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1822 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1823 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1824 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1825 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 Howes, et. al. Standards Track [Page 33] 1851