Add vmime library example
[rmail.git] / doc / rfc2425.txt
blob2e37e24a4f85b58f471e0ae21095dad740e4cd16
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
15              A MIME Content-Type for Directory Information
17 Status of this Memo
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.
25 Copyright Notice
27    Copyright (C) The Internet Society (1998).  All Rights Reserved.
29 1.  Abstract
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.
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).
58 Howes, et. al.              Standards Track                     [Page 1]
60 RFC 2425      MIME Content-Type for Directory Information September 1998
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].
67 2.  Table of Contents
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
114 Howes, et. al.              Standards Track                     [Page 2]
116 RFC 2425      MIME Content-Type for Directory Information September 1998
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
142 3.  Need for a MIME Directory Type
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.
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.
170 Howes, et. al.              Standards Track                     [Page 3]
172 RFC 2425      MIME Content-Type for Directory Information September 1998
175 4.  Overview
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].
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.
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.
207 5.  The text/directory Content-Type
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].
215    To: ietf-types@uninett.no
216    Subject: Registration of MIME media type text/directory
218 5.1.  MIME media type name
220    MIME media type name: text
226 Howes, et. al.              Standards Track                     [Page 4]
228 RFC 2425      MIME Content-Type for Directory Information September 1998
231 5.2.  MIME subtype name
233    MIME subtype name: directory
235 5.3.  Required parameters
237    Required parameters: charset
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.
243 5.4.  Optional parameters
245    Optional parameters: profile
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.
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").
261          profile = x-name / iana-token
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.
268          iana-token = <a publicly-defined extension token, registered
269                         with IANA, as specified in Section 9 of this
270                         document>
272 5.5.  Encoding considerations
274    The default encoding is 8bit. Otherwise, as specified by the
275    Content-Transfer-Encoding header field.
282 Howes, et. al.              Standards Track                     [Page 5]
284 RFC 2425      MIME Content-Type for Directory Information September 1998
287 5.6.  Security considerations
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.
299 5.7.  Interoperability considerations
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.
309 5.8.  Published specification
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.
316 5.8.1.  Line delimiting and folding
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.
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:
332    DESCRIPTION:This is a long description that exists on a long line.
334    Can be represented as:
338 Howes, et. al.              Standards Track                     [Page 6]
340 RFC 2425      MIME Content-Type for Directory Information September 1998
343    DESCRIPTION:This is a long description
344      that exists on a long line.
346    It could also be represented as:
348    DESCRIPTION:This is a long descrip
349     tion that exists o
350     n a long line.
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).
359 5.8.2.  ABNF content-type definition
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:
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.
374    group        = 1*(ALPHA / DIGIT / "-")
376    name         = x-name / iana-token
378    iana-token   = 1*(ALPHA / DIGIT / "-")
379       ; identifier registered with IANA
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.
386    param        = param-name "=" param-value *("," param-value)
388    param-name   = x-name / iana-token
390    param-value  = ptext / quoted-string
394 Howes, et. al.              Standards Track                     [Page 7]
396 RFC 2425      MIME Content-Type for Directory Information September 1998
399    ptext  = *SAFE-CHAR
401    value = *VALUE-CHAR
402          / valuespec      ; valuespec defined in section 5.8.4
404    quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
406    NON-ASCII    = %x80-FF
407       ; use restricted by charset parameter
408       ; on outer MIME object (UTF-8 preferred)
410    QSAFE-CHAR   = WSP / %x21 / %x23-7E / NON-ASCII
411       ; Any character except CTLs, DQUOTE
413    SAFE-CHAR    = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII
414       ; Any character except CTLs, DQUOTE, ";", ":", ","
416    VALUE-CHAR   = WSP / VCHAR / NON-ASCII
417       ; any textual character
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.
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.
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.
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.
450 Howes, et. al.              Standards Track                     [Page 8]
452 RFC 2425      MIME Content-Type for Directory Information September 1998
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.
465 5.8.3.  Pre-defined Parameters
467    The following parameters and value types are defined for general use.
469          predefined-param = encodingparm
470                           / valuetypeparm
471                           / languageparm
472                           / contextparm
474          encodingparm = "encoding" "=" encodingtype
476          encodingtype = "b"       ; from RFC 2047
477                     / iana-token  ; registered as described in
478                                   ; section 15 of this document
480          valuetypeparm = "value" "=" valuetype
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
494          languageparm = "language" "=" Language-Tag
495              ; Language-Tag is defined in section 2 of RFC 1766
497          contextparm = "context" "=" context
499          context = x-name
500                  / iana-token
506 Howes, et. al.              Standards Track                     [Page 9]
508 RFC 2425      MIME Content-Type for Directory Information September 1998
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].
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.
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.
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.
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.
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.
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.
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
562 Howes, et. al.              Standards Track                    [Page 10]
564 RFC 2425      MIME Content-Type for Directory Information September 1998
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.
571 5.8.4.  Pre-defined Value Types
573    The format for values corresponding to the predefined valuetype
574    specifications given above are defined.
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
586    text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR)
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.
593    date-list = date *("," date)
595    time-list = time *("," time)
597    date-time-list = date "T" time *("," date "T" time)
599    boolean = "TRUE" / "FALSE"
601    integer-list = integer *("," integer)
603    integer = [sign] 1*DIGIT
605    float-list = float *("," float)
607    float = [sign] 1*DIGIT ["." 1*DIGIT]
609    sign = "+" / "-"
611    date = date-fullyear ["-"] date-month ["-"] date-mday
613    date-fullyear = 4 DIGIT
618 Howes, et. al.              Standards Track                    [Page 11]
620 RFC 2425      MIME Content-Type for Directory Information September 1998
623    date-month = 2 DIGIT     ;01-12
625    date-mday = 2 DIGIT      ;01-28, 01-29, 01-30, 01-31
626                             ;based on month/year
628    time = time-hour [":"] time-minute [":"] time-second [time-secfrac]
629            [time-zone]
631    time-hour = 2 DIGIT      ;00-23
633    time-minute = 2 DIGIT    ;00-59
635    time-second = 2 DIGIT    ;00-60 (leap second)
637    time-secfrac = "," 1*DIGIT
639    time-zone = "Z" / time-numzone
641    time-numzome = sign time-hour [":"] time-minute
643    iana-valuespec = <a publicly-defined valuetype format, registered
644                      with IANA, as defined in section 15 of this
645                      document>
647    Some specific notes on the value types and formats:
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.
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
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".
664    For example a multiple line DESCRIPTION value of:
666    Mythical Manager
667    Hyjinx Software Division
668    BabsCo, Inc.
670    could be represented as:
674 Howes, et. al.              Standards Track                    [Page 12]
676 RFC 2425      MIME Content-Type for Directory Information September 1998
679    DESCRIPTION:Mythical Manager\nHyjinx Software Division\n
680     BabsCo\, Inc.\n
682    demonstrating the \n literal formatted line break technique, the
683    CRLF-followed-by-space line folding technique, and the backslash
684    escape technique.
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.
692        Examples for "uri":
693                   http://www.foobar.com/my/picture.jpg
694                   ldap://ldap.foobar.com/cn=babs%20jensen
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.
702        Examples for "date":
703                    1985-04-12
704                    1996-08-05,1996-11-11
705                    19850412
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
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
721    "boolean": The "boolean" value type is used to express boolen values.
722    These values are case insensitive.
724        Examples: TRUE
725                  false
726                  True
730 Howes, et. al.              Standards Track                    [Page 13]
732 RFC 2425      MIME Content-Type for Directory Information September 1998
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.
740        Examples: 1234567890
741                  -1234556790
742                  +1234556790,432109876
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.
749        Examples: 20.30
750                  1000000.0000001
751                  1.333,3.14
753 5.9.  Applications which use this media type
755    Applications which use this media type: Various
757 5.10.  Additional information
759    Additional information: None
761 5.11.  Person & email address to contact for further information
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
771 5.12.  Intended usage
773    Intended usage: COMMON
786 Howes, et. al.              Standards Track                    [Page 14]
788 RFC 2425      MIME Content-Type for Directory Information September 1998
791 5.13.  Author/Change controller
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
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
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
817 6.  Predefined Types
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.
825 6.1.  SOURCE Type Definition
827    To: ietf-mime-direct@imc.org
828    Subject: Registration of text/directory MIME type SOURCE
830    Type name: SOURCE
832    Type purpose: To identify the source of directory information
833    contained in the content type.
835    Type encoding: 8bit
837    Type valuetype: uri
842 Howes, et. al.              Standards Track                    [Page 15]
844 RFC 2425      MIME Content-Type for Directory Information September 1998
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.
860    Type example:
861            SOURCE;CONTEXT=LDAP:ldap://ldap.host/cn=Babs%20Jensen,
862             %20o=Babsco,%20c=US
864 6.2.  NAME Type Definition
866    To: ietf-mime-direct@imc.org
867    Subject: Registration of text/directory MIME type NAME
869    Type name: NAME
871    Type purpose: To identify the displayable name of the directory
872    entity to which information in the content type pertains.
874    Type encoding: 8bit
876    Type valuetype: text
878    Type special notes: The NAME type is used to convey the display name
879    of the entity to which the directory information pertains.
881    Type example:
882            NAME:Babs Jensen's Contact Information
884 6.3.  PROFILE Type Definition
886    To: ietf-mime-direct@imc.org
887    Subject: Registration of text/directory MIME type PROFILE
889    Type name: PROFILE
891    Type purpose: To identify the type of directory entity to which
892    information in the content type pertains.
894    Type encoding: 8bit
898 Howes, et. al.              Standards Track                    [Page 16]
900 RFC 2425      MIME Content-Type for Directory Information September 1998
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.
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.
912    Type example:
913            PROFILE:vCard
915 6.4.  BEGIN Type Definition
917    To: ietf-mime-direct@imc.org
918    Subject: Registration of text/directory MIME type BEGIN
920    Type name: BEGIN
922    Type purpose: To denote the beginning of a syntactic entity within a
923    text/directory content-type.
925    Type encoding: 8bit
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.
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.
940    Type example:
941            BEGIN:VCARD
943 6.5.  END Type Definition
945    To: ietf-mime-direct@imc.org
946    Subject: Registration of text/directory MIME type END
948    Type name: END
954 Howes, et. al.              Standards Track                    [Page 17]
956 RFC 2425      MIME Content-Type for Directory Information September 1998
959    Type purpose: To denote the end of a syntactic entity within a
960    text/directory content-type.
962    Type encoding: 8bit
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.
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.
977    Type example:
978            END: VCARD
980 7.  Use of the multipart/related Content-Type
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.
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.
996 8.  Examples
998    The following examples are for illustrative purposes only and are not
999    part of the definition.
1010 Howes, et. al.              Standards Track                    [Page 18]
1012 RFC 2425      MIME Content-Type for Directory Information September 1998
1015 8.1.  Example 1
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.
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>
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
1038 8.2.  Example 2
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.
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
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
1066 Howes, et. al.              Standards Track                    [Page 19]
1068 RFC 2425      MIME Content-Type for Directory Information September 1998
1071 8.3.  Example 3
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.
1079 Content-Type: text/directory; profile="vcard"; charset=iso-8859-1
1080 Content-ID: <id3@host.com>
1081 Content-Transfer-Encoding: Quoted-Printable
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
1122 Howes, et. al.              Standards Track                    [Page 20]
1124 RFC 2425      MIME Content-Type for Directory Information September 1998
1127 8.4.  Example 4
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.
1137 Content-Type: multipart/related;
1138         boundary=woof;
1139         type="text/directory";
1140         start="<id5@host.com>"
1141 Content-ID: <id4@host.com>
1143 --woof
1144 Content-Type: text/directory; charset="iso-8859-1"
1145 Content-ID: <id5@host.com>
1146 Content-Transfer-Encoding: Quoted-Printable
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
1157 --woof
1158 Content-Type: image/jpeg
1159 Content-ID: <id6@host.com>
1161 <...image data...>
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"
1171 Content-Type: audio/basic
1172 Content-ID: <id7@host.com>
1174 --woof--
1178 Howes, et. al.              Standards Track                    [Page 21]
1180 RFC 2425      MIME Content-Type for Directory Information September 1998
1183 9.  Registration of new profiles
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.
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.
1194    Registration of a new profile is accomplished by the following steps.
1196 9.1.  Define the profile
1198    A profile is defined by completing the following template.
1200       To: ietf-mime-direct@imc.org
1201       Subject: Registration of text/directory MIME profile XXX
1203       Profile name:
1205       Profile purpose:
1207       Profile types:
1209       Profile special notes (optional):
1211       Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
1213    The explanation of what goes in each field in the template follows.
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.
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.
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.
1234 Howes, et. al.              Standards Track                    [Page 22]
1236 RFC 2425      MIME Content-Type for Directory Information September 1998
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.
1244 9.2.  Post the profile definition
1246    The profile description must be posted to the new profile discussion
1247    list, ietf-mime-direct@imc.org
1249 9.3.  Allow a comment period
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.
1255 9.4.  Submit the profile for approval
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.
1271 10.  Profile Change Control
1273    Existing profiles can be changed using the same process by which they
1274    were registered.
1276          Define the change
1278          Post the change
1280          Allow a comment period
1282          Submit the changed profile for approval
1290 Howes, et. al.              Standards Track                    [Page 23]
1292 RFC 2425      MIME Content-Type for Directory Information September 1998
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.
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.
1305 11.  Registration of new types
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.
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.
1316    Registration of a new type is accomplished by the following steps.
1318 11.1.  Define the type
1320    A type is defined by completing the following template.
1322       To: ietf-mime-direct@imc.org
1323       Subject: Registration of text/directory MIME type XXX
1325       Type name:
1327       Type purpose:
1329       Type encoding:
1331       Type valuetype:
1333       Type special notes (optional):
1335       Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
1337    The meaning of each field in the template is as follows.
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 ":".
1346 Howes, et. al.              Standards Track                    [Page 24]
1348 RFC 2425      MIME Content-Type for Directory Information September 1998
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.
1355    Type encoding: The default encoding a value of the type must have in
1356    the body of a text/directory MIME Content-Type.
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.
1363    Type special notes: Any special notes about the type, how it is to be
1364    used, etc.
1366 11.2.  Post the type definition
1368    The type description must be posted to the new type discussion list,
1369    ietf-mime-direct@imc.org
1371 11.3.  Allow a comment period
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.
1377 11.4.  Submit the type for approval
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.
1402 Howes, et. al.              Standards Track                    [Page 25]
1404 RFC 2425      MIME Content-Type for Directory Information September 1998
1407 12.  Type Change Control
1409    Existing types can be changed using the same process by which they
1410    were registered.
1412          Define the change
1414          Post the change
1416          Allow a comment period
1418          Submit the type for approval
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.
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.
1430 13.  Registration of new parameters
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.
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.
1442    Registration of a new parameter is accomplished by the following
1443    steps.
1445 13.1.  Define the parameter
1447    A parameter is defined by completing the following template.
1449       To: ietf-mime-direct@imc.org
1450       Subject: Registration of text/directory MIME type parameter XXX
1452       Parameter name:
1454       Parameter purpose:
1458 Howes, et. al.              Standards Track                    [Page 26]
1460 RFC 2425      MIME Content-Type for Directory Information September 1998
1463       Parameter values:
1465       Parameter special notes (optional):
1467       Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
1469    The explanation of what goes in each field in the template follows.
1471    Parameter name: The name of the parameter as it will appear in the
1472    text/directory MIME Content-Type.
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.
1480    Parameter values: The list or description of values associated with
1481    the parameter.
1483    Parameter special notes: Any special notes about the parameter, how
1484    it is to be used, etc.
1486 13.2.  Post the parameter definition
1488    The parameter description must be posted to the new parameter
1489    discussion list, ietf-mime-direct@imc.org
1491 13.3.  Allow a comment period
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.
1497 13.4.  Submit the parameter for approval
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
1514 Howes, et. al.              Standards Track                    [Page 27]
1516 RFC 2425      MIME Content-Type for Directory Information September 1998
1519    addressed by the proposer and the parameter registration resubmitted.
1521 14.  Parameter Change Control
1523    Existing parameters can be changed using the same process by which
1524    they were registered.
1526          Define the change
1528          Post the change
1530          Allow a comment period
1532          Submit the parameter for approval
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.
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.
1545 15.  Registration of new value types
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.
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.
1557    Registration of a new value types is accomplished by the following
1558    steps.
1560 15.1.  Define the value type
1562    A value type is defined by completing the following template.
1564       To: ietf-mime-direct@imc.org
1565       Subject: Registration of text/directory MIME value type XXX
1570 Howes, et. al.              Standards Track                    [Page 28]
1572 RFC 2425      MIME Content-Type for Directory Information September 1998
1575       value type name:
1577       value type purpose:
1579       value type format:
1581       value type special notes (optional):
1583       Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
1585    The explanation of what goes in each field in the template follows.
1587    value type name: The name of the value type as it will appear in the
1588    text/directory MIME Content-Type.
1590    value type purpose: The purpose of the value type.  Give a short but
1591    clear description.
1593    value type format: The definition of the format for the value,
1594    usually using ABNF grammar.
1596    value type special notes: Any special notes about the value type, how
1597    it is to be used, etc.
1599 15.2.  Post the value type definition
1601    The value type description must be posted to the new value type
1602    discussion list, ietf-mime-direct@imc.org
1604 15.3.  Allow a comment period
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.
1610 15.4.  Submit the value type for approval
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
1626 Howes, et. al.              Standards Track                    [Page 29]
1628 RFC 2425      MIME Content-Type for Directory Information September 1998
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.
1635 16.  Security Considerations
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).
1644 17.  Acknowledgements
1646    The registration procedures defined here were shamelessly lifted from
1647    the MIME registration RFC.
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.
1654 18.  References
1656    [RFC-1777]   Yeong, W., Howes, T., and S. Kille, "Lightweight
1657                 Directory Access Protocol", RFC 1777, March 1995.
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.
1663    [RFC-822]    Crocker, D., "Standard for the Format of ARPA Internet
1664                 Text Messages", STD 11, RFC 822, August 1982.
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.
1670    [RFC-2046]   Moore, K., "Multipurpose Internet Mail Extensions (MIME)
1671                 Part Two:  Media Types", RFC 2046, November 1996.
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.
1677    [RFC-1766]   Alvestrand, H., "Tags for the Identification of
1678                 Languages", RFC 1766, March 1995.
1682 Howes, et. al.              Standards Track                    [Page 30]
1684 RFC 2425      MIME Content-Type for Directory Information September 1998
1687    [RFC-2112]   Levinson, E., "The MIME Multipart/Related Content-type",
1688                 RFC 2112, March 1997.
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.
1695    [RFC-1835]   Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider,
1696                 "Architecture of the WHOIS++ service", RFC 1835, August
1697                 1995.
1699    [RFC-1738]   Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
1700                 Resource Locators (URL)", RFC 1738, December 1994.
1702    [MIME-VCARD] Dawson, F., and T. Howes, "VCard MIME Directory
1703                 Profile", RFC 2426, September 1998.
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.
1709    [RFC-2119]   Bradner, S., "Key words for use in RFCs to Indicate
1710                 Requirement  Levels", BCP 14, RFC 2119, March 1997.
1712    [RFC-2234]   Crocker, D., and P. Overell, "Augmented BNF for Syntax
1713                 Specifications: ABNF", RFC 2234, November 1997.
1738 Howes, et. al.              Standards Track                    [Page 31]
1740 RFC 2425      MIME Content-Type for Directory Information September 1998
1743 19.  Authors' Addresses
1745    Tim Howes
1746    Netscape Communications Corp.
1747    501 East Middlefield Rd.
1748    Mountain View, CA 94041
1749    USA
1751    Phone: +1.415.937.3419
1752    EMail: howes@netscape.com
1755    Mark Smith
1756    Netscape Communications Corp.
1757    501 East Middlefield Rd.
1758    Mountain View, CA 94041
1759    USA
1761    Phone: +1.415.937.3477
1762    EMail: mcs@netscape.com
1765    Frank Dawson
1766    Lotus Development Corporation
1767    6544 Battleford Drive
1768    Raleigh, NC 27613
1769    USA
1771    Phone: +1-919-676-9515
1772    EMail: frank_dawson@lotus.com
1794 Howes, et. al.              Standards Track                    [Page 32]
1796 RFC 2425      MIME Content-Type for Directory Information September 1998
1799 20.  Full Copyright Statement
1801    Copyright (C) The Internet Society (1998).  All Rights Reserved.
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.
1817    The limited permissions granted above are perpetual and will not be
1818    revoked by the Internet Society or its successors or assigns.
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.
1850 Howes, et. al.              Standards Track                    [Page 33]