mirror of
https://git.friendi.ca/friendica/friendica-addons.git
synced 2024-08-16 19:01:01 +00:00
1851 lines
63 KiB
Text
1851 lines
63 KiB
Text
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group T. Howes
|
||
Request for Comments: 2425 M. Smith
|
||
Category: Standards Track Netscape Communications Corp.
|
||
F. Dawson
|
||
Lotus Development Corporation
|
||
September 1998
|
||
|
||
|
||
A MIME Content-Type for Directory Information
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||
|
||
1. Abstract
|
||
|
||
This document defines a MIME Content-Type for holding directory
|
||
information. The definition is independent of any particular
|
||
directory service or protocol. The text/directory Content-Type is
|
||
defined for holding a variety of directory information, for example,
|
||
name, or email address, or logo. The text/directory Content-Type can
|
||
also be used as the root body part in a multipart/related Content-
|
||
Type for handling more complicated situations, especially those in
|
||
which non-textual information that already has a natural MIME
|
||
representation, for example, a photograph or sound, is to be
|
||
represented.
|
||
|
||
The text/directory Content-Type defines a general framework and
|
||
format for holding directory information in a simple "type:value"
|
||
form. We refer to "type" in this context meaning a property or
|
||
attribute with which the value is associated. Mechanisms are defined
|
||
to specify alternate languages, encodings and other meta-information.
|
||
This document also defines the procedure by which particular formats,
|
||
called profiles, for carrying application-specific information within
|
||
a text/directory Content-Type can be defined and registered, and the
|
||
conventions such formats must follow. It is expected that other
|
||
documents will be produced that define such formats for various
|
||
applications (e.g., white pages).
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 1]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
|
||
document are to be interpreted as described in [RFC-2119].
|
||
|
||
2. Table of Contents
|
||
|
||
Status of the Memo................................................ 1
|
||
Copyright Notice.................................................. 1
|
||
1. Abstract...................................................... 1
|
||
2. Table of Contents............................................. 2
|
||
3. Need for a MIME Directory Type................................ 3
|
||
4. Overview...................................................... 4
|
||
5. The text/directory Content-Type............................... 4
|
||
5.1. MIME media type name........................................ 4
|
||
5.2. MIME subtype name........................................... 5
|
||
5.3. Required parameters......................................... 5
|
||
5.4. Optional parameters......................................... 5
|
||
5.5. Encoding considerations..................................... 5
|
||
5.6. Security considerations..................................... 6
|
||
5.7. Interoperability considerations............................. 6
|
||
5.8. Published specification..................................... 6
|
||
5.8.1. Line delimiting and folding............................... 6
|
||
5.8.2. ABNF content-type definition.............................. 7
|
||
5.8.3. Pre-defined Parameters.................................... 9
|
||
5.8.4. Pre-defined Value Types...................................11
|
||
5.9. Applications which use this media type......................14
|
||
5.10. Additional information.....................................14
|
||
5.11. Person & email address to contact for further information..14
|
||
5.12. Intended usage.............................................14
|
||
5.13. Author/Change controller...................................15
|
||
6. Predefined Types..............................................15
|
||
6.1. SOURCE Type Definition......................................15
|
||
6.2. NAME Type Definition........................................16
|
||
6.3. PROFILE Type Definition.....................................16
|
||
6.4. BEGIN Type Definition.......................................17
|
||
6.5. END Type Definition.........................................17
|
||
7. Use of the multipart/related Content-Type.....................18
|
||
8. Examples.......................................................18
|
||
8.1. Example 1...................................................19
|
||
8.2. Example 2...................................................19
|
||
8.3. Example 3...................................................20
|
||
8.4. Example 4...................................................21
|
||
9. Registration of new profiles..................................22
|
||
9.1. Define the profile..........................................22
|
||
9.2. Post the profile definition.................................23
|
||
9.3. Allow a comment period......................................23
|
||
9.4. Submit the profile for approval.............................23
|
||
10. Profile Change Control.......................................23
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 2]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
11. Registration of new types....................................24
|
||
11.1. Define the type............................................24
|
||
11.2. Post the type definition...................................25
|
||
11.3. Allow a comment period.....................................25
|
||
11.4. Submit the type for approval...............................25
|
||
12. Type Change Control..........................................25
|
||
13. Registration of new parameters...............................26
|
||
13.1. Define the parameter.......................................26
|
||
13.2. Post the parameter definition..............................27
|
||
13.3. Allow a comment period.....................................27
|
||
13.4. Submit the parameter for approval..........................27
|
||
14. Parameter Change Control.....................................28
|
||
15. Registration of new value types..............................28
|
||
15.1. Define the value type......................................28
|
||
15.2. Post the value type definition.............................29
|
||
15.3. Allow a comment period.....................................29
|
||
15.4. Submit the value type for approval.........................29
|
||
16. Security Considerations......................................30
|
||
17. Acknowledgements..............................................30
|
||
18. References....................................................30
|
||
19. Authors' Addresses...........................................32
|
||
20. Full Copyright Statement......................................33
|
||
|
||
3. Need for a MIME Directory Type
|
||
|
||
For purposes of this document, a directory is a special-purpose
|
||
database that contains typed information. A directory usually
|
||
supports both read and search of the information it contains, and can
|
||
support creation and modification of the information as well.
|
||
Directory information is usually accessed far more often than it is
|
||
updated. Directories can be local or global in scope. They can be
|
||
distributed or centralized. The information they contain can be
|
||
replicated, with weak or strong consistency requirements.
|
||
|
||
There are several situations in which users of Internet mail might
|
||
wish to exchange directory information: the email analogy of a
|
||
"business card" exchange; the conveyance of directory information to
|
||
a user having only email access to the Internet; the provision of
|
||
machine-parseable address information when purchasing goods or
|
||
services over the Internet; etc. As MIME [RFC-2045, RFC-2046] is
|
||
used increasingly by other protocols, most notably HTTP, it can also
|
||
be useful for these protocols to carry directory information in MIME
|
||
format. Such a format, for example, could be used to represent URC
|
||
(uniform resource characteristics) information about resources on the
|
||
World Wide Web, or to provide a rudimentary directory service over
|
||
HTTP.
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 3]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
4. Overview
|
||
|
||
The scheme defined here for representing directory information in a
|
||
MIME Content-Type has two parts. First, the text/directory Content-
|
||
Type is defined for use in holding directory information within a
|
||
single body part, for example name, title, or email address. In its
|
||
simplest form, the format uses a "type:value" approach, which should
|
||
be easily parseable by existing MIME implementations and
|
||
understandable by users. More complicated situations can be
|
||
represented also. This document defines the general form the
|
||
information in the Content-Type should have, and the procedure by
|
||
which specific types and values (properties) for particular
|
||
applications can be defined. The framework is general enough to
|
||
handle information from any number of end directory services,
|
||
including LDAP [RFC-1777, RFC-1778], WHOIS++ [RFC-1835], and X.500
|
||
[X500].
|
||
|
||
Directory entries can include far more than just textual information.
|
||
Some such information (e.g., an image or sound) overlaps with
|
||
predefined MIME Content-Types. In these cases it can be desirable to
|
||
include the information in its well-known MIME format. This situation
|
||
is handled by using a multipart/related Content-Type as defined in
|
||
[RFC-2112]. The root component of this type is a text/directory body
|
||
part specifying any in-line information, and for information
|
||
contained in other Content-Types, the Content-IDs (in URI form) of
|
||
those parts.
|
||
|
||
In some applications, it can be useful to include a pointer (e.g, a
|
||
URI) to some directory information rather than the information
|
||
itself. This document defines a general mechanism for accomplishing
|
||
this.
|
||
|
||
5. The text/directory Content-Type
|
||
|
||
The text/directory Content-Type is used to hold basic directory
|
||
information and URIs referencing other information, including other
|
||
MIME body parts holding supplementary or non-textual directory
|
||
information, such as an image or sound. It is defined as follows,
|
||
using the MIME media type registration template from [RFC-2048].
|
||
|
||
To: ietf-types@uninett.no
|
||
Subject: Registration of MIME media type text/directory
|
||
|
||
5.1. MIME media type name
|
||
|
||
MIME media type name: text
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 4]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
5.2. MIME subtype name
|
||
|
||
MIME subtype name: directory
|
||
|
||
5.3. Required parameters
|
||
|
||
Required parameters: charset
|
||
|
||
The "charset" parameter is as defined in [RFC-2046] for other body
|
||
parts. It is used to identify the default character set used within
|
||
the body part.
|
||
|
||
5.4. Optional parameters
|
||
|
||
Optional parameters: profile
|
||
|
||
The "profile" parameter is used to convey the type(s) of entity(ies)
|
||
to which the directory information pertains and the likely set of
|
||
information associated with the entity(ies). It is intended only as a
|
||
guide to applications interpreting the information contained within
|
||
the body part. It SHOULD NOT be used to exclude or require particular
|
||
pieces of information unless a profile definition specifically calls
|
||
for this behavior. Unless specifically forbidden by a particular
|
||
profile definition, a text/directory content type can contain
|
||
arbitrary attribute/value pairs.
|
||
|
||
The value of the "profile" parameter is defined as follows. Profile
|
||
names are case insensitive (i.e., the profile name "vCard" is the
|
||
same as "VCARD" and "vcard" and "vcArD").
|
||
|
||
profile = x-name / iana-token
|
||
|
||
x-name = "x-" 1*(ALPHA / DIGIT / "-")
|
||
; Names beginning with "x-" or "X-" are
|
||
; reserved for experimental use not intended for released
|
||
; products, or for use in bilateral agreements.
|
||
|
||
iana-token = <a publicly-defined extension token, registered
|
||
with IANA, as specified in Section 9 of this
|
||
document>
|
||
|
||
5.5. Encoding considerations
|
||
|
||
The default encoding is 8bit. Otherwise, as specified by the
|
||
Content-Transfer-Encoding header field.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 5]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
5.6. Security considerations
|
||
|
||
Directory information can be public or it can be protected from
|
||
unauthorized access by the directory service in which it resides.
|
||
Once the information leaves its native service, there can be no
|
||
guarantee that the same care will be taken by all services handling
|
||
the information. Furthermore, this specification defines no access
|
||
control mechanism by which information can be protected, or by which
|
||
access control information can be conveyed. Note that the integrity
|
||
and privacy of a text/directory body part can be protected by
|
||
enclosing it within an appropriate MIME-based security mechanism.
|
||
|
||
5.7. Interoperability considerations
|
||
|
||
In order to make sense of directory information, applications must
|
||
share a common understanding of the types of information contained
|
||
within the Content-Type (the directory schema). This schema
|
||
information is not defined in this document, but rather in companion
|
||
documents (e.g., [MIME-VCARD]) that follow the requirements specified
|
||
in this document, or in bilateral agreements between communicating
|
||
parties.
|
||
|
||
5.8. Published specification
|
||
|
||
The text/directory Content-Type contains directory information,
|
||
typically pertaining to a single directory entity or group of
|
||
entities. The content consists of one or more lines in the format
|
||
given below.
|
||
|
||
5.8.1. Line delimiting and folding
|
||
|
||
Individual lines within the MIME text/directory Content Type body are
|
||
delimited by the [RFC-822] line break, which is a CRLF sequence
|
||
(ASCII decimal 13, followed by ASCII decimal 10). Long logical lines
|
||
of text can be split into a multiple-physical-line representation
|
||
using the following folding technique.
|
||
|
||
A logical line MAY be continued on the next physical line anywhere
|
||
between two characters by inserting a CRLF immediately followed by a
|
||
single white space character (space, ASCII decimal 32, or horizontal
|
||
tab, ASCII decimal 9). At least one character must be present on the
|
||
folded line. Any sequence of CRLF followed immediately by a single
|
||
white space character is ignored (removed) when processing the
|
||
content type. For example the line:
|
||
|
||
DESCRIPTION:This is a long description that exists on a long line.
|
||
|
||
Can be represented as:
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 6]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
DESCRIPTION:This is a long description
|
||
that exists on a long line.
|
||
|
||
It could also be represented as:
|
||
|
||
DESCRIPTION:This is a long descrip
|
||
tion that exists o
|
||
n a long line.
|
||
|
||
The process of moving from this folded multiple-line representation
|
||
of a type definition to its single line representation is called
|
||
unfolding. Unfolding is accomplished by regarding CRLF immediately
|
||
followed by a white space character (namely HTAB ASCII decimal 9 or
|
||
SPACE ASCII decimal 32) as equivalent to no characters at all (i.e.,
|
||
the CRLF and single white space character are removed).
|
||
|
||
5.8.2. ABNF content-type definition
|
||
|
||
The following ABNF uses the notation of RFC 2234, which also defines
|
||
CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. After the unfolding of
|
||
any folded lines as described above, the syntax for a line of this
|
||
content type is as follows:
|
||
|
||
contentline = [group "."] name *(";" param) ":" value CRLF
|
||
; When parsing a content line, folded lines MUST first
|
||
; be unfolded according to the unfolding procedure
|
||
; described above.
|
||
; When generating a content line, lines longer than 75
|
||
; characters SHOULD be folded according to the folding
|
||
; procedure described above.
|
||
|
||
group = 1*(ALPHA / DIGIT / "-")
|
||
|
||
name = x-name / iana-token
|
||
|
||
iana-token = 1*(ALPHA / DIGIT / "-")
|
||
; identifier registered with IANA
|
||
|
||
x-name = "x-" 1*(ALPHA / DIGIT / "-")
|
||
; Names that begin with "x-" or "X-" are
|
||
; reserved for experimental use, not intended for released
|
||
; products, or for use in bilateral agreements.
|
||
|
||
param = param-name "=" param-value *("," param-value)
|
||
|
||
param-name = x-name / iana-token
|
||
|
||
param-value = ptext / quoted-string
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 7]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
ptext = *SAFE-CHAR
|
||
|
||
value = *VALUE-CHAR
|
||
/ valuespec ; valuespec defined in section 5.8.4
|
||
|
||
quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
|
||
|
||
NON-ASCII = %x80-FF
|
||
; use restricted by charset parameter
|
||
; on outer MIME object (UTF-8 preferred)
|
||
|
||
QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII
|
||
; Any character except CTLs, DQUOTE
|
||
|
||
SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII
|
||
; Any character except CTLs, DQUOTE, ";", ":", ","
|
||
|
||
VALUE-CHAR = WSP / VCHAR / NON-ASCII
|
||
; any textual character
|
||
|
||
A line that begins with a white space character is a continuation of
|
||
the previous line, as described above. The white space character and
|
||
immediately preceeding CRLF should be discarded when reconstructing
|
||
the original line. Note that this line-folding convention differs
|
||
from that found in RFC 822, in that the sequence <CRLF><WSP> found
|
||
anywhere in the content indicates a continued line and should be
|
||
removed.
|
||
|
||
Various type names and the format of the corresponding values are
|
||
defined as specified in Section 11. Specifications MAY impose
|
||
ordering on the type constructs within a body part, though none is
|
||
required by default. The various x-name constructs are used for
|
||
bilaterally-agreed upon type names, parameter names and parameter
|
||
values, or for use in experimental settings.
|
||
|
||
Type names and parameter names are case insensitive (e.g., the type
|
||
name "fn" is the same as "FN" and "Fn"). Parameter values MAY be case
|
||
sensitive or case insensitive, depending on their definition.
|
||
|
||
The group construct is used to group related attributes together.
|
||
The group name is a syntactic convention used to indicate that all
|
||
type names prefaced with the same group name SHOULD be grouped
|
||
together when displayed by an application. It has no other
|
||
significance. Implementations that do not understand or support
|
||
grouping MAY simply strip off any text before a "." to the left of
|
||
the type name and present the types and values as normal.
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 8]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
Each attribute defined in the text/directory body MAY have multiple
|
||
values, if allowed in the definition of the profile in which the
|
||
attribute is used. The general rule for encoding multi-valued items
|
||
is to simply create a new content line for each value (including the
|
||
type name). However, it should be noted that some value types
|
||
support encoding multiple values in a single content line by
|
||
separating the values with a comma ",". This approach has been taken
|
||
for several of the content types defined below (date, time, integer,
|
||
float), for space-saving reasons.
|
||
|
||
5.8.3. Pre-defined Parameters
|
||
|
||
The following parameters and value types are defined for general use.
|
||
|
||
predefined-param = encodingparm
|
||
/ valuetypeparm
|
||
/ languageparm
|
||
/ contextparm
|
||
|
||
encodingparm = "encoding" "=" encodingtype
|
||
|
||
encodingtype = "b" ; from RFC 2047
|
||
/ iana-token ; registered as described in
|
||
; section 15 of this document
|
||
|
||
valuetypeparm = "value" "=" valuetype
|
||
|
||
valuetype = "uri" ; genericurl from secion 5 of RFC 1738
|
||
/ "text"
|
||
/ "date"
|
||
/ "time"
|
||
/ "date-time" ; date time
|
||
/ "integer"
|
||
/ "boolean"
|
||
/ "float"
|
||
/ x-name
|
||
/ iana-token ; registered as described in
|
||
; section 15 of this document
|
||
|
||
languageparm = "language" "=" Language-Tag
|
||
; Language-Tag is defined in section 2 of RFC 1766
|
||
|
||
contextparm = "context" "=" context
|
||
|
||
context = x-name
|
||
/ iana-token
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 9]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
The "language" type parameter is used to identify data in multiple
|
||
languages. There is no concept of "default" language, except as
|
||
specified by any "Content-Language" MIME header parameter that is
|
||
present. The value of the "language" type parameter is a language
|
||
tag as defined in Section 2 of [RFC-1766].
|
||
|
||
The "context" type parameter is used to identify a context (e.g., a
|
||
protocol) used in interpreting the value. This is used, for example,
|
||
in the "source" type, defined below.
|
||
|
||
The "encoding" type parameter is used to specify an alternate
|
||
encoding for a value. If the value contains a CRLF, it must be
|
||
encoded, since CRLF is used to separate lines in the content-type
|
||
itself. Currently, only the "b" encoding is supported.
|
||
|
||
The "b" encoding can also be useful for binary values that are mixed
|
||
with other text information in the body part (e.g., a certificate).
|
||
Using a per-value "b" encoding in this case leaves the other
|
||
information in a more readable form. The encoded base 64 value can be
|
||
split across multiple physical lines in the content type by using the
|
||
line folding technique described above.
|
||
|
||
The Content-Transfer-Encoding header field is used to specify the
|
||
encoding used for the body part as a whole. The "encoding" type
|
||
parameter is used to specify an encoding for a particular value
|
||
(e.g., a certificate). In this case, the Content-Transfer-Encoding
|
||
header might specify "8bit", while the one certificate value might
|
||
specify an encoding of "b" via an "encoding=b" type parameter.
|
||
|
||
The Content-Transfer-Encoding and the encodings of individual types
|
||
given by the "encoding" type parameter are independent of one
|
||
another. When encoding a text/directory body part for transmission,
|
||
individual type encodings are performed first, then the entire body
|
||
part is encoded according to the Content-Transfer-Encoding. When
|
||
decoding a text/directory body part, the Content-Transfer-Encoding is
|
||
decoded first, and then any individual types with an "encoding" type
|
||
parameter are decoded.
|
||
|
||
The "value" parameter is optional, and is used to identify the value
|
||
type (data type) and format of the value. The use of these
|
||
predefined formats is encouraged even if the value parameter is not
|
||
explicity used. By defining a standard set of value types and their
|
||
formats, existing parsing and processing code can be leveraged.
|
||
|
||
Including the value type explicitly as part of each property provides
|
||
an extra hint to keep parsing simple and support more generalized
|
||
applications. For example a search engine would not have to know the
|
||
particular value types for all of the items for which it is
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 10]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
searching. Because the value type is explicit in the definition, the
|
||
search engine could look for dates in any item type and provide
|
||
results that can still be interpreted.
|
||
|
||
5.8.4. Pre-defined Value Types
|
||
|
||
The format for values corresponding to the predefined valuetype
|
||
specifications given above are defined.
|
||
|
||
valuespec = text-list
|
||
/ genericurl ; from section 5 of RFC 1738
|
||
/ date-list
|
||
/ time-list
|
||
/ date-time-list
|
||
/ boolean
|
||
/ integer-list
|
||
/ float-list
|
||
/ iana-valuespec
|
||
|
||
text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR)
|
||
|
||
TEXT-LIST-CHAR = "\\" / "\," / "\n"
|
||
/ <any VALUE-CHAR except , or \ or newline>
|
||
; Backslashes, newlines, and commas must be encoded.
|
||
; \n or \N can be used to encode a newline.
|
||
|
||
date-list = date *("," date)
|
||
|
||
time-list = time *("," time)
|
||
|
||
date-time-list = date "T" time *("," date "T" time)
|
||
|
||
boolean = "TRUE" / "FALSE"
|
||
|
||
integer-list = integer *("," integer)
|
||
|
||
integer = [sign] 1*DIGIT
|
||
|
||
float-list = float *("," float)
|
||
|
||
float = [sign] 1*DIGIT ["." 1*DIGIT]
|
||
|
||
sign = "+" / "-"
|
||
|
||
date = date-fullyear ["-"] date-month ["-"] date-mday
|
||
|
||
date-fullyear = 4 DIGIT
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 11]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
date-month = 2 DIGIT ;01-12
|
||
|
||
date-mday = 2 DIGIT ;01-28, 01-29, 01-30, 01-31
|
||
;based on month/year
|
||
|
||
time = time-hour [":"] time-minute [":"] time-second [time-secfrac]
|
||
[time-zone]
|
||
|
||
time-hour = 2 DIGIT ;00-23
|
||
|
||
time-minute = 2 DIGIT ;00-59
|
||
|
||
time-second = 2 DIGIT ;00-60 (leap second)
|
||
|
||
time-secfrac = "," 1*DIGIT
|
||
|
||
time-zone = "Z" / time-numzone
|
||
|
||
time-numzome = sign time-hour [":"] time-minute
|
||
|
||
iana-valuespec = <a publicly-defined valuetype format, registered
|
||
with IANA, as defined in section 15 of this
|
||
document>
|
||
|
||
Some specific notes on the value types and formats:
|
||
|
||
"text": The "text" value type should be used to identify values that
|
||
contain human-readable text. The character set and language in which
|
||
the text is represented is controlled by the charset content-header
|
||
and the language type parameter and content-header.
|
||
|
||
Examples for "text":
|
||
this is a text value
|
||
this is one value,this is another
|
||
this is a single value\, with a comma encoded
|
||
|
||
A formatted text line break in a text value type MUST be represented
|
||
as the character sequence backslash (ASCII decimal 92) followed by a
|
||
Latin small letter n (ASCII decimal 110) or a Latin capital letter N
|
||
(ASCII decimal 78), that is "\n" or "\N".
|
||
|
||
For example a multiple line DESCRIPTION value of:
|
||
|
||
Mythical Manager
|
||
Hyjinx Software Division
|
||
BabsCo, Inc.
|
||
|
||
could be represented as:
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 12]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
DESCRIPTION:Mythical Manager\nHyjinx Software Division\n
|
||
BabsCo\, Inc.\n
|
||
|
||
demonstrating the \n literal formatted line break technique, the
|
||
CRLF-followed-by-space line folding technique, and the backslash
|
||
escape technique.
|
||
|
||
"uri": The "uri" value type should be used to identify values that
|
||
are referenced by a URI (including a Content-ID URI), instead of
|
||
encoded in-line. These value references might be used if the value is
|
||
too large, or otherwise undesirable to include directly. The format
|
||
for the URI is as defined in RFC 1738.
|
||
|
||
Examples for "uri":
|
||
http://www.foobar.com/my/picture.jpg
|
||
ldap://ldap.foobar.com/cn=babs%20jensen
|
||
|
||
"date", "time", and "date-time": Each of these value types is based
|
||
on a subset of the definitions in ISO 8601 standard. Profiles MAY
|
||
place further restrictions on "date" and "time" values. Multiple
|
||
"date" and "time" values can be specified using the comma-separated
|
||
notation, unless restricted by a profile.
|
||
|
||
Examples for "date":
|
||
1985-04-12
|
||
1996-08-05,1996-11-11
|
||
19850412
|
||
|
||
Examples for "time":
|
||
10:22:00
|
||
102200
|
||
10:22:00.33
|
||
10:22:00.33Z
|
||
10:22:33,11:22:00
|
||
10:22:00-08:00
|
||
|
||
Examples for "date-time":
|
||
1996-10-22T14:00:00Z
|
||
1996-08-11T12:34:56Z
|
||
19960811T123456Z
|
||
1996-10-22T14:00:00Z,1996-08-11T12:34:56Z
|
||
|
||
"boolean": The "boolean" value type is used to express boolen values.
|
||
These values are case insensitive.
|
||
|
||
Examples: TRUE
|
||
false
|
||
True
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 13]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
"integer": The "integer" value type is used to express signed
|
||
integers in decimal format. If sign is not specified, the value is
|
||
assumed positive "+". Multiple "integer" values can be specified
|
||
using the comma-separated notation, unless restricted by a profile.
|
||
|
||
Examples: 1234567890
|
||
-1234556790
|
||
+1234556790,432109876
|
||
|
||
"float": The "float" value type is used to express real numbers. If
|
||
sign is not specified, the value is assumed positive "+". Multiple
|
||
"float" values can be specified using the comma-separated notation,
|
||
unless restricted by a profile.
|
||
|
||
Examples: 20.30
|
||
1000000.0000001
|
||
1.333,3.14
|
||
|
||
5.9. Applications which use this media type
|
||
|
||
Applications which use this media type: Various
|
||
|
||
5.10. Additional information
|
||
|
||
Additional information: None
|
||
|
||
5.11. Person & email address to contact for further information
|
||
|
||
Tim Howes
|
||
Netscape Communications Corp.
|
||
501 East Middlefield Rd.
|
||
Mountain View, CA 94041
|
||
USA
|
||
howes@netscape.com
|
||
+1 415 937 3419
|
||
|
||
5.12. Intended usage
|
||
|
||
Intended usage: COMMON
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 14]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
5.13. Author/Change controller
|
||
|
||
Tim Howes
|
||
Netscape Communications Corp.
|
||
501 East Middlefield Rd.
|
||
Mountain View, CA 94041
|
||
USA
|
||
howes@netscape.com
|
||
+1 415 937 3419
|
||
|
||
Mark Smith
|
||
Netscape Communications Corp.
|
||
501 East Middlefield Rd.
|
||
Mountain View, CA 94041
|
||
USA
|
||
mcs@netscape.com
|
||
+1 415 937 3477
|
||
|
||
Frank Dawson
|
||
Lotus Development Corporation
|
||
6544 Battleford Drive
|
||
Raleigh, NC 27613-3502
|
||
USA
|
||
frank_dawson@lotus.com
|
||
+1-919-676-9515
|
||
|
||
6. Predefined Types
|
||
|
||
The following types are generally useful regardless of the profile
|
||
being carried and are defined below using the text/directory MIME
|
||
type registration template defined in Section 11.1 of this document.
|
||
These types MAY be included in any profile, unless explicitly
|
||
forbidden in the profile definition.
|
||
|
||
6.1. SOURCE Type Definition
|
||
|
||
To: ietf-mime-direct@imc.org
|
||
Subject: Registration of text/directory MIME type SOURCE
|
||
|
||
Type name: SOURCE
|
||
|
||
Type purpose: To identify the source of directory information
|
||
contained in the content type.
|
||
|
||
Type encoding: 8bit
|
||
|
||
Type valuetype: uri
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 15]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
Type special notes: The SOURCE type is used to provide the means by
|
||
which applications knowledgable in the given directory service
|
||
protocol can obtain additional or more up-to-date information from
|
||
the directory service. It contains a URI as defined in [RFC-1738]
|
||
and/or other information referencing the directory entity or entities
|
||
to which the information pertains. When directory information is
|
||
available from more than one source, the sending entity can pick what
|
||
it considers to be the best source, or multiple SOURCE types can be
|
||
included. The interpretation of the value for a SOURCE type can
|
||
depend on the setting of the CONTEXT type parameter. The value of the
|
||
CONTEXT type parameter MUST be compatible with the value of the uri
|
||
prefix.
|
||
|
||
Type example:
|
||
SOURCE;CONTEXT=LDAP:ldap://ldap.host/cn=Babs%20Jensen,
|
||
%20o=Babsco,%20c=US
|
||
|
||
6.2. NAME Type Definition
|
||
|
||
To: ietf-mime-direct@imc.org
|
||
Subject: Registration of text/directory MIME type NAME
|
||
|
||
Type name: NAME
|
||
|
||
Type purpose: To identify the displayable name of the directory
|
||
entity to which information in the content type pertains.
|
||
|
||
Type encoding: 8bit
|
||
|
||
Type valuetype: text
|
||
|
||
Type special notes: The NAME type is used to convey the display name
|
||
of the entity to which the directory information pertains.
|
||
|
||
Type example:
|
||
NAME:Babs Jensen's Contact Information
|
||
|
||
6.3. PROFILE Type Definition
|
||
|
||
To: ietf-mime-direct@imc.org
|
||
Subject: Registration of text/directory MIME type PROFILE
|
||
|
||
Type name: PROFILE
|
||
|
||
Type purpose: To identify the type of directory entity to which
|
||
information in the content type pertains.
|
||
|
||
Type encoding: 8bit
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 16]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
Type valuetype: A profile name, registered as described in Section 9
|
||
of this document or bilaterally agreed upon as described in Section
|
||
5.
|
||
|
||
Type special notes: The PROFILE type is used to convey the type of
|
||
the entity to which the directory information in the rest of the body
|
||
part pertains. It should be the same as the "profile" header
|
||
parameter, if present.
|
||
|
||
Type example:
|
||
PROFILE:vCard
|
||
|
||
6.4. BEGIN Type Definition
|
||
|
||
To: ietf-mime-direct@imc.org
|
||
Subject: Registration of text/directory MIME type BEGIN
|
||
|
||
Type name: BEGIN
|
||
|
||
Type purpose: To denote the beginning of a syntactic entity within a
|
||
text/directory content-type.
|
||
|
||
Type encoding: 8bit
|
||
|
||
Type valuetype: text, containing a profile name, registered as
|
||
described in Section 9 of this document or bilaterally-agreed upon as
|
||
described in Section 5.
|
||
|
||
Type special notes: The BEGIN type is used in conjunction with the
|
||
END type to delimit a profile containing a related set of properties
|
||
within an text/directory content-type. This construct can be used
|
||
instead of or in addition to wrapping separate sets of information
|
||
inside additional MIME headers. It is provided for applications that
|
||
wish to define content that can contain multiple entities within the
|
||
same text/directory content-type or to define content that can be
|
||
identifiable outside of a MIME environment.
|
||
|
||
Type example:
|
||
BEGIN:VCARD
|
||
|
||
6.5. END Type Definition
|
||
|
||
To: ietf-mime-direct@imc.org
|
||
Subject: Registration of text/directory MIME type END
|
||
|
||
Type name: END
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 17]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
Type purpose: To denote the end of a syntactic entity within a
|
||
text/directory content-type.
|
||
|
||
Type encoding: 8bit
|
||
|
||
Type valuetype: text, containing a profile name, registered as
|
||
described in Section 9 of this document or bilaterally-agreed upon as
|
||
described in Section 5.
|
||
|
||
Type special notes: The END type is used in conjunction with the
|
||
BEGIN type to delimit a profile containing a related set of
|
||
properties within an text/directory content-type. This construct can
|
||
be used instead of or in addition to wrapping separate sets of
|
||
information inside additional MIME headers. It is provided for
|
||
applications that wish to define content that can contain multiple
|
||
entities within the same text/directory content-type or to define
|
||
content that can be identifiable outside of a MIME environment.
|
||
|
||
Type example:
|
||
END: VCARD
|
||
|
||
7. Use of the multipart/related Content-Type
|
||
|
||
The multipart/related Content-Type can be used to hold directory
|
||
information comprised of both text and non-text information or
|
||
directory information that already has a natural MIME representation.
|
||
The root body part within the multipart/related body part is
|
||
specified as defined in [RFC-2112] by a "start" parameter, or it is
|
||
the first body part in the absence of such a parameter. The root
|
||
body part must have a Content-Type of "text/directory". This part
|
||
holds inline information and makes reference to subsequent body parts
|
||
holding additional text or non-text directory information via their
|
||
Content-ID URIs as explained in Section 5.
|
||
|
||
The body parts referred to do not have to be in any particular order,
|
||
except as noted above for the root body part.
|
||
|
||
8. Examples
|
||
|
||
The following examples are for illustrative purposes only and are not
|
||
part of the definition.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 18]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
8.1. Example 1
|
||
|
||
The first example illustrates simple use of the text/directory
|
||
Content-Type. Note that no "profile" parameter is given, so an
|
||
application may not know what kind of directory entity the
|
||
information applies to. Note also the use of both hypothetical
|
||
official and bilaterally agreed upon types.
|
||
|
||
From: Whomever@wherever.com
|
||
To: Someone@somewhere.com
|
||
Subject: whatever
|
||
MIME-Version: 1.0
|
||
Message-ID: <id1@host.net>
|
||
Content-Type: text/directory
|
||
Content-ID: <id2@host.com>
|
||
|
||
cn:Babs Jensen
|
||
cn:Barbara J Jensen
|
||
sn:Jensen
|
||
email:babs@umich.edu
|
||
phone:+1 313 747-4454
|
||
x-id:1234567890
|
||
|
||
8.2. Example 2
|
||
|
||
The next example illustrates the use of the Quoted-Printable transfer
|
||
encoding defined in [RFC 2045] to include non-ASCII character in some
|
||
of the information returned, and the use of the optional "name" and
|
||
"source" types. It also illustrates the use of an "encoding" type
|
||
parameter to encode a certificate value in "b". A "vCard" profile
|
||
[MIME- VCARD] is used for the example.
|
||
|
||
Content-Type: text/directory;
|
||
charset="iso-8859-1";
|
||
profile="vCard"
|
||
Content-ID: <id3@host.com>
|
||
Content-Transfer-Encoding: Quoted-Printable
|
||
|
||
begin:VCARD
|
||
source:ldap://cn=bjorn%20Jensen, o=university%20of%20Michigan, c=US
|
||
name:Bjorn Jensen
|
||
fn:Bj=F8rn Jensen
|
||
n:Jensen;Bj=F8rn
|
||
email;type=internet:bjorn@umich.edu
|
||
tel;type=work,voice,msg:+1 313 747-4454
|
||
key;type=x509;encoding=B:dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK
|
||
end:VCARD
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 19]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
8.3. Example 3
|
||
|
||
The next example illustrates the use of multi-valued type parameters,
|
||
the "language" type parameter, the "value" type parameter, folding of
|
||
long lines, the \n encoding for formatted lines, attribute grouping,
|
||
and the inline "b" encoding. A "vCard" profile [MIME-VCARD] is used
|
||
for the example.
|
||
|
||
Content-Type: text/directory; profile="vcard"; charset=iso-8859-1
|
||
Content-ID: <id3@host.com>
|
||
Content-Transfer-Encoding: Quoted-Printable
|
||
|
||
begin:vcard
|
||
source:ldap://cn=Meister%20Berger,o=Universitaet%20Goerlitz,c=DE
|
||
name:Meister Berger
|
||
fn:Meister Berger
|
||
n:Berger;Meister
|
||
bday;value=date:1963-09-21
|
||
o:Universit=E6t G=F6rlitz
|
||
title:Mayor
|
||
title;language=de;value=text:Burgermeister
|
||
note:The Mayor of the great city of
|
||
Goerlitz in the great country of Germany.
|
||
email;internet:mb@goerlitz.de
|
||
home.tel;type=fax,voice,msg:+49 3581 123456
|
||
home.label:Hufenshlagel 1234\n
|
||
02828 Goerlitz\n
|
||
Deutschland
|
||
key;type=X509;encoding=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQ
|
||
AwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zI
|
||
ENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQD
|
||
ExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNjE5NDc1OVoXDTk3MTIwMzE5NDc
|
||
1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYDVQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW
|
||
9ucyBDb3JwLjEYMBYGA1UEAxMPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBF
|
||
hJob3dlc0BuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqG
|
||
SIb3DQEBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2dXc
|
||
oX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MBEGCWCGSAGG+E
|
||
IBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9
|
||
w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIPmx93HGp0Kgyx1jIVMyNgsemeAwBM+M
|
||
SlhMfcpbTrONwNjZYW8vJDSoi//yrZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8V
|
||
UMk1U7jt8LYpo4YULU7UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==
|
||
end:vcard
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 20]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
8.4. Example 4
|
||
|
||
The final example illustrates the use of the multipart/related
|
||
Content-Type to include non-textual directory data via the "uri"
|
||
encoding to refer to other body parts within the same message, or to
|
||
external values. Note that no "profile" parameter is given, so an
|
||
application may not know what kind of directory entity the
|
||
information applies to. Note also the use of both hypothetical
|
||
official and bilaterally agreed upon types.
|
||
|
||
Content-Type: multipart/related;
|
||
boundary=woof;
|
||
type="text/directory";
|
||
start="<id5@host.com>"
|
||
Content-ID: <id4@host.com>
|
||
|
||
--woof
|
||
Content-Type: text/directory; charset="iso-8859-1"
|
||
Content-ID: <id5@host.com>
|
||
Content-Transfer-Encoding: Quoted-Printable
|
||
|
||
source:ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US
|
||
cn:Bj=F8rn Jensen
|
||
sn:Jensen
|
||
email:bjorn@umich.edu
|
||
image;value=uri:cid:id6@host.com
|
||
image;value=uri;format=jpeg:ftp://some.host/some/path.jpg
|
||
sound;value=uri:cid:id7@host.com
|
||
phone:+1 313 747-4454
|
||
|
||
--woof
|
||
Content-Type: image/jpeg
|
||
Content-ID: <id6@host.com>
|
||
|
||
<...image data...>
|
||
|
||
--woof
|
||
Content-Type: message/external-body;
|
||
name="myvoice.au";
|
||
site="myhost.com";
|
||
access-type=ANON-FTP;
|
||
directory="pub/myname";
|
||
mode="image"
|
||
|
||
Content-Type: audio/basic
|
||
Content-ID: <id7@host.com>
|
||
|
||
--woof--
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 21]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
9. Registration of new profiles
|
||
|
||
This section defines procedures by which new profiles are registered
|
||
with the IANA and made available to the Internet community. Note that
|
||
non-IANA profiles can be used by bilateral agreement, provided the
|
||
associated profile names follow the "X-" convention defined above.
|
||
|
||
The procedures defined here are designed to allow public comment and
|
||
review of new profiles, while posing only a small impediment to the
|
||
definition of new profiles.
|
||
|
||
Registration of a new profile is accomplished by the following steps.
|
||
|
||
9.1. Define the profile
|
||
|
||
A profile is defined by completing the following template.
|
||
|
||
To: ietf-mime-direct@imc.org
|
||
Subject: Registration of text/directory MIME profile XXX
|
||
|
||
Profile name:
|
||
|
||
Profile purpose:
|
||
|
||
Profile types:
|
||
|
||
Profile special notes (optional):
|
||
|
||
Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
|
||
|
||
The explanation of what goes in each field in the template follows.
|
||
|
||
Profile name: The name of the profile as it will appear in the
|
||
text/directory MIME Content-Type "profile" header parameter, or the
|
||
predefined "profile" type name.
|
||
|
||
Profile purpose: The purpose of the profile (e.g., to represent
|
||
information about people, printers, documents, etc.). Give a short
|
||
but clear description.
|
||
|
||
Profile types: The list of types associated with the profile. This
|
||
list of types is to be expected but not required in the profile,
|
||
unless otherwise noted in the profile definition. Other types not
|
||
mentioned in the profile definition MAY also be present. Note that
|
||
any new types referenced by the profile MUST be defined separately as
|
||
described in Section 10.
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 22]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
Profile special notes: Any special notes about the profile, how it is
|
||
to be used, etc. This section of the template can also be used to
|
||
define an ordering on the types that appear in the Content-Type, if
|
||
such an ordering is required.
|
||
|
||
9.2. Post the profile definition
|
||
|
||
The profile description must be posted to the new profile discussion
|
||
list, ietf-mime-direct@imc.org
|
||
|
||
9.3. Allow a comment period
|
||
|
||
Discussion on the new profile must be allowed to take place on the
|
||
list for a minimum of two weeks. Consensus must be reached on the
|
||
profile before proceeding to step 4.
|
||
|
||
9.4. Submit the profile for approval
|
||
|
||
Once the two-week comment period has elapsed, and the proposer is
|
||
convinced consensus has been reached on the profile, the registration
|
||
application should be submitted to the Profile Reviewer for approval.
|
||
The Profile Reviewer is appointed by the Application Area Directors
|
||
and can either accept or reject the profile registration. An accepted
|
||
registration is passed on by the Profile Reviewer to the IANA for
|
||
inclusion in the official IANA profile registry. The registration may
|
||
be rejected for any of the following reasons. 1) Insufficient comment
|
||
period; 2) Consensus not reached; 3) Technical deficiencies raised on
|
||
the list or elsewhere have not been addressed. The Profile Reviewer's
|
||
decision to reject a profile can be appealed by the proposer to the
|
||
IESG, or the objections raised can be addressed by the proposer and
|
||
the profile resubmitted.
|
||
|
||
10. Profile Change Control
|
||
|
||
Existing profiles can be changed using the same process by which they
|
||
were registered.
|
||
|
||
Define the change
|
||
|
||
Post the change
|
||
|
||
Allow a comment period
|
||
|
||
Submit the changed profile for approval
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 23]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
Note that the original author or any other interested party can
|
||
propose a change to an existing profile, but that such changes should
|
||
only be proposed when there are serious omissions or errors in the
|
||
published specification. The Profile Reviewer can object to a change
|
||
if it is not backwards compatible, but is not required to do so.
|
||
|
||
Profile definitions can never be deleted from the IANA registry, but
|
||
profiles which are no longer believed to be useful can be declared
|
||
OBSOLETE by a change to their "intended use" field.
|
||
|
||
11. Registration of new types
|
||
|
||
This section defines procedures by which new types are registered
|
||
with the IANA. Note that non-IANA types can be used by bilateral
|
||
agreement, provided the associated types names follow the "X-"
|
||
convention defined above.
|
||
|
||
The procedures defined here are designed to allow public comment and
|
||
review of new types, while posing only a small impediment to the
|
||
definition of new types.
|
||
|
||
Registration of a new type is accomplished by the following steps.
|
||
|
||
11.1. Define the type
|
||
|
||
A type is defined by completing the following template.
|
||
|
||
To: ietf-mime-direct@imc.org
|
||
Subject: Registration of text/directory MIME type XXX
|
||
|
||
Type name:
|
||
|
||
Type purpose:
|
||
|
||
Type encoding:
|
||
|
||
Type valuetype:
|
||
|
||
Type special notes (optional):
|
||
|
||
Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
|
||
|
||
The meaning of each field in the template is as follows.
|
||
|
||
Type name: The name of the type, as it will appear in the body of an
|
||
text/directory MIME Content-Type "type: value" line to the left of
|
||
the colon ":".
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 24]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
Type purpose: The purpose of the type (e.g., to represent a name,
|
||
postal address, IP address, etc.). Give a short but clear
|
||
description.
|
||
|
||
Type encoding: The default encoding a value of the type must have in
|
||
the body of a text/directory MIME Content-Type.
|
||
|
||
Type valuetype: The format a value of the type must have in the body
|
||
of a text/directory MIME Content-Type. This description must be
|
||
precise and must not violate the general encoding rules defined in
|
||
section 5 of this document.
|
||
|
||
Type special notes: Any special notes about the type, how it is to be
|
||
used, etc.
|
||
|
||
11.2. Post the type definition
|
||
|
||
The type description must be posted to the new type discussion list,
|
||
ietf-mime-direct@imc.org
|
||
|
||
11.3. Allow a comment period
|
||
|
||
Discussion on the new type must be allowed to take place on the list
|
||
for a minimum of two weeks. Consensus must be reached on the type
|
||
before proceeding to step 4.
|
||
|
||
11.4. Submit the type for approval
|
||
|
||
Once the two-week comment period has elapsed, and the proposer is
|
||
convinced consensus has been reached on the type, the registration
|
||
application should be submitted to the Profile Reviewer for approval.
|
||
The Profile Reviewer is appointed by the Application Area Directors
|
||
and can either accept or reject the type registration. An accepted
|
||
registration is passed on by the Profile Reviewer to the IANA for
|
||
inclusion in the official IANA profile registry. The registration can
|
||
be rejected for any of the following reasons. 1) Insufficient comment
|
||
period; 2) Consensus not reached; 3) Technical deficiencies raised on
|
||
the list or elsewhere have not been addressed. The Profile
|
||
Reviewer's decision to reject a type can be appealed by the proposer
|
||
to the IESG, or the objections raised can be addressed by the
|
||
proposer and the type resubmitted.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 25]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
12. Type Change Control
|
||
|
||
Existing types can be changed using the same process by which they
|
||
were registered.
|
||
|
||
Define the change
|
||
|
||
Post the change
|
||
|
||
Allow a comment period
|
||
|
||
Submit the type for approval
|
||
|
||
Note that the original author or any other interested party can
|
||
propose a change to an existing type, but that such changes should
|
||
only be proposed when there are serious omissions or errors in the
|
||
published specification. The Profile Reviewer can object to a change
|
||
if it is not backwards compatible, but is not required to do so.
|
||
|
||
Type definitions can never be deleted from the IANA registry, but
|
||
types which are nolonger believed to be useful can be declared
|
||
OBSOLETE by a change to their "intended use" field.
|
||
|
||
13. Registration of new parameters
|
||
|
||
This section defines procedures by which new parameters are
|
||
registered with the IANA and made available to the Internet
|
||
community. Note that non-IANA parameters can be used by bilateral
|
||
agreement, provided the associated parameters names follow the "X-"
|
||
convention defined above.
|
||
|
||
The procedures defined here are designed to allow public comment and
|
||
review of new parameters, while posing only a small impediment to the
|
||
definition of new parameters.
|
||
|
||
Registration of a new parameter is accomplished by the following
|
||
steps.
|
||
|
||
13.1. Define the parameter
|
||
|
||
A parameter is defined by completing the following template.
|
||
|
||
To: ietf-mime-direct@imc.org
|
||
Subject: Registration of text/directory MIME type parameter XXX
|
||
|
||
Parameter name:
|
||
|
||
Parameter purpose:
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 26]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
Parameter values:
|
||
|
||
Parameter special notes (optional):
|
||
|
||
Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
|
||
|
||
The explanation of what goes in each field in the template follows.
|
||
|
||
Parameter name: The name of the parameter as it will appear in the
|
||
text/directory MIME Content-Type.
|
||
|
||
Parameter purpose: The purpose of the parameter (e.g., to represent
|
||
the format of an image, type of a phone number, etc.). Give a short
|
||
but clear description. If defining a general paramemter like "format"
|
||
or "type" keep in mind that other applications might wish to extend
|
||
its use.
|
||
|
||
Parameter values: The list or description of values associated with
|
||
the parameter.
|
||
|
||
Parameter special notes: Any special notes about the parameter, how
|
||
it is to be used, etc.
|
||
|
||
13.2. Post the parameter definition
|
||
|
||
The parameter description must be posted to the new parameter
|
||
discussion list, ietf-mime-direct@imc.org
|
||
|
||
13.3. Allow a comment period
|
||
|
||
Discussion on the new parameter must be allowed to take place on the
|
||
list for a minimum of two weeks. Consensus must be reached on the
|
||
parameter before proceeding to step 4.
|
||
|
||
13.4. Submit the parameter for approval
|
||
|
||
Once the two-week comment period has elapsed, and the proposer is
|
||
convinced consensus has been reached on the parameter, the
|
||
registration application should be submitted to the Profile Reviewer
|
||
for approval. The Profile Reviewer is appointed by the Application
|
||
Area Directors and can either accept or reject the parameter
|
||
registration. An accepted registration is passed on by the Profile
|
||
Reviewer to the IANA for inclusion in the official IANA parameter
|
||
registry. The registration can be rejected for any of the following
|
||
reasons. 1) Insufficient comment period; 2) Consensus not reached; 3)
|
||
Technical deficiencies raised on the list or elsewhere have not been
|
||
addressed. The Profile Reviewer's decision to reject a profile can be
|
||
appealed by the proposer to the IESG, or the objections raised can be
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 27]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
addressed by the proposer and the parameter registration resubmitted.
|
||
|
||
14. Parameter Change Control
|
||
|
||
Existing parameters can be changed using the same process by which
|
||
they were registered.
|
||
|
||
Define the change
|
||
|
||
Post the change
|
||
|
||
Allow a comment period
|
||
|
||
Submit the parameter for approval
|
||
|
||
Note that the original author or any other interested party can
|
||
propose a change to an existing parameter, but that such changes
|
||
should only be proposed when there are serious omissions or errors in
|
||
the published specification. The Profile Reviewer can object to a
|
||
change if it is not backwards compatible, but is not required to do
|
||
so.
|
||
|
||
Parameter definitions can never be deleted from the IANA registry,
|
||
but parameters which are nolonger believed to be useful can be
|
||
declared OBSOLETE by a change to their "intended use" field.
|
||
|
||
15. Registration of new value types
|
||
|
||
This section defines procedures by which new value types are
|
||
registered with the IANA and made available to the Internet
|
||
community. Note that non-IANA value types can be used by bilateral
|
||
agreement, provided the associated value types names follow the "X-"
|
||
convention defined above.
|
||
|
||
The procedures defined here are designed to allow public comment and
|
||
review of new value types, while posing only a small impediment to
|
||
the definition of new value types.
|
||
|
||
Registration of a new value types is accomplished by the following
|
||
steps.
|
||
|
||
15.1. Define the value type
|
||
|
||
A value type is defined by completing the following template.
|
||
|
||
To: ietf-mime-direct@imc.org
|
||
Subject: Registration of text/directory MIME value type XXX
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 28]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
value type name:
|
||
|
||
value type purpose:
|
||
|
||
value type format:
|
||
|
||
value type special notes (optional):
|
||
|
||
Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
|
||
|
||
The explanation of what goes in each field in the template follows.
|
||
|
||
value type name: The name of the value type as it will appear in the
|
||
text/directory MIME Content-Type.
|
||
|
||
value type purpose: The purpose of the value type. Give a short but
|
||
clear description.
|
||
|
||
value type format: The definition of the format for the value,
|
||
usually using ABNF grammar.
|
||
|
||
value type special notes: Any special notes about the value type, how
|
||
it is to be used, etc.
|
||
|
||
15.2. Post the value type definition
|
||
|
||
The value type description must be posted to the new value type
|
||
discussion list, ietf-mime-direct@imc.org
|
||
|
||
15.3. Allow a comment period
|
||
|
||
Discussion on the new value type must be allowed to take place on the
|
||
list for a minimum of two weeks. Consensus must be reached before
|
||
proceeding to step 4.
|
||
|
||
15.4. Submit the value type for approval
|
||
|
||
Once the two-week comment period has elapsed, and the proposer is
|
||
convinced consensus has been reached on the value type, the
|
||
registration application should be submitted to the Profile Reviewer
|
||
for approval. The Profile Reviewer is appointed by the Application
|
||
Area Directors and can either accept or reject the value type
|
||
registration. An accepted registration should be passed on by the
|
||
Profile Reviewer to the IANA for inclusion in the official IANA value
|
||
type registry. The registration can be rejected for any of the
|
||
following reasons. 1) Insufficient comment period; 2) Consensus not
|
||
reached; 3) Technical deficiencies raised on the list or elsewhere
|
||
have not been addressed. The Profile Reviewer's decision to reject a
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 29]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
profile can be appealed by the proposer to the IESG, or the
|
||
objections raised can be addressed by the proposer and the value type
|
||
registration resubmitted.
|
||
|
||
16. Security Considerations
|
||
|
||
Internet mail is subject to many well known security attacks,
|
||
including monitoring, replay, and forgery. Care should be taken by
|
||
any directory service in allowing information to leave the scope of
|
||
the service itself, where any access controls can no longer be
|
||
guaranteed. Applications should also take care to display directory
|
||
data in a "safe" environment (e.g., PostScript-valued types).
|
||
|
||
17. Acknowledgements
|
||
|
||
The registration procedures defined here were shamelessly lifted from
|
||
the MIME registration RFC.
|
||
|
||
The many valuable comments contributed by members of the IETF ASID
|
||
working group are gratefully acknowledged, as are the contributions
|
||
of the Versit Consortium. Chris Newman was especially helpful in
|
||
navigating the intricacies of ABNF lore.
|
||
|
||
18. References
|
||
|
||
[RFC-1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
|
||
Directory Access Protocol", RFC 1777, March 1995.
|
||
|
||
[RFC-1778] Howes, T., Kille, S., Yeong, W., and C. Robbins, "The
|
||
String Representation of Standard Attribute Syntaxes",
|
||
RFC 1778, March 1995.
|
||
|
||
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
|
||
Text Messages", STD 11, RFC 822, August 1982.
|
||
|
||
[RFC-2045] Borenstein, N., and N. Freed, "Multipurpose Internet
|
||
Mail Extensions (MIME) Part One: Format of Internet
|
||
Message Bodies", RFC 2045, November 1996.
|
||
|
||
[RFC-2046] Moore, K., "Multipurpose Internet Mail Extensions (MIME)
|
||
Part Two: Media Types", RFC 2046, November 1996.
|
||
|
||
[RFC-2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
|
||
Internet Mail Extensions (MIME) Part Four: Registration
|
||
Procedures", RFC 2048, November 1996.
|
||
|
||
[RFC-1766] Alvestrand, H., "Tags for the Identification of
|
||
Languages", RFC 1766, March 1995.
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 30]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
[RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type",
|
||
RFC 2112, March 1997.
|
||
|
||
[X500] "Information Processing Systems - Open Systems
|
||
Interconnection - The Directory: Overview of Concepts,
|
||
Models and Services", ISO/IEC JTC 1/SC21, International
|
||
Standard 9594-1, 1988.
|
||
|
||
[RFC-1835] Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider,
|
||
"Architecture of the WHOIS++ service", RFC 1835, August
|
||
1995.
|
||
|
||
[RFC-1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
|
||
Resource Locators (URL)", RFC 1738, December 1994.
|
||
|
||
[MIME-VCARD] Dawson, F., and T. Howes, "VCard MIME Directory
|
||
Profile", RFC 2426, September 1998.
|
||
|
||
[VCARD] Internet Mail Consortium, "vCard - The Electronic
|
||
Business Card", Version 2.1,
|
||
http://www.imc.com/pdi/vcard-21.txt, September, 1996.
|
||
|
||
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC-2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
|
||
Specifications: ABNF", RFC 2234, November 1997.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 31]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
19. Authors' Addresses
|
||
|
||
Tim Howes
|
||
Netscape Communications Corp.
|
||
501 East Middlefield Rd.
|
||
Mountain View, CA 94041
|
||
USA
|
||
|
||
Phone: +1.415.937.3419
|
||
EMail: howes@netscape.com
|
||
|
||
|
||
Mark Smith
|
||
Netscape Communications Corp.
|
||
501 East Middlefield Rd.
|
||
Mountain View, CA 94041
|
||
USA
|
||
|
||
Phone: +1.415.937.3477
|
||
EMail: mcs@netscape.com
|
||
|
||
|
||
Frank Dawson
|
||
Lotus Development Corporation
|
||
6544 Battleford Drive
|
||
Raleigh, NC 27613
|
||
USA
|
||
|
||
Phone: +1-919-676-9515
|
||
EMail: frank_dawson@lotus.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 32]
|
||
|
||
RFC 2425 MIME Content-Type for Directory Information September 1998
|
||
|
||
|
||
20. Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
or assist in its implementation may be prepared, copied, published
|
||
and distributed, in whole or in part, without restriction of any
|
||
kind, provided that the above copyright notice and this paragraph are
|
||
included on all such copies and derivative works. However, this
|
||
document itself may not be modified in any way, such as by removing
|
||
the copyright notice or references to the Internet Society or other
|
||
Internet organizations, except as needed for the purpose of
|
||
developing Internet standards in which case the procedures for
|
||
copyrights defined in the Internet Standards process must be
|
||
followed, or as required to translate it into languages other than
|
||
English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Howes, et. al. Standards Track [Page 33]
|
||
|