idnits 2.17.1 draft-ietf-asid-mime-direct-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 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.) ** There are 232 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 7 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '...fts are worki...' == Line 11 has weird spacing: '...ments of the ...' == Line 12 has weird spacing: '...t other group...' == Line 16 has weird spacing: '...and may be ...' == Line 20 has weird spacing: '...atus of any ...' == (227 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC-1521' on line 912 looks like a reference -- Missing reference section? 'RFC-1522' on line 917 looks like a reference -- Missing reference section? 'HTTP' on line 949 looks like a reference -- Missing reference section? 'RFC-1835' on line 939 looks like a reference -- Missing reference section? 'RFC-1872' on line 927 looks like a reference -- Missing reference section? 'MIME-REG' on line 930 looks like a reference -- Missing reference section? 'RFC-1766' on line 924 looks like a reference -- Missing reference section? 'RFC-1848' on line 921 looks like a reference -- Missing reference section? 'RFC-1738' on line 942 looks like a reference -- Missing reference section? 'RFC-1777' on line 900 looks like a reference -- Missing reference section? 'RFC-1778' on line 905 looks like a reference -- Missing reference section? 'RFC-822' on line 909 looks like a reference -- Missing reference section? 'MIME-WPP' on line 945 looks like a reference -- Missing reference section? 'VERSIT' on line 955 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tim Howes 3 INTERNET-DRAFT Mark Smith 4 draft-ietf-asid-mime-direct-02.txt Netscape Communications Corp. 6 A MIME Content-Type for Directory Information 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working docu- 11 ments of the Internet Engineering Task Force (IETF), its areas, and its 12 working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference material 18 or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 2. Abstract 28 This document defines a MIME Content-Type for holding directory informa- 29 tion. The definition is independent of any particular directory ser- 30 vice. The application/directory Content-Type is defined for holding a 31 variety of directory information, for example, name, or email address. 32 The application/directory Content-Type can also be used as the root body 33 part in a multipart/related Content-Type for handling more complicated 34 situations, especially those in which non-textual information that 35 already has a natural MIME representation, for example, a photograph or 36 sound, must be represented. 38 The application/directory Content-Type defines a general framework and 39 format for holding directory information in a simple "type: value" for- 40 mat. This format is compatible with the Versit Electronic Business Card 41 Specification text encoding. Mechanisms are defined to specify alter- 42 nate character sets, languages, encodings and other meta-information. 43 This document also defines the procedure by which particular formats, 44 called profiles, for carrying application-specific information within an 45 application/directory Content-Type may be defined and registered, and 46 the conventions such formats must follow. It is expected that other 47 Expires in six months INTERNET DRAFT 49 documents will be produced that define such formats for various applica- 50 tions (e.g., white pages). 52 3. Need for a MIME Directory Type 54 For purposes of this document, a directory is a special-purpose database 55 that contains typed information. A directory usually supports both read 56 and search of the information it contains, and may support modification 57 of the information as well. Directory information is usually accessed 58 far more often than it is updated. Directories may be local or global 59 in scope. They may be distributed or centralized. The information they 60 contain may be replicated, with weak or strong consistency requirements. 62 There are several situations in which users of Internet mail may wish to 63 exchange directory information: the email analogy of a "business card" 64 exchange; the conveyance of directory information to a user having only 65 email access to the Internet; the provision of machine-parseable address 66 information when purchasing goods or services over the Internet; etc. As 67 MIME [RFC-1521,RFC-1522] is used increasingly by other protocols, most 68 notably HTTP [HTTP], it may also be useful for these protocols to be 69 able to carry directory information in MIME format. Such a format, for 70 example, could be used to represent URC (uniform resource characteris- 71 tics) information about resources on the World Wide Web, or to provide 72 general directory service over HTTP. 74 4. Overview 76 The scheme defined here for representing directory information in a MIME 77 Content-Type has two parts. First, the application/directory Content- 78 Type is defined for use in holding directory information within a single 79 body part, for example name, title, or email address. In its simplest 80 form, the format uses a "type: value" approach, which should be easily 81 parsable by existing MIME implementations and understandable by users. 82 More complicated situations can be represented also. This document 83 defines the general form the information in the Content-Type should 84 have, and the procedure by which specific types and values (properties) 85 for particular applications may be defined. The framework is general 86 enough to handle information from any number of end directory services, 87 including LDAP [RFC-1777, RFC-1778], WHOIS++ [RFC-1835], and X.500 88 [x500]. 90 Directory entries can include far more than just textual information. 91 Some such information (e.g., an image or sound) overlaps with predefined 92 MIME Content-Types. In these cases it may be desirable to include the 93 information in its well-known MIME format. This situation is handled by 94 using a multipart/related Content-Type as defined in [RFC-1872]. The 95 root component of this type is an application/directory body part speci- 96 fying any textual information in-line, and for information contained in 97 Expires in six months INTERNET DRAFT 99 other Content-Types, the Content-IDs (in URL form) of those types. 101 In some applications, it may be useful to include a pointer (e.g, a URL) 102 to some directory information rather than the information itself. This 103 document defines a general mechanism for accomplishing this. 105 5. The application/directory Content-Type 107 The application/directory Content-Type is used to hold basic directory 108 information, URLs referencing other information, including other MIME 109 body parts holding supplementary or non-textual directory information, 110 such as an image or sound. It is defined as follows, using the MIME 111 media type registration template from [MIME-REG]. 113 To: ietf-types@uninett.no 114 Subject: Registration of MIME media type application/directory 116 MIME media type name: application 118 MIME subtype name: directory 120 Required parameters: none 122 Optional parameters: charset, language, profile 124 The "charset" parameter is as defined in [RFC-1521] for other body 125 parts. It is used to identify the default character set used within 126 the body part. Note that alternate character sets can be specified on 127 a per-value basis using the "charset" type parameter described below. 129 The "language" parameter is used to identify the default language for 130 information contained within the body part. Its value is a language 131 tag as defined in Section 2 of [RFC-1766]. Note that alternate 132 languages can be specified on a per-value basis using the "language" 133 type parameter, defined below. 135 The "profile" parameter is used to convey the type(s) of entity(ies) 136 to which the directory information pertains and the likely set of 137 information associated with the entity(ies). It is intended only as a 138 guide to applications interpreting the information contained within 139 the body part. It should not be used to exclude or require particular 140 pieces of information unless a profile definition specifically calls 141 for this behavior. The value of the "profile" parameter is defined 142 as follows. Note that profile names are case insensitive (i.e., the 143 profile name "Person" is the same as "PERSON" and "person" and "peR- 144 sOn"). 146 profile := x-token / iana-token 148 Expires in six months INTERNET DRAFT 150 x-token := 154 iana-token := 158 Encoding considerations: 160 As specified by the Content-Transfer-Encoding header field. Note that 161 each value may also have an inline encoding associated with it. This 162 encoding is independent of the encoding for the body part as a whole 163 (i.e., inline encodings are performed first, then Content-Transfer- 164 Encoding is applied to the entire body part). 166 Security considerations: 168 Directory information may be public or it may be protected from unau- 169 thorized access by the directory service in which it resides. Once 170 the information leaves its native service, there can be no guarantee 171 that the same care will be taken by all services handling the infor- 172 mation. Furthermore, this specification defines no access control 173 mechanism by which information may be protected, or by which access 174 control information may be conveyed. Note that the integrity and 175 privacy of an application/directory body part may be protected by 176 enclosing it within a MOSS [RFC-1848] body part, or equivalent 177 method. 179 Interoperability considerations: 181 In order to make sense of directory information, applications must 182 share a common understanding of the types of information contained 183 within the Content-Type (the directory schema). This schema informa- 184 tion is not defined in this document, but rather in companion docu- 185 ments that follow the requirements specified in this document, or in 186 bilateral agreements. 188 Published specification: 190 The application/directory Content-Type contains directory informa- 191 tion, typically pertaining to a single directory entity or group of 192 entities. The content consists of one or more CRLF-separated lines 193 in the following format. Using the notation of RFC 822, the syntax 194 for this content is: 196 contentline := [[group.]type] [";" parameterlist] ":" valuespec 198 Expires in six months INTERNET DRAFT 200 group := atom ; as defined in Section 3.3 of RFC 822 202 type := x-name 203 / iana-type 205 x-name := 208 iana-type := 212 parameterlist := parameter / parameterlist ";" parameter 214 parameter := encodingparm 215 / valuetypeparm ; not present => inline value 216 / charsetparm 217 / languageparm 218 / protoparm 219 / [parmtype "="] parmvalues 221 encodingparm := "encoding" "=" encodingtype 223 encodingtype := "base64" ; from Section 5.2 of RFC 1521 224 / "quoted-printable" ; from Section 5.1 of RFC 1521 226 valuetypeparm := "value" "=" valuetype 228 valuetype := "url" ; genericurl from RFC 1735 230 charsetparm := "charset" "=" charset ; from Section 7.1 of RFC 1521 232 languageparm := "language" "=" language ; as defined in RFC 1766 234 protoparm := "proto" "=" protocol ; as defined in assigned numbers 236 parmtype := x-name 237 / iana-parmtype 239 iana-parmtype := 243 parmvalues := parmvalue 244 / parmvalues "," parmvalue 246 parmvalue := x-name 247 / iana-parmvalue 249 Expires in six months INTERNET DRAFT 251 iana-parmvalue := 255 value := *text ; Characters whose syntax depends on type and the 256 ; the encoding parameter. If the value contains 257 ; a or character (ASCII 10 or 13), it must 258 ; be encoded using either base64 or quoted-printable. 260 To the left of the beginning of "value", white space characters 261 (namely HTABs and SPACEs, ASCII 9 and 32) may freely surround any 262 symbol. Note that this means that if a "value" begins with white 263 space, it must be encoded using either the base64 or quoted-printable 264 methods. 266 Note that the meanings of the various type names and the format of 267 the corresponding values must be defined as specified in Section 9. 268 Specifications may impose ordering on the type constructs within a 269 body part, though none is required by default. The various x-name 270 constructs are used for bilaterally-agreed upon type names, parameter 271 names and parameter values. 273 Type names, parameter names, and parameter values (i.e., everything 274 to the left of the ":") are case insensitive (e.g., the type name 275 "cn" is the same as "CN" and "Cn"). 277 The group construct is used to group related attributes together. 278 The group name is a syntactic convention used to indicate that all 279 type names prefaced with the same group name should be grouped 280 together when displayed by an application. It has no other signifi- 281 cance. Implementations that do not understand or support grouping 282 may simply strip off any text before a "." and present the types and 283 values as normal. 285 The "charset" type parameter should be used to identify character 286 sets other than US ASCII. The "charset" header parameter can be used 287 to set the default character set for the entire body part. The "char- 288 set" type parameter can be used to change the default character set 289 on a per-value basis. 291 The "language" type parameter should be used to identify data in 292 alternate languages. Note that there is no concept of "default" 293 language, except as specified by the "language" header parameter. The 294 value of the "language" type parameter is a language tag as defined 295 in Section 2 of [RFC-1766]. 297 The "proto" type parameter should be used to identify a protocol used 298 in interpreting the value. This is used, for example, in the "name" 300 Expires in six months INTERNET DRAFT 302 type, defined below. 304 The "encoding" type parameter should be used to specify an alternate 305 encoding for a value. If the value contains a or character 306 (ASCII 10 or 13), it must be encoded using either "base64" or 307 "quoted-printable". These encodings can also be useful for binary 308 values that are mixed with other text information in the body part 309 (e.g., a certificate). Using a per-value "base64" or "quoted- 310 printable" encoding in this case leaves the other information in a 311 more readable form. 313 The Content-Transfer-Encoding header field is used to specify the 314 encoding used for the body part as a whole. The "encoding" type 315 parameter is used to specify an encoding for a particular value 316 (e.g., a certificate). In this case, the Content-Transfer-Encoding 317 header might specify "7-bit", while the one certificate value might 318 specify an encoding of base64 via an "encoding=base64" type parame- 319 ter. 321 The "value" type parameter should be used to identify values that are 322 referenced by a URL (including a Content-ID URL) instead of encoded 323 in-line. These value references might be used if the value is too 324 large, unavailable, or otherwise undesirable to include directly. In 325 this case, a value type of "url" might be appropriate. 327 Person & email address to contact for further information: 329 Tim Howes 330 Netscape Communications Corp. 331 501 East Middlefield Rd. 332 Mountain View, CA 94041 333 USA 334 howes@netscape.com 335 +1.415.937.3419 337 Intended usage: COMMON 339 Author/Change controller: 341 Tim Howes 342 Netscape Communications Corp. 343 501 East Middlefield Rd. 344 Mountain View, CA 94041 345 USA 346 howes@netscape.com 347 +1.415.937.3419 349 Mark Smith 351 Expires in six months INTERNET DRAFT 353 Netscape Communications Corp. 354 501 East Middlefield Rd. 355 Mountain View, CA 94041 356 USA 357 mcs@netscape.com 358 +1.415.937.3477 360 6. Predefined Types 362 The following types are generally useful regardless of the profile being 363 carried, and are defined below, using the application/directory MIME 364 type registration template defined in Section 11.1 of this document. 365 These types may be included in any profile. 367 6.1. SOURCE Type Definition 369 To: ietf-mime-direct@umich.edu 370 Subject: Registration of application/directory MIME type SOURCE 372 Type name: SOURCE 374 Type purpose: To identify the source of directory information con- 375 tained in the content type. 377 Type encoding: A URL as defined in [RFC-1738]. 379 Type special notes: The SOURCE type is used to provide the means by 380 which applications knowledgable in the given directory service proto- 381 col may obtain additional or more up-to-date information from the 382 directory service. It contains a URL as defined in [RFC-1738] point- 383 ing to the directory entity or entities to which the information per- 384 tains. When directory information is available from more than one 385 source, the sending entity may pick what it considers to be the best 386 source, or multiple SOURCE types may be included. 388 Type example: 389 SOURCE: ldap://ldap.host/cn=Babs%20Jensen,%20o=Babsco,%20c=US 391 6.2. NAME Type Definition 393 To: ietf-mime-direct@umich.edu 394 Subject: Registration of application/directory MIME type NAME 396 Type name: NAME 398 Type purpose: To identify the name of the directory entity to which 399 information in the content type pertains. 401 Expires in six months INTERNET DRAFT 403 Type encoding: A protocol-specific directory name. 405 Type special notes: The NAME parameter is used to convey the direc- 406 tory name of the entity to which the directory information pertains. 407 Its value depends on the setting of the "PROTO" type parameter, which 408 indicates the directory service protocol context in which the value 409 of the NAME parameter should be interpreted. Note that this value is 410 protocol-specific and is intended for applications knowledgable in a 411 particular directory service protocol. 413 Type example: 414 NAME;PROTO=LDAP: cn=Babs Jensen, o=Babsco, c=US 416 6.3. PROFILE Type Definition 418 To: ietf-mime-direct@umich.edu 419 Subject: Registration of application/directory MIME type PROFILE 421 Type name: PROFILE 423 Type purpose: To identify the type of directory entity to which 424 information in the content type pertains. 426 Type encoding: A profile name, registered as described in Section 9 427 of this document or bilaterally-agreed upon as described in Section 428 5. 430 Type special notes: The PROFILE parameter is used to convey the type 431 of the entity to which the directory information in the rest of the 432 body part pertains. It should be the same as the "profile" header 433 parameter, if present. 435 Type example: 436 PROFILE: person 438 7. Use of the multipart/related Content-Type 440 The multipart/related Content-Type can be used to hold directory infor- 441 mation comprised of both text and non-text information or directory 442 information that already has a natural MIME representation. The root 443 body part within the multipart/related body part is specified as defined 444 in [RFC-1872] by a "start" parameter, or it is the first body part in 445 the absence of such a parameter. The root body part must have a 446 Content-Type of "application/directory". This part holds inline infor- 447 mation, optionally defines the name and source of the information, and 448 makes reference to subsequent body parts holding additional text or 449 non-text directory information via their Content-ID URLs as explained in 450 Expires in six months INTERNET DRAFT 452 Section 5. 454 The body parts referred to do not have to be in any particular order, 455 except as noted above for the root body part. 457 8. Examples 459 The following examples are for illustrative purposes only and are not 460 part of the definition. The first example illustrates simple use of the 461 application/directory Content-Type. Note that no "profile" parameter is 462 given, so an application may not know what kind of directory entity the 463 information applies to. Note also the use of both hypothetical official 464 and bilaterally agreed upon types. 466 From: Whomever 467 To: Someone 468 Subject: whatever 469 MIME-Version: 1.0 470 Message-ID: 471 Content-Type: application/directory 472 Content-ID: 474 cn: Babs Jensen 475 cn: Barbara J Jensen 476 sn: Jensen 477 email: babs@umich.edu 478 phone: +1 313 747-4454 479 x-id: 1234567890 481 The next example illustrates the use of the Quoted-Printable encoding 482 defined in [RFC-1521] to include non-ASCII characters in some of the 483 information returned, and the use of the optional "name" and "source" 484 types. It also illustrates the use of an "encoding" type parameter to 485 encode a certificate value in base 64. Note the use of the hypothetical 486 "person" profile. 488 Content-Type: application/directory; 489 charset="iso-8859-1"; 490 profile="person" 491 Content-ID: 492 Content-Transfer-Encoding: Quoted-Printable 494 source: ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US 495 name;proto=ldap: cn=Bjorn Jensen, o=University of Michigan, c=US 496 cn: Bj=F8rn Jensen 497 sn: Jensen 498 email: bjorn@umich.edu 499 phone: +1 313 747-4454 501 Expires in six months INTERNET DRAFT 503 certificate;encoding=3Dbase64: dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK 505 The next example illustrates the use of multi-valued type parameters, 506 the "charset" type parameter, the "language" type parameter, inline 507 quoted-printable encoding to represent iso-8859-1 characters and fold 508 long lines, and attribute grouping. 510 Content-Type: application/directory; profile="person" 511 Content-ID: 513 source: ldap://cn=Meister%20Berger,o=Universitaet%20Goerlitz,c=DE 514 name: cn=Meister Berger, o=Universitaet Goerlitz, c=DE 515 cn: Meister Berger 516 cn: Berger Meister 517 sn: Berger 518 o;charset=iso-8859-1;encoding=quoted-printable: Universit=E6t G=F6rlitz 519 title: Mayor 520 title;language=de: Burgermeister 521 description;encoding=quoted-printable: The Mayor of the great city of= 522 Goerlitz in the great country of Germany. 523 email: mb@goerlitz.de 524 home.phone;fax,voice,msg: +49 3581 123456 525 home.addr;encoding=quoted-printable: Hufenshlagel 1234=0A 526 02828 Goerlitz=0A= 527 Deutschland 528 certificate;encoding=base64: dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK 530 The final example illustrates the use of the multipart/related Content- 531 Type to include non-textual directory data via the "url" encoding to 532 refer to other body parts within the same message, or to external 533 values. 535 Content-Type: multipart/related; 536 boundary=woof; 537 type="application/directory"; 538 start="" 539 Content-ID: 541 --woof 542 Content-Type: application/directory; charset="iso-8859-1" 543 Content-ID: 544 Content-Transfer-Encoding: Quoted-Printable 546 source: ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US 547 cn: Bj=F8rn Jensen 548 sn: Jensen 549 email: bjorn@umich.edu 550 image;encoding=url: cid:id6@host.com 552 Expires in six months INTERNET DRAFT 554 image;encoding=url;format=jpeg: ftp://some.host/some.path.jpg 555 sound;encoding=url: cid:id7@host.com 556 phone: +1 313 747-4454 558 --woof 559 Content-Type: image/jpeg 560 Content-ID: 562 <...image data...> 564 --woof 565 Content-Type: message/external-body; 566 name="myvoice.au"; 567 site="myhost.com"; 568 access-type=ANON-FTP; 569 directory="pub/myname"; 570 mode="image" 572 Content-Type: audio/basic 573 Content-ID: 575 --woof-- 577 9. Registration of new profiles 579 This section defines procedures by which new profiles are registered 580 with the IANA and made available to the Internet community. Note that 581 non-IANA profiles may be used by bilateral agreement, provided the asso- 582 ciated profile names follow the "X-" convention defined above. 584 The procedures defined here are designed to allow public comment and 585 review of new profiles, while posing only a small impediment to the 586 definition of new profiles. 588 Registration of a new profile is accomplished by the following steps. 590 9.1. Define the profile 592 A profile is defined by completing the following template. 594 To: ietf-mime-direct@umich.edu 595 Subject: Registration of application/directory MIME profile XXX 597 Profile name: 599 Profile purpose: 601 Profile types: 603 Expires in six months INTERNET DRAFT 605 Profile special notes (optional): 607 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 609 The explanation of what goes in each field in the template follows. 611 Profile name: The name of the profile as it will appear in the 612 application/directory MIME Content-Type "profile" header parameter, or 613 the predefined "profile" type name. 615 Profile purpose: The purpose of the profile (e.g., to represent informa- 616 tion about people, printers, documents, etc.). Give a short but clear 617 description. 619 Profile types: The list of types associated with the profile. This list 620 of types is to be expected but not required in the profile, unless oth- 621 erwise noted in the profile definition. Other types not mentioned in 622 the profile definition may also be present. Note that any new types 623 referenced by the profile must be defined separately as described in 624 Section 10. 626 Profile special notes: Any special notes about the profile, how it is to 627 be used, etc. This section of the template may also be used to define an 628 ordering on the types that appear in the Content-Type, if such an order- 629 ing is required. 631 9.2. Post the profile definition 633 The profile description must be posted to the new profile discussion 634 list, ietf-mime-direct@umich.edu. 636 9.3. Allow a comment period 638 Discussion on the new profile must be allowed to take place on the list 639 for a minimum of two weeks. Consensus must be reached on the profile 640 before proceeding to step 4. 642 9.4. Submit the profile for approval 644 Once the two-week comment period has elapsed, and the proposer is con- 645 vinced consensus has been reached on the profile, the registration 646 application should be submitted to the Profile Reviewer for approval. 647 The Profile Reviewer is appointed to the Application Area Directors and 648 may either accept or reject the profile registration. An accepted regis- 649 tration should be passed on by the Profile Reviewer to the IANA for 650 inclusion in the official IANA profile registry. The registration may be 651 rejected for any of the following reasons. 1) Insufficient comment 652 period; 2) Consensus not reached; 3) Technical deficiencies raised on 653 Expires in six months INTERNET DRAFT 655 the list or elsewhere have not been addressed. The Profile Reviewer's 656 decision to reject a profile may be appealed by the proposer to the 657 IESG, or the objections raised can be addressed by the proposer and the 658 profile resubmitted. 660 10. Profile Change Control 662 Existing profiles may be changed using the same process by which they 663 were registered. 665 Define the change 667 Post the change 669 Allow a comment period 671 Submit the changed profile for approval 673 Note that the original author or any other interested party may propose 674 a change to an existing profile, but that such changes should only be 675 proposed when there are serious omissions or errors in the published 676 specification. The Profile Reviewer may object to a change if it is not 677 backwards compatible, but is not required to do so. 679 Profile definitions can never be deleted from the IANA registry, but 680 profiles which are no longer believed to be useful can be declared 681 OBSOLETE by a change to their "intended use" field. 683 11. Registration of new types 685 This section defines procedures by which new types are registered with 686 the IANA. Note that non-IANA types may be used by bilateral agreement, 687 provided the associated types names follow the "X-" convention defined 688 above. 690 The procedures defined here are designed to allow public comment and 691 review of new types, while posing only a small impediment to the defini- 692 tion of new types. 694 Registration of a new type is accomplished by the following steps. 696 11.1. Define the type 698 A type is defined by completing the following template. 700 To: ietf-mime-direct@umich.edu 701 Subject: Registration of application/directory MIME type XXX 703 Expires in six months INTERNET DRAFT 705 Type name: 707 Type purpose: 709 Type encoding: 711 Type special notes (optional): 713 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 715 The meaning of each field in the template is as follows. 717 Type name: The name of the type, as it will appear in the body of an 718 application/directory MIME Content-Type "type: value" line to the left 719 of the colon ":". 721 Type purpose: The purpose of the type (e.g., to represent a name, postal 722 address, IP address, etc.). Give a short but clear description. 724 Type encoding: The encoding a value of the type must have in the body of 725 an application/directory MIME Content-Type. This description must be 726 precise and must not violate the general encoding rules defined in sec- 727 tion 5 of this document. 729 Type special notes: Any special notes about the type, how it is to be 730 used, etc. 732 11.2. Post the type definition 734 The type description must be posted to the new type discussion list, 735 ietf-mime-direct@umich.edu. 737 11.3. Allow a comment period 739 Discussion on the new type must be allowed to take place on the list for 740 a minimum of two weeks. Consensus must be reached on the type before 741 proceeding to step 4. 743 11.4. Submit the type for approval 745 Once the two-week comment period has elapsed, and the proposer is con- 746 vinced consensus has been reached on the type, the registration applica- 747 tion should be submitted to the Profile Reviewer for approval. The Pro- 748 file Reviewer is appointed to the Application Area Directors and may 749 either accept or reject the type registration. An accepted registration 750 should be passed on by the Profile Reviewer to the IANA for inclusion in 751 the official IANA profile registry. The registration may be rejected for 752 any of the following reasons. 1) Insufficient comment period; 2) 753 Expires in six months INTERNET DRAFT 755 Consensus not reached; 3) Technical deficiencies raised on the list or 756 elsewhere have not been addressed. The Profile Reviewer's decision to 757 reject a type may be appealed by the proposer to the IESG, or the objec- 758 tions raised can be addressed by the proposer and the type resubmitted. 760 12. Type Change Control 762 Existing types may be changed using the same process by which they were 763 registered. 765 Define the change 767 Post the change 769 Allow a comment period 771 Submit the type for approval 773 Note that the original author or any other interested party may propose 774 a change to an existing type, but that such changes should only be pro- 775 posed when there are serious omissions or errors in the published 776 specification. The Profile Reviewer may object to a change if it is not 777 backwards compatible, but is not required to do so. 779 Type definitions can never be deleted from the IANA registry, but types 780 which are nolonger believed to be useful can be declared OBSOLETE by a 781 change to their "intended use" field. 783 13. Registration of new parameters 785 This section defines procedures by which new parameters are registered 786 with the IANA and made available to the Internet community. Note that 787 non-IANA parameters may be used by bilateral agreement, provided the 788 associated parameters names follow the "X-" convention defined above. 790 The procedures defined here are designed to allow public comment and 791 review of new parameters, while posing only a small impediment to the 792 definition of new parameters. 794 Registration of a new parameter is accomplished by the following steps. 796 13.1. Define the parameter 798 A parameter is defined by completing the following template. 800 To: ietf-mime-direct@umich.edu 801 Subject: Registration of application/directory MIME type parameter XXX 803 Expires in six months INTERNET DRAFT 805 Parameter name: 807 Parameter purpose: 809 Parameter values: 811 Parameter special notes (optional): 813 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 815 The explanation of what goes in each field in the template follows. 817 Parameter name: The name of the parameter as it will appear in the 818 application/directory MIME Content-Type. 820 Parameter purpose: The purpose of the parameter (e.g., to represent the 821 format of an image, type of a phone number, etc.). Give a short but 822 clear description. If defining a general paramemter like "format" or 823 "type" keep in mind that other applications may wish to extend its use. 825 Parameter values: The list or description of values associated with the 826 parameter. 828 Parameter special notes: Any special notes about the parameter, how it 829 is to be used, etc. 831 13.2. Post the parameter definition 833 The parameter description must be posted to the new parameter discussion 834 list, ietf-mime-direct@umich.edu. 836 13.3. Allow a comment period 838 Discussion on the new parameter must be allowed to take place on the 839 list for a minimum of two weeks. Consensus must be reached on the param- 840 eter before proceeding to step 4. 842 13.4. Submit the parameter for approval 844 Once the two-week comment period has elapsed, and the proposer is con- 845 vinced consensus has been reached on the parameter, the registration 846 application should be submitted to the Profile Reviewer for approval. 847 The Profile Reviewer is appointed to the Application Area Directors and 848 may either accept or reject the parameter registration. An accepted 849 registration should be passed on by the Profile Reviewer to the IANA for 850 inclusion in the official IANA parameter registry. The registration may 851 be rejected for any of the following reasons. 1) Insufficient comment 852 period; 2) Consensus not reached; 3) Technical deficiencies raised on 853 Expires in six months INTERNET DRAFT 855 the list or elsewhere have not been addressed. The Profile Reviewer's 856 decision to reject a profile may be appealed by the proposer to the 857 IESG, or the objections raised can be addressed by the proposer and the 858 parameter registration resubmitted. 860 14. Parameter Change Control 862 Existing parameters may be changed using the same process by which they 863 were registered. 865 Define the change 867 Post the change 869 Allow a comment period 871 Submit the parameter for approval 873 Note that the original author or any other interested party may propose 874 a change to an existing parameter, but that such changes should only be 875 proposed when there are serious omissions or errors in the published 876 specification. The Profile Reviewer may object to a change if it is not 877 backwards compatible, but is not required to do so. 879 Parameter definitions can never be deleted from the IANA registry, but 880 parameters which are nolonger believed to be useful can be declared 881 OBSOLETE by a change to their "intended use" field. 883 15. Security Considerations 885 Internet mail is subject to many well known security attacks, including 886 monitoring, replay, and forgery. Care should be taken by any directory 887 service in allowing information to leave the scope of the service 888 itself, where any access controls can no longer be guaranteed. Applica- 889 tions should also take care to display directory data in a "safe" 890 environment (e.g., PostScript-valued types). 892 16. Acknowledgements 894 This material is based upon work supported by the National Science Foun- 895 dation under Grant No. NCR-9416667. The registration procedures defined 896 here were shamelessly lifted from the MIME registration draft. 898 17. Bibliography 900 [RFC-1777] Yeong, W., Howes, T., Kille, S., "Lightweight Directory 901 Access Protocol", Request for Comment (RFC) 1777, March 1995. 903 Expires in six months INTERNET DRAFT 905 [RFC-1778] Howes, T., Kille, S., Yeong, W., Robbins, C.J., "The String 906 Representation of Standard Attribute Syntaxes", Request for 907 Comment (RFC) 1778, March 1995. 909 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 910 Messages", STD 11, RFC 822, August 1982. 912 [RFC-1521] Borenstein, N., Freed, N., "MIME (Multipurpose Internet Mail 913 Extensions) Part One: Mechanisms for Specifying and Describ- 914 ing the Format of Internet Message Bodies", RFC 1521, Sep- 915 tember 1993. 917 [RFC-1522] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 918 Two: Message Header Extensions for Non-ASCII Text", RFC 919 1522, September 1993. 921 [RFC-1848] Crocker, S., Freed, N., Galvin, J., Murphy, S., "MIME Object 922 Security Services", RFC 1848, October 1995. 924 [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", 925 RFC 1766, March 1995. 927 [RFC-1872] Levinson, E., "The MIME Multipart/Related Content-type," RFC 928 1872, December 1995. 930 [MIME-REG] Freed, N., Postel, J., "Multipurpose Internet Mail Extensions 931 (MIME) Part Four: Registration Procedures," Internet-Draft 932 draft-ietf-822ext-mime-reg-02.txt, December 1995. 934 [x500] "Information Processing Systems - Open Systems Interconnec- 935 tion - The Directory: Overview of Concepts, Models and Ser- 936 vices", ISO/IEC JTC 1/SC21, International Standard 9594-1, 937 1988. 939 [RFC-1835] Deutsch, P., Schoultz, R., Faltstrom, P., Weider, C., "Archi- 940 tecture of the WHOIS++ service", August 1995. 942 [RFC-1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform 943 Resource Locators (URL)", RFC 1738, December 1994. 945 [MIME-WPP] Howes, T., Smith, M., "A White Pages Person Profile for the 946 application/directory MIME Content-Type", Internet-Draft 947 draft-ietf-asid-mime-person-00.txt, January, 1996. 949 [HTTP] Berners-Lee, T., Fielding, R. Frystyk, H., "Hypertext 950 Transfer Protocol -- HTTP/1.0", Internet-Draft draft-ietf- 951 http-v10-spec-05.txt, February, 1996. 953 Expires in six months INTERNET DRAFT 955 [VERSIT] VERSIT Consortium, "Electronic Business Card (vCard) Specifi- 956 cation", Draft Final Text - Version 2.0, February 16, 1996, 957 http://www.versit.com 959 18. Author's Address 961 Tim Howes 962 Netscape Communications Corp. 963 501 East Middlefield Rd. 964 Mountain View, CA 94041 965 USA 966 howes@netscape.com 967 +1.415.937.3419 969 Mark Smith 970 Netscape Communications Corp. 971 501 East Middlefield Rd. 972 Mountain View, CA 94041 973 USA 974 mcs@netscape.com 975 +1.415.937.3477