aboutsummaryrefslogtreecommitdiffstats
path: root/vendor/sabre/dav/docs/rfc2425.txt
diff options
context:
space:
mode:
authorKlaus Weidenbach <Klaus.Weidenbach@gmx.net>2014-06-28 22:28:08 +0200
committerKlaus Weidenbach <Klaus.Weidenbach@gmx.net>2014-06-29 01:17:07 +0200
commit03b31d113ea316c8384a4cbf3d27ca22bb528eac (patch)
tree92ed87436b09ab806f9effff08145408044d77f4 /vendor/sabre/dav/docs/rfc2425.txt
parentf49b74c5f6ebe57937fb6dfea7d2e917f4680ce9 (diff)
downloadvolse-hubzilla-03b31d113ea316c8384a4cbf3d27ca22bb528eac.tar.gz
volse-hubzilla-03b31d113ea316c8384a4cbf3d27ca22bb528eac.tar.bz2
volse-hubzilla-03b31d113ea316c8384a4cbf3d27ca22bb528eac.zip
Update SabreDAV from 1.8.9 to 1.8.10.
Diffstat (limited to 'vendor/sabre/dav/docs/rfc2425.txt')
-rw-r--r--vendor/sabre/dav/docs/rfc2425.txt1851
1 files changed, 0 insertions, 1851 deletions
diff --git a/vendor/sabre/dav/docs/rfc2425.txt b/vendor/sabre/dav/docs/rfc2425.txt
deleted file mode 100644
index 2e37e24a4..000000000
--- a/vendor/sabre/dav/docs/rfc2425.txt
+++ /dev/null
@@ -1,1851 +0,0 @@
-
-
-
-
-
-
-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]
-