rfc2425.txt - rohrpost - A commandline mail client to change the world as we see it.
(HTM) git clone git://r-36.net/rohrpost
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) README
(DIR) LICENSE
---
rfc2425.txt (64428B)
---
1
2
3
4
5
6
7 Network Working Group T. Howes
8 Request for Comments: 2425 M. Smith
9 Category: Standards Track Netscape Communications Corp.
10 F. Dawson
11 Lotus Development Corporation
12 September 1998
13
14
15 A MIME Content-Type for Directory Information
16
17 Status of this Memo
18
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.
24
25 Copyright Notice
26
27 Copyright (C) The Internet Society (1998). All Rights Reserved.
28
29 1. Abstract
30
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
40 represented.
41
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).
53
54
55
56
57
58 Howes, et. al. Standards Track [Page 1]
59
60 RFC 2425 MIME Content-Type for Directory Information September 1998
61
62
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].
66
67 2. Table of Contents
68
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
111
112
113
114 Howes, et. al. Standards Track [Page 2]
115
116 RFC 2425 MIME Content-Type for Directory Information September 1998
117
118
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
141
142 3. Need for a MIME Directory Type
143
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.
152
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
164 HTTP.
165
166
167
168
169
170 Howes, et. al. Standards Track [Page 3]
171
172 RFC 2425 MIME Content-Type for Directory Information September 1998
173
174
175 4. Overview
176
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
190 [X500].
191
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
200 those parts.
201
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
205 this.
206
207 5. The text/directory Content-Type
208
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].
214
215 To: ietf-types@uninett.no
216 Subject: Registration of MIME media type text/directory
217
218 5.1. MIME media type name
219
220 MIME media type name: text
221
222
223
224
225
226 Howes, et. al. Standards Track [Page 4]
227
228 RFC 2425 MIME Content-Type for Directory Information September 1998
229
230
231 5.2. MIME subtype name
232
233 MIME subtype name: directory
234
235 5.3. Required parameters
236
237 Required parameters: charset
238
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
241 the body part.
242
243 5.4. Optional parameters
244
245 Optional parameters: profile
246
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.
256
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").
260
261 profile = x-name / iana-token
262
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.
267
268 iana-token = <a publicly-defined extension token, registered
269 with IANA, as specified in Section 9 of this
270 document>
271
272 5.5. Encoding considerations
273
274 The default encoding is 8bit. Otherwise, as specified by the
275 Content-Transfer-Encoding header field.
276
277
278
279
280
281
282 Howes, et. al. Standards Track [Page 5]
283
284 RFC 2425 MIME Content-Type for Directory Information September 1998
285
286
287 5.6. Security considerations
288
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.
298
299 5.7. Interoperability considerations
300
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
307 parties.
308
309 5.8. Published specification
310
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
314 given below.
315
316 5.8.1. Line delimiting and folding
317
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.
323
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:
331
332 DESCRIPTION:This is a long description that exists on a long line.
333
334 Can be represented as:
335
336
337
338 Howes, et. al. Standards Track [Page 6]
339
340 RFC 2425 MIME Content-Type for Directory Information September 1998
341
342
343 DESCRIPTION:This is a long description
344 that exists on a long line.
345
346 It could also be represented as:
347
348 DESCRIPTION:This is a long descrip
349 tion that exists o
350 n a long line.
351
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).
358
359 5.8.2. ABNF content-type definition
360
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:
365
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
369 ; described above.
370 ; When generating a content line, lines longer than 75
371 ; characters SHOULD be folded according to the folding
372 ; procedure described above.
373
374 group = 1*(ALPHA / DIGIT / "-")
375
376 name = x-name / iana-token
377
378 iana-token = 1*(ALPHA / DIGIT / "-")
379 ; identifier registered with IANA
380
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.
385
386 param = param-name "=" param-value *("," param-value)
387
388 param-name = x-name / iana-token
389
390 param-value = ptext / quoted-string
391
392
393
394 Howes, et. al. Standards Track [Page 7]
395
396 RFC 2425 MIME Content-Type for Directory Information September 1998
397
398
399 ptext = *SAFE-CHAR
400
401 value = *VALUE-CHAR
402 / valuespec ; valuespec defined in section 5.8.4
403
404 quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
405
406 NON-ASCII = %x80-FF
407 ; use restricted by charset parameter
408 ; on outer MIME object (UTF-8 preferred)
409
410 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII
411 ; Any character except CTLs, DQUOTE
412
413 SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII
414 ; Any character except CTLs, DQUOTE, ";", ":", ","
415
416 VALUE-CHAR = WSP / VCHAR / NON-ASCII
417 ; any textual character
418
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
425 removed.
426
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.
433
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.
437
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.
445
446
447
448
449
450 Howes, et. al. Standards Track [Page 8]
451
452 RFC 2425 MIME Content-Type for Directory Information September 1998
453
454
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.
464
465 5.8.3. Pre-defined Parameters
466
467 The following parameters and value types are defined for general use.
468
469 predefined-param = encodingparm
470 / valuetypeparm
471 / languageparm
472 / contextparm
473
474 encodingparm = "encoding" "=" encodingtype
475
476 encodingtype = "b" ; from RFC 2047
477 / iana-token ; registered as described in
478 ; section 15 of this document
479
480 valuetypeparm = "value" "=" valuetype
481
482 valuetype = "uri" ; genericurl from secion 5 of RFC 1738
483 / "text"
484 / "date"
485 / "time"
486 / "date-time" ; date time
487 / "integer"
488 / "boolean"
489 / "float"
490 / x-name
491 / iana-token ; registered as described in
492 ; section 15 of this document
493
494 languageparm = "language" "=" Language-Tag
495 ; Language-Tag is defined in section 2 of RFC 1766
496
497 contextparm = "context" "=" context
498
499 context = x-name
500 / iana-token
501
502
503
504
505
506 Howes, et. al. Standards Track [Page 9]
507
508 RFC 2425 MIME Content-Type for Directory Information September 1998
509
510
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].
516
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.
520
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.
525
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.
532
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.
539
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.
548
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.
554
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
559
560
561
562 Howes, et. al. Standards Track [Page 10]
563
564 RFC 2425 MIME Content-Type for Directory Information September 1998
565
566
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.
570
571 5.8.4. Pre-defined Value Types
572
573 The format for values corresponding to the predefined valuetype
574 specifications given above are defined.
575
576 valuespec = text-list
577 / genericurl ; from section 5 of RFC 1738
578 / date-list
579 / time-list
580 / date-time-list
581 / boolean
582 / integer-list
583 / float-list
584 / iana-valuespec
585
586 text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR)
587
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.
592
593 date-list = date *("," date)
594
595 time-list = time *("," time)
596
597 date-time-list = date "T" time *("," date "T" time)
598
599 boolean = "TRUE" / "FALSE"
600
601 integer-list = integer *("," integer)
602
603 integer = [sign] 1*DIGIT
604
605 float-list = float *("," float)
606
607 float = [sign] 1*DIGIT ["." 1*DIGIT]
608
609 sign = "+" / "-"
610
611 date = date-fullyear ["-"] date-month ["-"] date-mday
612
613 date-fullyear = 4 DIGIT
614
615
616
617
618 Howes, et. al. Standards Track [Page 11]
619
620 RFC 2425 MIME Content-Type for Directory Information September 1998
621
622
623 date-month = 2 DIGIT ;01-12
624
625 date-mday = 2 DIGIT ;01-28, 01-29, 01-30, 01-31
626 ;based on month/year
627
628 time = time-hour [":"] time-minute [":"] time-second [time-secfrac]
629 [time-zone]
630
631 time-hour = 2 DIGIT ;00-23
632
633 time-minute = 2 DIGIT ;00-59
634
635 time-second = 2 DIGIT ;00-60 (leap second)
636
637 time-secfrac = "," 1*DIGIT
638
639 time-zone = "Z" / time-numzone
640
641 time-numzome = sign time-hour [":"] time-minute
642
643 iana-valuespec = <a publicly-defined valuetype format, registered
644 with IANA, as defined in section 15 of this
645 document>
646
647 Some specific notes on the value types and formats:
648
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.
653
654 Examples for "text":
655 this is a text value
656 this is one value,this is another
657 this is a single value\, with a comma encoded
658
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".
663
664 For example a multiple line DESCRIPTION value of:
665
666 Mythical Manager
667 Hyjinx Software Division
668 BabsCo, Inc.
669
670 could be represented as:
671
672
673
674 Howes, et. al. Standards Track [Page 12]
675
676 RFC 2425 MIME Content-Type for Directory Information September 1998
677
678
679 DESCRIPTION:Mythical Manager\nHyjinx Software Division\n
680 BabsCo\, Inc.\n
681
682 demonstrating the \n literal formatted line break technique, the
683 CRLF-followed-by-space line folding technique, and the backslash
684 escape technique.
685
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.
691
692 Examples for "uri":
693 http://www.foobar.com/my/picture.jpg
694 ldap://ldap.foobar.com/cn=babs%20jensen
695
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.
701
702 Examples for "date":
703 1985-04-12
704 1996-08-05,1996-11-11
705 19850412
706
707 Examples for "time":
708 10:22:00
709 102200
710 10:22:00.33
711 10:22:00.33Z
712 10:22:33,11:22:00
713 10:22:00-08:00
714
715 Examples for "date-time":
716 1996-10-22T14:00:00Z
717 1996-08-11T12:34:56Z
718 19960811T123456Z
719 1996-10-22T14:00:00Z,1996-08-11T12:34:56Z
720
721 "boolean": The "boolean" value type is used to express boolen values.
722 These values are case insensitive.
723
724 Examples: TRUE
725 false
726 True
727
728
729
730 Howes, et. al. Standards Track [Page 13]
731
732 RFC 2425 MIME Content-Type for Directory Information September 1998
733
734
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.
739
740 Examples: 1234567890
741 -1234556790
742 +1234556790,432109876
743
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.
748
749 Examples: 20.30
750 1000000.0000001
751 1.333,3.14
752
753 5.9. Applications which use this media type
754
755 Applications which use this media type: Various
756
757 5.10. Additional information
758
759 Additional information: None
760
761 5.11. Person & email address to contact for further information
762
763 Tim Howes
764 Netscape Communications Corp.
765 501 East Middlefield Rd.
766 Mountain View, CA 94041
767 USA
768 howes@netscape.com
769 +1 415 937 3419
770
771 5.12. Intended usage
772
773 Intended usage: COMMON
774
775
776
777
778
779
780
781
782
783
784
785
786 Howes, et. al. Standards Track [Page 14]
787
788 RFC 2425 MIME Content-Type for Directory Information September 1998
789
790
791 5.13. Author/Change controller
792
793 Tim Howes
794 Netscape Communications Corp.
795 501 East Middlefield Rd.
796 Mountain View, CA 94041
797 USA
798 howes@netscape.com
799 +1 415 937 3419
800
801 Mark Smith
802 Netscape Communications Corp.
803 501 East Middlefield Rd.
804 Mountain View, CA 94041
805 USA
806 mcs@netscape.com
807 +1 415 937 3477
808
809 Frank Dawson
810 Lotus Development Corporation
811 6544 Battleford Drive
812 Raleigh, NC 27613-3502
813 USA
814 frank_dawson@lotus.com
815 +1-919-676-9515
816
817 6. Predefined Types
818
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.
824
825 6.1. SOURCE Type Definition
826
827 To: ietf-mime-direct@imc.org
828 Subject: Registration of text/directory MIME type SOURCE
829
830 Type name: SOURCE
831
832 Type purpose: To identify the source of directory information
833 contained in the content type.
834
835 Type encoding: 8bit
836
837 Type valuetype: uri
838
839
840
841
842 Howes, et. al. Standards Track [Page 15]
843
844 RFC 2425 MIME Content-Type for Directory Information September 1998
845
846
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
858 prefix.
859
860 Type example:
861 SOURCE;CONTEXT=LDAP:ldap://ldap.host/cn=Babs%20Jensen,
862 %20o=Babsco,%20c=US
863
864 6.2. NAME Type Definition
865
866 To: ietf-mime-direct@imc.org
867 Subject: Registration of text/directory MIME type NAME
868
869 Type name: NAME
870
871 Type purpose: To identify the displayable name of the directory
872 entity to which information in the content type pertains.
873
874 Type encoding: 8bit
875
876 Type valuetype: text
877
878 Type special notes: The NAME type is used to convey the display name
879 of the entity to which the directory information pertains.
880
881 Type example:
882 NAME:Babs Jensen's Contact Information
883
884 6.3. PROFILE Type Definition
885
886 To: ietf-mime-direct@imc.org
887 Subject: Registration of text/directory MIME type PROFILE
888
889 Type name: PROFILE
890
891 Type purpose: To identify the type of directory entity to which
892 information in the content type pertains.
893
894 Type encoding: 8bit
895
896
897
898 Howes, et. al. Standards Track [Page 16]
899
900 RFC 2425 MIME Content-Type for Directory Information September 1998
901
902
903 Type valuetype: A profile name, registered as described in Section 9
904 of this document or bilaterally agreed upon as described in Section
905 5.
906
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.
911
912 Type example:
913 PROFILE:vCard
914
915 6.4. BEGIN Type Definition
916
917 To: ietf-mime-direct@imc.org
918 Subject: Registration of text/directory MIME type BEGIN
919
920 Type name: BEGIN
921
922 Type purpose: To denote the beginning of a syntactic entity within a
923 text/directory content-type.
924
925 Type encoding: 8bit
926
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.
930
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.
939
940 Type example:
941 BEGIN:VCARD
942
943 6.5. END Type Definition
944
945 To: ietf-mime-direct@imc.org
946 Subject: Registration of text/directory MIME type END
947
948 Type name: END
949
950
951
952
953
954 Howes, et. al. Standards Track [Page 17]
955
956 RFC 2425 MIME Content-Type for Directory Information September 1998
957
958
959 Type purpose: To denote the end of a syntactic entity within a
960 text/directory content-type.
961
962 Type encoding: 8bit
963
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.
967
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.
976
977 Type example:
978 END: VCARD
979
980 7. Use of the multipart/related Content-Type
981
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.
992
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.
995
996 8. Examples
997
998 The following examples are for illustrative purposes only and are not
999 part of the definition.
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010 Howes, et. al. Standards Track [Page 18]
1011
1012 RFC 2425 MIME Content-Type for Directory Information September 1998
1013
1014
1015 8.1. Example 1
1016
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.
1022
1023 From: Whomever@wherever.com
1024 To: Someone@somewhere.com
1025 Subject: whatever
1026 MIME-Version: 1.0
1027 Message-ID: <id1@host.net>
1028 Content-Type: text/directory
1029 Content-ID: <id2@host.com>
1030
1031 cn:Babs Jensen
1032 cn:Barbara J Jensen
1033 sn:Jensen
1034 email:babs@umich.edu
1035 phone:+1 313 747-4454
1036 x-id:1234567890
1037
1038 8.2. Example 2
1039
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.
1046
1047 Content-Type: text/directory;
1048 charset="iso-8859-1";
1049 profile="vCard"
1050 Content-ID: <id3@host.com>
1051 Content-Transfer-Encoding: Quoted-Printable
1052
1053 begin:VCARD
1054 source:ldap://cn=bjorn%20Jensen, o=university%20of%20Michigan, c=US
1055 name:Bjorn Jensen
1056 fn:Bj=F8rn Jensen
1057 n:Jensen;Bj=F8rn
1058 email;type=internet:bjorn@umich.edu
1059 tel;type=work,voice,msg:+1 313 747-4454
1060 key;type=x509;encoding=B:dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK
1061 end:VCARD
1062
1063
1064
1065
1066 Howes, et. al. Standards Track [Page 19]
1067
1068 RFC 2425 MIME Content-Type for Directory Information September 1998
1069
1070
1071 8.3. Example 3
1072
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
1077 for the example.
1078
1079 Content-Type: text/directory; profile="vcard"; charset=iso-8859-1
1080 Content-ID: <id3@host.com>
1081 Content-Transfer-Encoding: Quoted-Printable
1082
1083 begin:vcard
1084 source:ldap://cn=Meister%20Berger,o=Universitaet%20Goerlitz,c=DE
1085 name:Meister Berger
1086 fn:Meister Berger
1087 n:Berger;Meister
1088 bday;value=date:1963-09-21
1089 o:Universit=E6t G=F6rlitz
1090 title:Mayor
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
1097 02828 Goerlitz\n
1098 Deutschland
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==
1112 end:vcard
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122 Howes, et. al. Standards Track [Page 20]
1123
1124 RFC 2425 MIME Content-Type for Directory Information September 1998
1125
1126
1127 8.4. Example 4
1128
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.
1136
1137 Content-Type: multipart/related;
1138 boundary=woof;
1139 type="text/directory";
1140 start="<id5@host.com>"
1141 Content-ID: <id4@host.com>
1142
1143 --woof
1144 Content-Type: text/directory; charset="iso-8859-1"
1145 Content-ID: <id5@host.com>
1146 Content-Transfer-Encoding: Quoted-Printable
1147
1148 source:ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US
1149 cn:Bj=F8rn Jensen
1150 sn:Jensen
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
1156
1157 --woof
1158 Content-Type: image/jpeg
1159 Content-ID: <id6@host.com>
1160
1161 <...image data...>
1162
1163 --woof
1164 Content-Type: message/external-body;
1165 name="myvoice.au";
1166 site="myhost.com";
1167 access-type=ANON-FTP;
1168 directory="pub/myname";
1169 mode="image"
1170
1171 Content-Type: audio/basic
1172 Content-ID: <id7@host.com>
1173
1174 --woof--
1175
1176
1177
1178 Howes, et. al. Standards Track [Page 21]
1179
1180 RFC 2425 MIME Content-Type for Directory Information September 1998
1181
1182
1183 9. Registration of new profiles
1184
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.
1189
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.
1193
1194 Registration of a new profile is accomplished by the following steps.
1195
1196 9.1. Define the profile
1197
1198 A profile is defined by completing the following template.
1199
1200 To: ietf-mime-direct@imc.org
1201 Subject: Registration of text/directory MIME profile XXX
1202
1203 Profile name:
1204
1205 Profile purpose:
1206
1207 Profile types:
1208
1209 Profile special notes (optional):
1210
1211 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
1212
1213 The explanation of what goes in each field in the template follows.
1214
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.
1218
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.
1222
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.
1229
1230
1231
1232
1233
1234 Howes, et. al. Standards Track [Page 22]
1235
1236 RFC 2425 MIME Content-Type for Directory Information September 1998
1237
1238
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.
1243
1244 9.2. Post the profile definition
1245
1246 The profile description must be posted to the new profile discussion
1247 list, ietf-mime-direct@imc.org
1248
1249 9.3. Allow a comment period
1250
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.
1254
1255 9.4. Submit the profile for approval
1256
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.
1270
1271 10. Profile Change Control
1272
1273 Existing profiles can be changed using the same process by which they
1274 were registered.
1275
1276 Define the change
1277
1278 Post the change
1279
1280 Allow a comment period
1281
1282 Submit the changed profile for approval
1283
1284
1285
1286
1287
1288
1289
1290 Howes, et. al. Standards Track [Page 23]
1291
1292 RFC 2425 MIME Content-Type for Directory Information September 1998
1293
1294
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.
1300
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.
1304
1305 11. Registration of new types
1306
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.
1311
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.
1315
1316 Registration of a new type is accomplished by the following steps.
1317
1318 11.1. Define the type
1319
1320 A type is defined by completing the following template.
1321
1322 To: ietf-mime-direct@imc.org
1323 Subject: Registration of text/directory MIME type XXX
1324
1325 Type name:
1326
1327 Type purpose:
1328
1329 Type encoding:
1330
1331 Type valuetype:
1332
1333 Type special notes (optional):
1334
1335 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
1336
1337 The meaning of each field in the template is as follows.
1338
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
1341 the colon ":".
1342
1343
1344
1345
1346 Howes, et. al. Standards Track [Page 24]
1347
1348 RFC 2425 MIME Content-Type for Directory Information September 1998
1349
1350
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
1353 description.
1354
1355 Type encoding: The default encoding a value of the type must have in
1356 the body of a text/directory MIME Content-Type.
1357
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.
1362
1363 Type special notes: Any special notes about the type, how it is to be
1364 used, etc.
1365
1366 11.2. Post the type definition
1367
1368 The type description must be posted to the new type discussion list,
1369 ietf-mime-direct@imc.org
1370
1371 11.3. Allow a comment period
1372
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.
1376
1377 11.4. Submit the type for approval
1378
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.
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402 Howes, et. al. Standards Track [Page 25]
1403
1404 RFC 2425 MIME Content-Type for Directory Information September 1998
1405
1406
1407 12. Type Change Control
1408
1409 Existing types can be changed using the same process by which they
1410 were registered.
1411
1412 Define the change
1413
1414 Post the change
1415
1416 Allow a comment period
1417
1418 Submit the type for approval
1419
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.
1425
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.
1429
1430 13. Registration of new parameters
1431
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.
1437
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.
1441
1442 Registration of a new parameter is accomplished by the following
1443 steps.
1444
1445 13.1. Define the parameter
1446
1447 A parameter is defined by completing the following template.
1448
1449 To: ietf-mime-direct@imc.org
1450 Subject: Registration of text/directory MIME type parameter XXX
1451
1452 Parameter name:
1453
1454 Parameter purpose:
1455
1456
1457
1458 Howes, et. al. Standards Track [Page 26]
1459
1460 RFC 2425 MIME Content-Type for Directory Information September 1998
1461
1462
1463 Parameter values:
1464
1465 Parameter special notes (optional):
1466
1467 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
1468
1469 The explanation of what goes in each field in the template follows.
1470
1471 Parameter name: The name of the parameter as it will appear in the
1472 text/directory MIME Content-Type.
1473
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
1478 its use.
1479
1480 Parameter values: The list or description of values associated with
1481 the parameter.
1482
1483 Parameter special notes: Any special notes about the parameter, how
1484 it is to be used, etc.
1485
1486 13.2. Post the parameter definition
1487
1488 The parameter description must be posted to the new parameter
1489 discussion list, ietf-mime-direct@imc.org
1490
1491 13.3. Allow a comment period
1492
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.
1496
1497 13.4. Submit the parameter for approval
1498
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
1511
1512
1513
1514 Howes, et. al. Standards Track [Page 27]
1515
1516 RFC 2425 MIME Content-Type for Directory Information September 1998
1517
1518
1519 addressed by the proposer and the parameter registration resubmitted.
1520
1521 14. Parameter Change Control
1522
1523 Existing parameters can be changed using the same process by which
1524 they were registered.
1525
1526 Define the change
1527
1528 Post the change
1529
1530 Allow a comment period
1531
1532 Submit the parameter for approval
1533
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
1539 so.
1540
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.
1544
1545 15. Registration of new value types
1546
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.
1552
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.
1556
1557 Registration of a new value types is accomplished by the following
1558 steps.
1559
1560 15.1. Define the value type
1561
1562 A value type is defined by completing the following template.
1563
1564 To: ietf-mime-direct@imc.org
1565 Subject: Registration of text/directory MIME value type XXX
1566
1567
1568
1569
1570 Howes, et. al. Standards Track [Page 28]
1571
1572 RFC 2425 MIME Content-Type for Directory Information September 1998
1573
1574
1575 value type name:
1576
1577 value type purpose:
1578
1579 value type format:
1580
1581 value type special notes (optional):
1582
1583 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
1584
1585 The explanation of what goes in each field in the template follows.
1586
1587 value type name: The name of the value type as it will appear in the
1588 text/directory MIME Content-Type.
1589
1590 value type purpose: The purpose of the value type. Give a short but
1591 clear description.
1592
1593 value type format: The definition of the format for the value,
1594 usually using ABNF grammar.
1595
1596 value type special notes: Any special notes about the value type, how
1597 it is to be used, etc.
1598
1599 15.2. Post the value type definition
1600
1601 The value type description must be posted to the new value type
1602 discussion list, ietf-mime-direct@imc.org
1603
1604 15.3. Allow a comment period
1605
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.
1609
1610 15.4. Submit the value type for approval
1611
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
1623
1624
1625
1626 Howes, et. al. Standards Track [Page 29]
1627
1628 RFC 2425 MIME Content-Type for Directory Information September 1998
1629
1630
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.
1634
1635 16. Security Considerations
1636
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).
1643
1644 17. Acknowledgements
1645
1646 The registration procedures defined here were shamelessly lifted from
1647 the MIME registration RFC.
1648
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.
1653
1654 18. References
1655
1656 [RFC-1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
1657 Directory Access Protocol", RFC 1777, March 1995.
1658
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.
1662
1663 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
1664 Text Messages", STD 11, RFC 822, August 1982.
1665
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.
1669
1670 [RFC-2046] Moore, K., "Multipurpose Internet Mail Extensions (MIME)
1671 Part Two: Media Types", RFC 2046, November 1996.
1672
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.
1676
1677 [RFC-1766] Alvestrand, H., "Tags for the Identification of
1678 Languages", RFC 1766, March 1995.
1679
1680
1681
1682 Howes, et. al. Standards Track [Page 30]
1683
1684 RFC 2425 MIME Content-Type for Directory Information September 1998
1685
1686
1687 [RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type",
1688 RFC 2112, March 1997.
1689
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.
1694
1695 [RFC-1835] Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider,
1696 "Architecture of the WHOIS++ service", RFC 1835, August
1697 1995.
1698
1699 [RFC-1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
1700 Resource Locators (URL)", RFC 1738, December 1994.
1701
1702 [MIME-VCARD] Dawson, F., and T. Howes, "VCard MIME Directory
1703 Profile", RFC 2426, September 1998.
1704
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.
1708
1709 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
1710 Requirement Levels", BCP 14, RFC 2119, March 1997.
1711
1712 [RFC-2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
1713 Specifications: ABNF", RFC 2234, November 1997.
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738 Howes, et. al. Standards Track [Page 31]
1739
1740 RFC 2425 MIME Content-Type for Directory Information September 1998
1741
1742
1743 19. Authors' Addresses
1744
1745 Tim Howes
1746 Netscape Communications Corp.
1747 501 East Middlefield Rd.
1748 Mountain View, CA 94041
1749 USA
1750
1751 Phone: +1.415.937.3419
1752 EMail: howes@netscape.com
1753
1754
1755 Mark Smith
1756 Netscape Communications Corp.
1757 501 East Middlefield Rd.
1758 Mountain View, CA 94041
1759 USA
1760
1761 Phone: +1.415.937.3477
1762 EMail: mcs@netscape.com
1763
1764
1765 Frank Dawson
1766 Lotus Development Corporation
1767 6544 Battleford Drive
1768 Raleigh, NC 27613
1769 USA
1770
1771 Phone: +1-919-676-9515
1772 EMail: frank_dawson@lotus.com
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794 Howes, et. al. Standards Track [Page 32]
1795
1796 RFC 2425 MIME Content-Type for Directory Information September 1998
1797
1798
1799 20. Full Copyright Statement
1800
1801 Copyright (C) The Internet Society (1998). All Rights Reserved.
1802
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
1815 English.
1816
1817 The limited permissions granted above are perpetual and will not be
1818 revoked by the Internet Society or its successors or assigns.
1819
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.
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850 Howes, et. al. Standards Track [Page 33]
1851