📄 rfc2425.txt
字号:
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -