diff options
Diffstat (limited to 'vendor/sabre/dav/docs/rfc2425.txt')
| -rw-r--r-- | vendor/sabre/dav/docs/rfc2425.txt | 1851 |
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] - |