7 Network Working Group T. Howes
8 Request for Comments: 2425 M. Smith
9 Category: Standards Track Netscape Communications Corp.
11 Lotus Development Corporation
15 A MIME Content-Type for Directory Information
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
27 Copyright (C) The Internet Society (1998). All Rights Reserved.
31 This document defines a MIME Content-Type for holding directory
32 information. The definition is independent of any particular
33 directory service or protocol. The text/directory Content-Type is
34 defined for holding a variety of directory information, for example,
35 name, or email address, or logo. The text/directory Content-Type can
36 also be used as the root body part in a multipart/related Content-
37 Type for handling more complicated situations, especially those in
38 which non-textual information that already has a natural MIME
39 representation, for example, a photograph or sound, is to be
42 The text/directory Content-Type defines a general framework and
43 format for holding directory information in a simple "type:value"
44 form. We refer to "type" in this context meaning a property or
45 attribute with which the value is associated. Mechanisms are defined
46 to specify alternate languages, encodings and other meta-information.
47 This document also defines the procedure by which particular formats,
48 called profiles, for carrying application-specific information within
49 a text/directory Content-Type can be defined and registered, and the
50 conventions such formats must follow. It is expected that other
51 documents will be produced that define such formats for various
52 applications (e.g., white pages).
58 Howes, et. al. Standards Track [Page 1]
60 RFC 2425 MIME Content-Type for Directory Information September 1998
63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
65 document are to be interpreted as described in [RFC-2119].
69 Status of the Memo................................................ 1
70 Copyright Notice.................................................. 1
71 1. Abstract...................................................... 1
72 2. Table of Contents............................................. 2
73 3. Need for a MIME Directory Type................................ 3
74 4. Overview...................................................... 4
75 5. The text/directory Content-Type............................... 4
76 5.1. MIME media type name........................................ 4
77 5.2. MIME subtype name........................................... 5
78 5.3. Required parameters......................................... 5
79 5.4. Optional parameters......................................... 5
80 5.5. Encoding considerations..................................... 5
81 5.6. Security considerations..................................... 6
82 5.7. Interoperability considerations............................. 6
83 5.8. Published specification..................................... 6
84 5.8.1. Line delimiting and folding............................... 6
85 5.8.2. ABNF content-type definition.............................. 7
86 5.8.3. Pre-defined Parameters.................................... 9
87 5.8.4. Pre-defined Value Types...................................11
88 5.9. Applications which use this media type......................14
89 5.10. Additional information.....................................14
90 5.11. Person & email address to contact for further information..14
91 5.12. Intended usage.............................................14
92 5.13. Author/Change controller...................................15
93 6. Predefined Types..............................................15
94 6.1. SOURCE Type Definition......................................15
95 6.2. NAME Type Definition........................................16
96 6.3. PROFILE Type Definition.....................................16
97 6.4. BEGIN Type Definition.......................................17
98 6.5. END Type Definition.........................................17
99 7. Use of the multipart/related Content-Type.....................18
100 8. Examples.......................................................18
101 8.1. Example 1...................................................19
102 8.2. Example 2...................................................19
103 8.3. Example 3...................................................20
104 8.4. Example 4...................................................21
105 9. Registration of new profiles..................................22
106 9.1. Define the profile..........................................22
107 9.2. Post the profile definition.................................23
108 9.3. Allow a comment period......................................23
109 9.4. Submit the profile for approval.............................23
110 10. Profile Change Control.......................................23
114 Howes, et. al. Standards Track [Page 2]
116 RFC 2425 MIME Content-Type for Directory Information September 1998
119 11. Registration of new types....................................24
120 11.1. Define the type............................................24
121 11.2. Post the type definition...................................25
122 11.3. Allow a comment period.....................................25
123 11.4. Submit the type for approval...............................25
124 12. Type Change Control..........................................25
125 13. Registration of new parameters...............................26
126 13.1. Define the parameter.......................................26
127 13.2. Post the parameter definition..............................27
128 13.3. Allow a comment period.....................................27
129 13.4. Submit the parameter for approval..........................27
130 14. Parameter Change Control.....................................28
131 15. Registration of new value types..............................28
132 15.1. Define the value type......................................28
133 15.2. Post the value type definition.............................29
134 15.3. Allow a comment period.....................................29
135 15.4. Submit the value type for approval.........................29
136 16. Security Considerations......................................30
137 17. Acknowledgements..............................................30
138 18. References....................................................30
139 19. Authors' Addresses...........................................32
140 20. Full Copyright Statement......................................33
142 3. Need for a MIME Directory Type
144 For purposes of this document, a directory is a special-purpose
145 database that contains typed information. A directory usually
146 supports both read and search of the information it contains, and can
147 support creation and modification of the information as well.
148 Directory information is usually accessed far more often than it is
149 updated. Directories can be local or global in scope. They can be
150 distributed or centralized. The information they contain can be
151 replicated, with weak or strong consistency requirements.
153 There are several situations in which users of Internet mail might
154 wish to exchange directory information: the email analogy of a
155 "business card" exchange; the conveyance of directory information to
156 a user having only email access to the Internet; the provision of
157 machine-parseable address information when purchasing goods or
158 services over the Internet; etc. As MIME [RFC-2045, RFC-2046] is
159 used increasingly by other protocols, most notably HTTP, it can also
160 be useful for these protocols to carry directory information in MIME
161 format. Such a format, for example, could be used to represent URC
162 (uniform resource characteristics) information about resources on the
163 World Wide Web, or to provide a rudimentary directory service over
170 Howes, et. al. Standards Track [Page 3]
172 RFC 2425 MIME Content-Type for Directory Information September 1998
177 The scheme defined here for representing directory information in a
178 MIME Content-Type has two parts. First, the text/directory Content-
179 Type is defined for use in holding directory information within a
180 single body part, for example name, title, or email address. In its
181 simplest form, the format uses a "type:value" approach, which should
182 be easily parseable by existing MIME implementations and
183 understandable by users. More complicated situations can be
184 represented also. This document defines the general form the
185 information in the Content-Type should have, and the procedure by
186 which specific types and values (properties) for particular
187 applications can be defined. The framework is general enough to
188 handle information from any number of end directory services,
189 including LDAP [RFC-1777, RFC-1778], WHOIS++ [RFC-1835], and X.500
192 Directory entries can include far more than just textual information.
193 Some such information (e.g., an image or sound) overlaps with
194 predefined MIME Content-Types. In these cases it can be desirable to
195 include the information in its well-known MIME format. This situation
196 is handled by using a multipart/related Content-Type as defined in
197 [RFC-2112]. The root component of this type is a text/directory body
198 part specifying any in-line information, and for information
199 contained in other Content-Types, the Content-IDs (in URI form) of
202 In some applications, it can be useful to include a pointer (e.g, a
203 URI) to some directory information rather than the information
204 itself. This document defines a general mechanism for accomplishing
207 5. The text/directory Content-Type
209 The text/directory Content-Type is used to hold basic directory
210 information and URIs referencing other information, including other
211 MIME body parts holding supplementary or non-textual directory
212 information, such as an image or sound. It is defined as follows,
213 using the MIME media type registration template from [RFC-2048].
215 To: ietf-types@uninett.no
216 Subject: Registration of MIME media type text/directory
218 5.1. MIME media type name
220 MIME media type name: text
226 Howes, et. al. Standards Track [Page 4]
228 RFC 2425 MIME Content-Type for Directory Information September 1998
231 5.2. MIME subtype name
233 MIME subtype name: directory
235 5.3. Required parameters
237 Required parameters: charset
239 The "charset" parameter is as defined in [RFC-2046] for other body
240 parts. It is used to identify the default character set used within
243 5.4. Optional parameters
245 Optional parameters: profile
247 The "profile" parameter is used to convey the type(s) of entity(ies)
248 to which the directory information pertains and the likely set of
249 information associated with the entity(ies). It is intended only as a
250 guide to applications interpreting the information contained within
251 the body part. It SHOULD NOT be used to exclude or require particular
252 pieces of information unless a profile definition specifically calls
253 for this behavior. Unless specifically forbidden by a particular
254 profile definition, a text/directory content type can contain
255 arbitrary attribute/value pairs.
257 The value of the "profile" parameter is defined as follows. Profile
258 names are case insensitive (i.e., the profile name "vCard" is the
259 same as "VCARD" and "vcard" and "vcArD").
261 profile = x-name / iana-token
263 x-name = "x-" 1*(ALPHA / DIGIT / "-")
264 ; Names beginning with "x-" or "X-" are
265 ; reserved for experimental use not intended for released
266 ; products, or for use in bilateral agreements.
268 iana-token = <a publicly-defined extension token, registered
269 with IANA, as specified in Section 9 of this
272 5.5. Encoding considerations
274 The default encoding is 8bit. Otherwise, as specified by the
275 Content-Transfer-Encoding header field.
282 Howes, et. al. Standards Track [Page 5]
284 RFC 2425 MIME Content-Type for Directory Information September 1998
287 5.6. Security considerations
289 Directory information can be public or it can be protected from
290 unauthorized access by the directory service in which it resides.
291 Once the information leaves its native service, there can be no
292 guarantee that the same care will be taken by all services handling
293 the information. Furthermore, this specification defines no access
294 control mechanism by which information can be protected, or by which
295 access control information can be conveyed. Note that the integrity
296 and privacy of a text/directory body part can be protected by
297 enclosing it within an appropriate MIME-based security mechanism.
299 5.7. Interoperability considerations
301 In order to make sense of directory information, applications must
302 share a common understanding of the types of information contained
303 within the Content-Type (the directory schema). This schema
304 information is not defined in this document, but rather in companion
305 documents (e.g., [MIME-VCARD]) that follow the requirements specified
306 in this document, or in bilateral agreements between communicating
309 5.8. Published specification
311 The text/directory Content-Type contains directory information,
312 typically pertaining to a single directory entity or group of
313 entities. The content consists of one or more lines in the format
316 5.8.1. Line delimiting and folding
318 Individual lines within the MIME text/directory Content Type body are
319 delimited by the [RFC-822] line break, which is a CRLF sequence
320 (ASCII decimal 13, followed by ASCII decimal 10). Long logical lines
321 of text can be split into a multiple-physical-line representation
322 using the following folding technique.
324 A logical line MAY be continued on the next physical line anywhere
325 between two characters by inserting a CRLF immediately followed by a
326 single white space character (space, ASCII decimal 32, or horizontal
327 tab, ASCII decimal 9). At least one character must be present on the
328 folded line. Any sequence of CRLF followed immediately by a single
329 white space character is ignored (removed) when processing the
330 content type. For example the line:
332 DESCRIPTION:This is a long description that exists on a long line.
334 Can be represented as:
338 Howes, et. al. Standards Track [Page 6]
340 RFC 2425 MIME Content-Type for Directory Information September 1998
343 DESCRIPTION:This is a long description
344 that exists on a long line.
346 It could also be represented as:
348 DESCRIPTION:This is a long descrip
352 The process of moving from this folded multiple-line representation
353 of a type definition to its single line representation is called
354 unfolding. Unfolding is accomplished by regarding CRLF immediately
355 followed by a white space character (namely HTAB ASCII decimal 9 or
356 SPACE ASCII decimal 32) as equivalent to no characters at all (i.e.,
357 the CRLF and single white space character are removed).
359 5.8.2. ABNF content-type definition
361 The following ABNF uses the notation of RFC 2234, which also defines
362 CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. After the unfolding of
363 any folded lines as described above, the syntax for a line of this
364 content type is as follows:
366 contentline = [group "."] name *(";" param) ":" value CRLF
367 ; When parsing a content line, folded lines MUST first
368 ; be unfolded according to the unfolding procedure
370 ; When generating a content line, lines longer than 75
371 ; characters SHOULD be folded according to the folding
372 ; procedure described above.
374 group = 1*(ALPHA / DIGIT / "-")
376 name = x-name / iana-token
378 iana-token = 1*(ALPHA / DIGIT / "-")
379 ; identifier registered with IANA
381 x-name = "x-" 1*(ALPHA / DIGIT / "-")
382 ; Names that begin with "x-" or "X-" are
383 ; reserved for experimental use, not intended for released
384 ; products, or for use in bilateral agreements.
386 param = param-name "=" param-value *("," param-value)
388 param-name = x-name / iana-token
390 param-value = ptext / quoted-string
394 Howes, et. al. Standards Track [Page 7]
396 RFC 2425 MIME Content-Type for Directory Information September 1998
402 / valuespec ; valuespec defined in section 5.8.4
404 quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
407 ; use restricted by charset parameter
408 ; on outer MIME object (UTF-8 preferred)
410 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII
411 ; Any character except CTLs, DQUOTE
413 SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII
414 ; Any character except CTLs, DQUOTE, ";", ":", ","
416 VALUE-CHAR = WSP / VCHAR / NON-ASCII
417 ; any textual character
419 A line that begins with a white space character is a continuation of
420 the previous line, as described above. The white space character and
421 immediately preceeding CRLF should be discarded when reconstructing
422 the original line. Note that this line-folding convention differs
423 from that found in RFC 822, in that the sequence <CRLF><WSP> found
424 anywhere in the content indicates a continued line and should be
427 Various type names and the format of the corresponding values are
428 defined as specified in Section 11. Specifications MAY impose
429 ordering on the type constructs within a body part, though none is
430 required by default. The various x-name constructs are used for
431 bilaterally-agreed upon type names, parameter names and parameter
432 values, or for use in experimental settings.
434 Type names and parameter names are case insensitive (e.g., the type
435 name "fn" is the same as "FN" and "Fn"). Parameter values MAY be case
436 sensitive or case insensitive, depending on their definition.
438 The group construct is used to group related attributes together.
439 The group name is a syntactic convention used to indicate that all
440 type names prefaced with the same group name SHOULD be grouped
441 together when displayed by an application. It has no other
442 significance. Implementations that do not understand or support
443 grouping MAY simply strip off any text before a "." to the left of
444 the type name and present the types and values as normal.
450 Howes, et. al. Standards Track [Page 8]
452 RFC 2425 MIME Content-Type for Directory Information September 1998
455 Each attribute defined in the text/directory body MAY have multiple
456 values, if allowed in the definition of the profile in which the
457 attribute is used. The general rule for encoding multi-valued items
458 is to simply create a new content line for each value (including the
459 type name). However, it should be noted that some value types
460 support encoding multiple values in a single content line by
461 separating the values with a comma ",". This approach has been taken
462 for several of the content types defined below (date, time, integer,
463 float), for space-saving reasons.
465 5.8.3. Pre-defined Parameters
467 The following parameters and value types are defined for general use.
469 predefined-param = encodingparm
474 encodingparm = "encoding" "=" encodingtype
476 encodingtype = "b" ; from RFC 2047
477 / iana-token ; registered as described in
478 ; section 15 of this document
480 valuetypeparm = "value" "=" valuetype
482 valuetype = "uri" ; genericurl from secion 5 of RFC 1738
486 / "date-time" ; date time
491 / iana-token ; registered as described in
492 ; section 15 of this document
494 languageparm = "language" "=" Language-Tag
495 ; Language-Tag is defined in section 2 of RFC 1766
497 contextparm = "context" "=" context
506 Howes, et. al. Standards Track [Page 9]
508 RFC 2425 MIME Content-Type for Directory Information September 1998
511 The "language" type parameter is used to identify data in multiple
512 languages. There is no concept of "default" language, except as
513 specified by any "Content-Language" MIME header parameter that is
514 present. The value of the "language" type parameter is a language
515 tag as defined in Section 2 of [RFC-1766].
517 The "context" type parameter is used to identify a context (e.g., a
518 protocol) used in interpreting the value. This is used, for example,
519 in the "source" type, defined below.
521 The "encoding" type parameter is used to specify an alternate
522 encoding for a value. If the value contains a CRLF, it must be
523 encoded, since CRLF is used to separate lines in the content-type
524 itself. Currently, only the "b" encoding is supported.
526 The "b" encoding can also be useful for binary values that are mixed
527 with other text information in the body part (e.g., a certificate).
528 Using a per-value "b" encoding in this case leaves the other
529 information in a more readable form. The encoded base 64 value can be
530 split across multiple physical lines in the content type by using the
531 line folding technique described above.
533 The Content-Transfer-Encoding header field is used to specify the
534 encoding used for the body part as a whole. The "encoding" type
535 parameter is used to specify an encoding for a particular value
536 (e.g., a certificate). In this case, the Content-Transfer-Encoding
537 header might specify "8bit", while the one certificate value might
538 specify an encoding of "b" via an "encoding=b" type parameter.
540 The Content-Transfer-Encoding and the encodings of individual types
541 given by the "encoding" type parameter are independent of one
542 another. When encoding a text/directory body part for transmission,
543 individual type encodings are performed first, then the entire body
544 part is encoded according to the Content-Transfer-Encoding. When
545 decoding a text/directory body part, the Content-Transfer-Encoding is
546 decoded first, and then any individual types with an "encoding" type
547 parameter are decoded.
549 The "value" parameter is optional, and is used to identify the value
550 type (data type) and format of the value. The use of these
551 predefined formats is encouraged even if the value parameter is not
552 explicity used. By defining a standard set of value types and their
553 formats, existing parsing and processing code can be leveraged.
555 Including the value type explicitly as part of each property provides
556 an extra hint to keep parsing simple and support more generalized
557 applications. For example a search engine would not have to know the
558 particular value types for all of the items for which it is
562 Howes, et. al. Standards Track [Page 10]
564 RFC 2425 MIME Content-Type for Directory Information September 1998
567 searching. Because the value type is explicit in the definition, the
568 search engine could look for dates in any item type and provide
569 results that can still be interpreted.
571 5.8.4. Pre-defined Value Types
573 The format for values corresponding to the predefined valuetype
574 specifications given above are defined.
576 valuespec = text-list
577 / genericurl ; from section 5 of RFC 1738
586 text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR)
588 TEXT-LIST-CHAR = "\\" / "\," / "\n"
589 / <any VALUE-CHAR except , or \ or newline>
590 ; Backslashes, newlines, and commas must be encoded.
591 ; \n or \N can be used to encode a newline.
593 date-list = date *("," date)
595 time-list = time *("," time)
597 date-time-list = date "T" time *("," date "T" time)
599 boolean = "TRUE" / "FALSE"
601 integer-list = integer *("," integer)
603 integer = [sign] 1*DIGIT
605 float-list = float *("," float)
607 float = [sign] 1*DIGIT ["." 1*DIGIT]
611 date = date-fullyear ["-"] date-month ["-"] date-mday
613 date-fullyear = 4 DIGIT
618 Howes, et. al. Standards Track [Page 11]
620 RFC 2425 MIME Content-Type for Directory Information September 1998
623 date-month = 2 DIGIT ;01-12
625 date-mday = 2 DIGIT ;01-28, 01-29, 01-30, 01-31
628 time = time-hour [":"] time-minute [":"] time-second [time-secfrac]
631 time-hour = 2 DIGIT ;00-23
633 time-minute = 2 DIGIT ;00-59
635 time-second = 2 DIGIT ;00-60 (leap second)
637 time-secfrac = "," 1*DIGIT
639 time-zone = "Z" / time-numzone
641 time-numzome = sign time-hour [":"] time-minute
643 iana-valuespec = <a publicly-defined valuetype format, registered
644 with IANA, as defined in section 15 of this
647 Some specific notes on the value types and formats:
649 "text": The "text" value type should be used to identify values that
650 contain human-readable text. The character set and language in which
651 the text is represented is controlled by the charset content-header
652 and the language type parameter and content-header.
656 this is one value,this is another
657 this is a single value\, with a comma encoded
659 A formatted text line break in a text value type MUST be represented
660 as the character sequence backslash (ASCII decimal 92) followed by a
661 Latin small letter n (ASCII decimal 110) or a Latin capital letter N
662 (ASCII decimal 78), that is "\n" or "\N".
664 For example a multiple line DESCRIPTION value of:
667 Hyjinx Software Division
670 could be represented as:
674 Howes, et. al. Standards Track [Page 12]
676 RFC 2425 MIME Content-Type for Directory Information September 1998
679 DESCRIPTION:Mythical Manager\nHyjinx Software Division\n
682 demonstrating the \n literal formatted line break technique, the
683 CRLF-followed-by-space line folding technique, and the backslash
686 "uri": The "uri" value type should be used to identify values that
687 are referenced by a URI (including a Content-ID URI), instead of
688 encoded in-line. These value references might be used if the value is
689 too large, or otherwise undesirable to include directly. The format
690 for the URI is as defined in RFC 1738.
693 http://www.foobar.com/my/picture.jpg
694 ldap://ldap.foobar.com/cn=babs%20jensen
696 "date", "time", and "date-time": Each of these value types is based
697 on a subset of the definitions in ISO 8601 standard. Profiles MAY
698 place further restrictions on "date" and "time" values. Multiple
699 "date" and "time" values can be specified using the comma-separated
700 notation, unless restricted by a profile.
704 1996-08-05,1996-11-11
715 Examples for "date-time":
719 1996-10-22T14:00:00Z,1996-08-11T12:34:56Z
721 "boolean": The "boolean" value type is used to express boolen values.
722 These values are case insensitive.
730 Howes, et. al. Standards Track [Page 13]
732 RFC 2425 MIME Content-Type for Directory Information September 1998
735 "integer": The "integer" value type is used to express signed
736 integers in decimal format. If sign is not specified, the value is
737 assumed positive "+". Multiple "integer" values can be specified
738 using the comma-separated notation, unless restricted by a profile.
742 +1234556790,432109876
744 "float": The "float" value type is used to express real numbers. If
745 sign is not specified, the value is assumed positive "+". Multiple
746 "float" values can be specified using the comma-separated notation,
747 unless restricted by a profile.
753 5.9. Applications which use this media type
755 Applications which use this media type: Various
757 5.10. Additional information
759 Additional information: None
761 5.11. Person & email address to contact for further information
764 Netscape Communications Corp.
765 501 East Middlefield Rd.
766 Mountain View, CA 94041
773 Intended usage: COMMON
786 Howes, et. al. Standards Track [Page 14]
788 RFC 2425 MIME Content-Type for Directory Information September 1998
791 5.13. Author/Change controller
794 Netscape Communications Corp.
795 501 East Middlefield Rd.
796 Mountain View, CA 94041
802 Netscape Communications Corp.
803 501 East Middlefield Rd.
804 Mountain View, CA 94041
810 Lotus Development Corporation
811 6544 Battleford Drive
812 Raleigh, NC 27613-3502
814 frank_dawson@lotus.com
819 The following types are generally useful regardless of the profile
820 being carried and are defined below using the text/directory MIME
821 type registration template defined in Section 11.1 of this document.
822 These types MAY be included in any profile, unless explicitly
823 forbidden in the profile definition.
825 6.1. SOURCE Type Definition
827 To: ietf-mime-direct@imc.org
828 Subject: Registration of text/directory MIME type SOURCE
832 Type purpose: To identify the source of directory information
833 contained in the content type.
842 Howes, et. al. Standards Track [Page 15]
844 RFC 2425 MIME Content-Type for Directory Information September 1998
847 Type special notes: The SOURCE type is used to provide the means by
848 which applications knowledgable in the given directory service
849 protocol can obtain additional or more up-to-date information from
850 the directory service. It contains a URI as defined in [RFC-1738]
851 and/or other information referencing the directory entity or entities
852 to which the information pertains. When directory information is
853 available from more than one source, the sending entity can pick what
854 it considers to be the best source, or multiple SOURCE types can be
855 included. The interpretation of the value for a SOURCE type can
856 depend on the setting of the CONTEXT type parameter. The value of the
857 CONTEXT type parameter MUST be compatible with the value of the uri
861 SOURCE;CONTEXT=LDAP:ldap://ldap.host/cn=Babs%20Jensen,
864 6.2. NAME Type Definition
866 To: ietf-mime-direct@imc.org
867 Subject: Registration of text/directory MIME type NAME
871 Type purpose: To identify the displayable name of the directory
872 entity to which information in the content type pertains.
878 Type special notes: The NAME type is used to convey the display name
879 of the entity to which the directory information pertains.
882 NAME:Babs Jensen's Contact Information
884 6.3. PROFILE Type Definition
886 To: ietf-mime-direct@imc.org
887 Subject: Registration of text/directory MIME type PROFILE
891 Type purpose: To identify the type of directory entity to which
892 information in the content type pertains.
898 Howes, et. al. Standards Track [Page 16]
900 RFC 2425 MIME Content-Type for Directory Information September 1998
903 Type valuetype: A profile name, registered as described in Section 9
904 of this document or bilaterally agreed upon as described in Section
907 Type special notes: The PROFILE type is used to convey the type of
908 the entity to which the directory information in the rest of the body
909 part pertains. It should be the same as the "profile" header
910 parameter, if present.
915 6.4. BEGIN Type Definition
917 To: ietf-mime-direct@imc.org
918 Subject: Registration of text/directory MIME type BEGIN
922 Type purpose: To denote the beginning of a syntactic entity within a
923 text/directory content-type.
927 Type valuetype: text, containing a profile name, registered as
928 described in Section 9 of this document or bilaterally-agreed upon as
929 described in Section 5.
931 Type special notes: The BEGIN type is used in conjunction with the
932 END type to delimit a profile containing a related set of properties
933 within an text/directory content-type. This construct can be used
934 instead of or in addition to wrapping separate sets of information
935 inside additional MIME headers. It is provided for applications that
936 wish to define content that can contain multiple entities within the
937 same text/directory content-type or to define content that can be
938 identifiable outside of a MIME environment.
943 6.5. END Type Definition
945 To: ietf-mime-direct@imc.org
946 Subject: Registration of text/directory MIME type END
954 Howes, et. al. Standards Track [Page 17]
956 RFC 2425 MIME Content-Type for Directory Information September 1998
959 Type purpose: To denote the end of a syntactic entity within a
960 text/directory content-type.
964 Type valuetype: text, containing a profile name, registered as
965 described in Section 9 of this document or bilaterally-agreed upon as
966 described in Section 5.
968 Type special notes: The END type is used in conjunction with the
969 BEGIN type to delimit a profile containing a related set of
970 properties within an text/directory content-type. This construct can
971 be used instead of or in addition to wrapping separate sets of
972 information inside additional MIME headers. It is provided for
973 applications that wish to define content that can contain multiple
974 entities within the same text/directory content-type or to define
975 content that can be identifiable outside of a MIME environment.
980 7. Use of the multipart/related Content-Type
982 The multipart/related Content-Type can be used to hold directory
983 information comprised of both text and non-text information or
984 directory information that already has a natural MIME representation.
985 The root body part within the multipart/related body part is
986 specified as defined in [RFC-2112] by a "start" parameter, or it is
987 the first body part in the absence of such a parameter. The root
988 body part must have a Content-Type of "text/directory". This part
989 holds inline information and makes reference to subsequent body parts
990 holding additional text or non-text directory information via their
991 Content-ID URIs as explained in Section 5.
993 The body parts referred to do not have to be in any particular order,
994 except as noted above for the root body part.
998 The following examples are for illustrative purposes only and are not
999 part of the definition.
1010 Howes, et. al. Standards Track [Page 18]
1012 RFC 2425 MIME Content-Type for Directory Information September 1998
1017 The first example illustrates simple use of the text/directory
1018 Content-Type. Note that no "profile" parameter is given, so an
1019 application may not know what kind of directory entity the
1020 information applies to. Note also the use of both hypothetical
1021 official and bilaterally agreed upon types.
1023 From: Whomever@wherever.com
1024 To: Someone@somewhere.com
1027 Message-ID: <id1@host.net>
1028 Content-Type: text/directory
1029 Content-ID: <id2@host.com>
1034 email:babs@umich.edu
1035 phone:+1 313 747-4454
1040 The next example illustrates the use of the Quoted-Printable transfer
1041 encoding defined in [RFC 2045] to include non-ASCII character in some
1042 of the information returned, and the use of the optional "name" and
1043 "source" types. It also illustrates the use of an "encoding" type
1044 parameter to encode a certificate value in "b". A "vCard" profile
1045 [MIME- VCARD] is used for the example.
1047 Content-Type: text/directory;
1048 charset="iso-8859-1";
1050 Content-ID: <id3@host.com>
1051 Content-Transfer-Encoding: Quoted-Printable
1054 source:ldap://cn=bjorn%20Jensen, o=university%20of%20Michigan, c=US
1058 email;type=internet:bjorn@umich.edu
1059 tel;type=work,voice,msg:+1 313 747-4454
1060 key;type=x509;encoding=B:dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK
1066 Howes, et. al. Standards Track [Page 19]
1068 RFC 2425 MIME Content-Type for Directory Information September 1998
1073 The next example illustrates the use of multi-valued type parameters,
1074 the "language" type parameter, the "value" type parameter, folding of
1075 long lines, the \n encoding for formatted lines, attribute grouping,
1076 and the inline "b" encoding. A "vCard" profile [MIME-VCARD] is used
1079 Content-Type: text/directory; profile="vcard"; charset=iso-8859-1
1080 Content-ID: <id3@host.com>
1081 Content-Transfer-Encoding: Quoted-Printable
1084 source:ldap://cn=Meister%20Berger,o=Universitaet%20Goerlitz,c=DE
1088 bday;value=date:1963-09-21
1089 o:Universit=E6t G=F6rlitz
1091 title;language=de;value=text:Burgermeister
1092 note:The Mayor of the great city of
1093 Goerlitz in the great country of Germany.
1094 email;internet:mb@goerlitz.de
1095 home.tel;type=fax,voice,msg:+49 3581 123456
1096 home.label:Hufenshlagel 1234\n
1099 key;type=X509;encoding=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQ
1100 AwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zI
1101 ENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQD
1102 ExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNjE5NDc1OVoXDTk3MTIwMzE5NDc
1103 1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYDVQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW
1104 9ucyBDb3JwLjEYMBYGA1UEAxMPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBF
1105 hJob3dlc0BuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqG
1106 SIb3DQEBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2dXc
1107 oX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MBEGCWCGSAGG+E
1108 IBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9
1109 w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIPmx93HGp0Kgyx1jIVMyNgsemeAwBM+M
1110 SlhMfcpbTrONwNjZYW8vJDSoi//yrZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8V
1111 UMk1U7jt8LYpo4YULU7UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==
1122 Howes, et. al. Standards Track [Page 20]
1124 RFC 2425 MIME Content-Type for Directory Information September 1998
1129 The final example illustrates the use of the multipart/related
1130 Content-Type to include non-textual directory data via the "uri"
1131 encoding to refer to other body parts within the same message, or to
1132 external values. Note that no "profile" parameter is given, so an
1133 application may not know what kind of directory entity the
1134 information applies to. Note also the use of both hypothetical
1135 official and bilaterally agreed upon types.
1137 Content-Type: multipart/related;
1139 type="text/directory";
1140 start="<id5@host.com>"
1141 Content-ID: <id4@host.com>
1144 Content-Type: text/directory; charset="iso-8859-1"
1145 Content-ID: <id5@host.com>
1146 Content-Transfer-Encoding: Quoted-Printable
1148 source:ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US
1151 email:bjorn@umich.edu
1152 image;value=uri:cid:id6@host.com
1153 image;value=uri;format=jpeg:ftp://some.host/some/path.jpg
1154 sound;value=uri:cid:id7@host.com
1155 phone:+1 313 747-4454
1158 Content-Type: image/jpeg
1159 Content-ID: <id6@host.com>
1164 Content-Type: message/external-body;
1167 access-type=ANON-FTP;
1168 directory="pub/myname";
1171 Content-Type: audio/basic
1172 Content-ID: <id7@host.com>
1178 Howes, et. al. Standards Track [Page 21]
1180 RFC 2425 MIME Content-Type for Directory Information September 1998
1183 9. Registration of new profiles
1185 This section defines procedures by which new profiles are registered
1186 with the IANA and made available to the Internet community. Note that
1187 non-IANA profiles can be used by bilateral agreement, provided the
1188 associated profile names follow the "X-" convention defined above.
1190 The procedures defined here are designed to allow public comment and
1191 review of new profiles, while posing only a small impediment to the
1192 definition of new profiles.
1194 Registration of a new profile is accomplished by the following steps.
1196 9.1. Define the profile
1198 A profile is defined by completing the following template.
1200 To: ietf-mime-direct@imc.org
1201 Subject: Registration of text/directory MIME profile XXX
1209 Profile special notes (optional):
1211 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
1213 The explanation of what goes in each field in the template follows.
1215 Profile name: The name of the profile as it will appear in the
1216 text/directory MIME Content-Type "profile" header parameter, or the
1217 predefined "profile" type name.
1219 Profile purpose: The purpose of the profile (e.g., to represent
1220 information about people, printers, documents, etc.). Give a short
1221 but clear description.
1223 Profile types: The list of types associated with the profile. This
1224 list of types is to be expected but not required in the profile,
1225 unless otherwise noted in the profile definition. Other types not
1226 mentioned in the profile definition MAY also be present. Note that
1227 any new types referenced by the profile MUST be defined separately as
1228 described in Section 10.
1234 Howes, et. al. Standards Track [Page 22]
1236 RFC 2425 MIME Content-Type for Directory Information September 1998
1239 Profile special notes: Any special notes about the profile, how it is
1240 to be used, etc. This section of the template can also be used to
1241 define an ordering on the types that appear in the Content-Type, if
1242 such an ordering is required.
1244 9.2. Post the profile definition
1246 The profile description must be posted to the new profile discussion
1247 list, ietf-mime-direct@imc.org
1249 9.3. Allow a comment period
1251 Discussion on the new profile must be allowed to take place on the
1252 list for a minimum of two weeks. Consensus must be reached on the
1253 profile before proceeding to step 4.
1255 9.4. Submit the profile for approval
1257 Once the two-week comment period has elapsed, and the proposer is
1258 convinced consensus has been reached on the profile, the registration
1259 application should be submitted to the Profile Reviewer for approval.
1260 The Profile Reviewer is appointed by the Application Area Directors
1261 and can either accept or reject the profile registration. An accepted
1262 registration is passed on by the Profile Reviewer to the IANA for
1263 inclusion in the official IANA profile registry. The registration may
1264 be rejected for any of the following reasons. 1) Insufficient comment
1265 period; 2) Consensus not reached; 3) Technical deficiencies raised on
1266 the list or elsewhere have not been addressed. The Profile Reviewer's
1267 decision to reject a profile can be appealed by the proposer to the
1268 IESG, or the objections raised can be addressed by the proposer and
1269 the profile resubmitted.
1271 10. Profile Change Control
1273 Existing profiles can be changed using the same process by which they
1280 Allow a comment period
1282 Submit the changed profile for approval
1290 Howes, et. al. Standards Track [Page 23]
1292 RFC 2425 MIME Content-Type for Directory Information September 1998
1295 Note that the original author or any other interested party can
1296 propose a change to an existing profile, but that such changes should
1297 only be proposed when there are serious omissions or errors in the
1298 published specification. The Profile Reviewer can object to a change
1299 if it is not backwards compatible, but is not required to do so.
1301 Profile definitions can never be deleted from the IANA registry, but
1302 profiles which are no longer believed to be useful can be declared
1303 OBSOLETE by a change to their "intended use" field.
1305 11. Registration of new types
1307 This section defines procedures by which new types are registered
1308 with the IANA. Note that non-IANA types can be used by bilateral
1309 agreement, provided the associated types names follow the "X-"
1310 convention defined above.
1312 The procedures defined here are designed to allow public comment and
1313 review of new types, while posing only a small impediment to the
1314 definition of new types.
1316 Registration of a new type is accomplished by the following steps.
1318 11.1. Define the type
1320 A type is defined by completing the following template.
1322 To: ietf-mime-direct@imc.org
1323 Subject: Registration of text/directory MIME type XXX
1333 Type special notes (optional):
1335 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
1337 The meaning of each field in the template is as follows.
1339 Type name: The name of the type, as it will appear in the body of an
1340 text/directory MIME Content-Type "type: value" line to the left of
1346 Howes, et. al. Standards Track [Page 24]
1348 RFC 2425 MIME Content-Type for Directory Information September 1998
1351 Type purpose: The purpose of the type (e.g., to represent a name,
1352 postal address, IP address, etc.). Give a short but clear
1355 Type encoding: The default encoding a value of the type must have in
1356 the body of a text/directory MIME Content-Type.
1358 Type valuetype: The format a value of the type must have in the body
1359 of a text/directory MIME Content-Type. This description must be
1360 precise and must not violate the general encoding rules defined in
1361 section 5 of this document.
1363 Type special notes: Any special notes about the type, how it is to be
1366 11.2. Post the type definition
1368 The type description must be posted to the new type discussion list,
1369 ietf-mime-direct@imc.org
1371 11.3. Allow a comment period
1373 Discussion on the new type must be allowed to take place on the list
1374 for a minimum of two weeks. Consensus must be reached on the type
1375 before proceeding to step 4.
1377 11.4. Submit the type for approval
1379 Once the two-week comment period has elapsed, and the proposer is
1380 convinced consensus has been reached on the type, the registration
1381 application should be submitted to the Profile Reviewer for approval.
1382 The Profile Reviewer is appointed by the Application Area Directors
1383 and can either accept or reject the type registration. An accepted
1384 registration is passed on by the Profile Reviewer to the IANA for
1385 inclusion in the official IANA profile registry. The registration can
1386 be rejected for any of the following reasons. 1) Insufficient comment
1387 period; 2) Consensus not reached; 3) Technical deficiencies raised on
1388 the list or elsewhere have not been addressed. The Profile
1389 Reviewer's decision to reject a type can be appealed by the proposer
1390 to the IESG, or the objections raised can be addressed by the
1391 proposer and the type resubmitted.
1402 Howes, et. al. Standards Track [Page 25]
1404 RFC 2425 MIME Content-Type for Directory Information September 1998
1407 12. Type Change Control
1409 Existing types can be changed using the same process by which they
1416 Allow a comment period
1418 Submit the type for approval
1420 Note that the original author or any other interested party can
1421 propose a change to an existing type, but that such changes should
1422 only be proposed when there are serious omissions or errors in the
1423 published specification. The Profile Reviewer can object to a change
1424 if it is not backwards compatible, but is not required to do so.
1426 Type definitions can never be deleted from the IANA registry, but
1427 types which are nolonger believed to be useful can be declared
1428 OBSOLETE by a change to their "intended use" field.
1430 13. Registration of new parameters
1432 This section defines procedures by which new parameters are
1433 registered with the IANA and made available to the Internet
1434 community. Note that non-IANA parameters can be used by bilateral
1435 agreement, provided the associated parameters names follow the "X-"
1436 convention defined above.
1438 The procedures defined here are designed to allow public comment and
1439 review of new parameters, while posing only a small impediment to the
1440 definition of new parameters.
1442 Registration of a new parameter is accomplished by the following
1445 13.1. Define the parameter
1447 A parameter is defined by completing the following template.
1449 To: ietf-mime-direct@imc.org
1450 Subject: Registration of text/directory MIME type parameter XXX
1458 Howes, et. al. Standards Track [Page 26]
1460 RFC 2425 MIME Content-Type for Directory Information September 1998
1465 Parameter special notes (optional):
1467 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
1469 The explanation of what goes in each field in the template follows.
1471 Parameter name: The name of the parameter as it will appear in the
1472 text/directory MIME Content-Type.
1474 Parameter purpose: The purpose of the parameter (e.g., to represent
1475 the format of an image, type of a phone number, etc.). Give a short
1476 but clear description. If defining a general paramemter like "format"
1477 or "type" keep in mind that other applications might wish to extend
1480 Parameter values: The list or description of values associated with
1483 Parameter special notes: Any special notes about the parameter, how
1484 it is to be used, etc.
1486 13.2. Post the parameter definition
1488 The parameter description must be posted to the new parameter
1489 discussion list, ietf-mime-direct@imc.org
1491 13.3. Allow a comment period
1493 Discussion on the new parameter must be allowed to take place on the
1494 list for a minimum of two weeks. Consensus must be reached on the
1495 parameter before proceeding to step 4.
1497 13.4. Submit the parameter for approval
1499 Once the two-week comment period has elapsed, and the proposer is
1500 convinced consensus has been reached on the parameter, the
1501 registration application should be submitted to the Profile Reviewer
1502 for approval. The Profile Reviewer is appointed by the Application
1503 Area Directors and can either accept or reject the parameter
1504 registration. An accepted registration is passed on by the Profile
1505 Reviewer to the IANA for inclusion in the official IANA parameter
1506 registry. The registration can be rejected for any of the following
1507 reasons. 1) Insufficient comment period; 2) Consensus not reached; 3)
1508 Technical deficiencies raised on the list or elsewhere have not been
1509 addressed. The Profile Reviewer's decision to reject a profile can be
1510 appealed by the proposer to the IESG, or the objections raised can be
1514 Howes, et. al. Standards Track [Page 27]
1516 RFC 2425 MIME Content-Type for Directory Information September 1998
1519 addressed by the proposer and the parameter registration resubmitted.
1521 14. Parameter Change Control
1523 Existing parameters can be changed using the same process by which
1524 they were registered.
1530 Allow a comment period
1532 Submit the parameter for approval
1534 Note that the original author or any other interested party can
1535 propose a change to an existing parameter, but that such changes
1536 should only be proposed when there are serious omissions or errors in
1537 the published specification. The Profile Reviewer can object to a
1538 change if it is not backwards compatible, but is not required to do
1541 Parameter definitions can never be deleted from the IANA registry,
1542 but parameters which are nolonger believed to be useful can be
1543 declared OBSOLETE by a change to their "intended use" field.
1545 15. Registration of new value types
1547 This section defines procedures by which new value types are
1548 registered with the IANA and made available to the Internet
1549 community. Note that non-IANA value types can be used by bilateral
1550 agreement, provided the associated value types names follow the "X-"
1551 convention defined above.
1553 The procedures defined here are designed to allow public comment and
1554 review of new value types, while posing only a small impediment to
1555 the definition of new value types.
1557 Registration of a new value types is accomplished by the following
1560 15.1. Define the value type
1562 A value type is defined by completing the following template.
1564 To: ietf-mime-direct@imc.org
1565 Subject: Registration of text/directory MIME value type XXX
1570 Howes, et. al. Standards Track [Page 28]
1572 RFC 2425 MIME Content-Type for Directory Information September 1998
1581 value type special notes (optional):
1583 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
1585 The explanation of what goes in each field in the template follows.
1587 value type name: The name of the value type as it will appear in the
1588 text/directory MIME Content-Type.
1590 value type purpose: The purpose of the value type. Give a short but
1593 value type format: The definition of the format for the value,
1594 usually using ABNF grammar.
1596 value type special notes: Any special notes about the value type, how
1597 it is to be used, etc.
1599 15.2. Post the value type definition
1601 The value type description must be posted to the new value type
1602 discussion list, ietf-mime-direct@imc.org
1604 15.3. Allow a comment period
1606 Discussion on the new value type must be allowed to take place on the
1607 list for a minimum of two weeks. Consensus must be reached before
1608 proceeding to step 4.
1610 15.4. Submit the value type for approval
1612 Once the two-week comment period has elapsed, and the proposer is
1613 convinced consensus has been reached on the value type, the
1614 registration application should be submitted to the Profile Reviewer
1615 for approval. The Profile Reviewer is appointed by the Application
1616 Area Directors and can either accept or reject the value type
1617 registration. An accepted registration should be passed on by the
1618 Profile Reviewer to the IANA for inclusion in the official IANA value
1619 type registry. The registration can be rejected for any of the
1620 following reasons. 1) Insufficient comment period; 2) Consensus not
1621 reached; 3) Technical deficiencies raised on the list or elsewhere
1622 have not been addressed. The Profile Reviewer's decision to reject a
1626 Howes, et. al. Standards Track [Page 29]
1628 RFC 2425 MIME Content-Type for Directory Information September 1998
1631 profile can be appealed by the proposer to the IESG, or the
1632 objections raised can be addressed by the proposer and the value type
1633 registration resubmitted.
1635 16. Security Considerations
1637 Internet mail is subject to many well known security attacks,
1638 including monitoring, replay, and forgery. Care should be taken by
1639 any directory service in allowing information to leave the scope of
1640 the service itself, where any access controls can no longer be
1641 guaranteed. Applications should also take care to display directory
1642 data in a "safe" environment (e.g., PostScript-valued types).
1644 17. Acknowledgements
1646 The registration procedures defined here were shamelessly lifted from
1647 the MIME registration RFC.
1649 The many valuable comments contributed by members of the IETF ASID
1650 working group are gratefully acknowledged, as are the contributions
1651 of the Versit Consortium. Chris Newman was especially helpful in
1652 navigating the intricacies of ABNF lore.
1656 [RFC-1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
1657 Directory Access Protocol", RFC 1777, March 1995.
1659 [RFC-1778] Howes, T., Kille, S., Yeong, W., and C. Robbins, "The
1660 String Representation of Standard Attribute Syntaxes",
1661 RFC 1778, March 1995.
1663 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
1664 Text Messages", STD 11, RFC 822, August 1982.
1666 [RFC-2045] Borenstein, N., and N. Freed, "Multipurpose Internet
1667 Mail Extensions (MIME) Part One: Format of Internet
1668 Message Bodies", RFC 2045, November 1996.
1670 [RFC-2046] Moore, K., "Multipurpose Internet Mail Extensions (MIME)
1671 Part Two: Media Types", RFC 2046, November 1996.
1673 [RFC-2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
1674 Internet Mail Extensions (MIME) Part Four: Registration
1675 Procedures", RFC 2048, November 1996.
1677 [RFC-1766] Alvestrand, H., "Tags for the Identification of
1678 Languages", RFC 1766, March 1995.
1682 Howes, et. al. Standards Track [Page 30]
1684 RFC 2425 MIME Content-Type for Directory Information September 1998
1687 [RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type",
1688 RFC 2112, March 1997.
1690 [X500] "Information Processing Systems - Open Systems
1691 Interconnection - The Directory: Overview of Concepts,
1692 Models and Services", ISO/IEC JTC 1/SC21, International
1693 Standard 9594-1, 1988.
1695 [RFC-1835] Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider,
1696 "Architecture of the WHOIS++ service", RFC 1835, August
1699 [RFC-1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
1700 Resource Locators (URL)", RFC 1738, December 1994.
1702 [MIME-VCARD] Dawson, F., and T. Howes, "VCard MIME Directory
1703 Profile", RFC 2426, September 1998.
1705 [VCARD] Internet Mail Consortium, "vCard - The Electronic
1706 Business Card", Version 2.1,
1707 http://www.imc.com/pdi/vcard-21.txt, September, 1996.
1709 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
1710 Requirement Levels", BCP 14, RFC 2119, March 1997.
1712 [RFC-2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
1713 Specifications: ABNF", RFC 2234, November 1997.
1738 Howes, et. al. Standards Track [Page 31]
1740 RFC 2425 MIME Content-Type for Directory Information September 1998
1743 19. Authors' Addresses
1746 Netscape Communications Corp.
1747 501 East Middlefield Rd.
1748 Mountain View, CA 94041
1751 Phone: +1.415.937.3419
1752 EMail: howes@netscape.com
1756 Netscape Communications Corp.
1757 501 East Middlefield Rd.
1758 Mountain View, CA 94041
1761 Phone: +1.415.937.3477
1762 EMail: mcs@netscape.com
1766 Lotus Development Corporation
1767 6544 Battleford Drive
1771 Phone: +1-919-676-9515
1772 EMail: frank_dawson@lotus.com
1794 Howes, et. al. Standards Track [Page 32]
1796 RFC 2425 MIME Content-Type for Directory Information September 1998
1799 20. Full Copyright Statement
1801 Copyright (C) The Internet Society (1998). All Rights Reserved.
1803 This document and translations of it may be copied and furnished to
1804 others, and derivative works that comment on or otherwise explain it
1805 or assist in its implementation may be prepared, copied, published
1806 and distributed, in whole or in part, without restriction of any
1807 kind, provided that the above copyright notice and this paragraph are
1808 included on all such copies and derivative works. However, this
1809 document itself may not be modified in any way, such as by removing
1810 the copyright notice or references to the Internet Society or other
1811 Internet organizations, except as needed for the purpose of
1812 developing Internet standards in which case the procedures for
1813 copyrights defined in the Internet Standards process must be
1814 followed, or as required to translate it into languages other than
1817 The limited permissions granted above are perpetual and will not be
1818 revoked by the Internet Society or its successors or assigns.
1820 This document and the information contained herein is provided on an
1821 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1822 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1823 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1824 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1825 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1850 Howes, et. al. Standards Track [Page 33]
projects / friendica-addons.git / blob