idnits 2.17.1 draft-ietf-asid-mime-direct-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 53 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 31 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 9 has weird spacing: '...fts are worki...' == Line 10 has weird spacing: '...ments of the ...' == Line 11 has weird spacing: '...t other group...' == Line 15 has weird spacing: '...and may be ...' == Line 19 has weird spacing: '...atus of any ...' == (48 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tim Howes 2 INTERNET DRAFT University of Michigan 3 draft-ietf-asid-mime-direct-00.txt 5 A MIME Content-Type for Directory Information 7 1. Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working docu- 10 ments of the Internet Engineering Task Force (IETF), its areas, and its 11 working groups. Note that other groups may also distribute working 12 documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet- Drafts as reference material 17 or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 21 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 22 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 23 ftp.isi.edu (US West Coast). 25 2. Abstract 27 This memo defines a MIME Content-Type for holding directory information. 28 The application/directory Content-Type is defined for holding basic tex- 29 tual directory information, for example, name, or email address. The 30 multipart/mixed Content-Type is used for handling more complicated 31 situations, in which non-textual information, for example, a photograph 32 or sound, must be represented. 34 3. Need for a MIME Directory Type 36 There are several situations in which users of Internet mail may wish to 37 exchange directory information: the email analogy of a "business card" 38 exchange; the conveyance of directory information to a user having only 39 email access to the Internet; the provision of machine-parsable address 40 information when purchasing goods or services over the Internet; etc. As 41 MIME [mime1] is used increasingly by other protocols, most notably HTTP, 42 it may be useful for these protocols to be able to carry directory 43 information in MIME format. Such a format, for example, could be used to 44 represent URC (uniform resource characteristics) information about 45 resources on the World Wide Web. 47 Expires January 1996 INTERNET DRAFT 49 4. Overview 51 The scheme described here for representing directory information in a 52 MIME Content-Type has two parts. First, the application/directory 53 Content-Type is defined for use in holding simple textual directory 54 information, for example name, title, or email address. The format uses 55 a simple "type: value" approach, which should be easily parsable by 56 existing MIME implementations. The allowable values for "type", their 57 correspondence with attributes or fields in several common directory 58 services, and the procedure by which new types are defined are given, 59 along with the formats for "value", their correspondence with values or 60 syntaxes in several common directory services, and the procedure by 61 which new values are defined. Many values are represented using the con- 62 ventions defined in RFC 1522 [mime2], allowing multiple character sets 63 to be used. 65 Directory entries can include far more than just textual information. 66 Some such information (e.g., an image or sound attribute) overlaps with 67 predefined MIME Content-Type. In these cases it may be desirable to 68 include the attributes in their well-known MIME formats. This situation 69 is handled by using a multipart/mixed Content-Type. The first component 70 of this type is an application/directory body part specifying any tex- 71 tual information in-line, and for information contained in other 72 Content-Types, the Content-IDs of those types. 74 5. The application/directory Content-Type 76 The application/directory Content-Type is used to hold textual directory 77 information and to point to other MIME body parts holding non-text 78 information. It is defined as follows, using the MIME subtype definition 79 from RFC 1521. 81 (1) MIME type name: application 83 (2) MIME subtype name: directory 85 (3) Required parameters: none 87 (4) Optional parameters: charset, source 89 Note that the value of the "source" parameter is intended to provide 90 the means by which applications knowledgable in the given directory 91 service protocol may obtain additional or more up-to-date 92 information from the directory service. It contains a URL pointing 93 to the directory entry from which the information came. When 94 directory information is available from more than one source, the 95 sending entity should pick what it considers to be the "best" source. 97 Expires January 1996 INTERNET DRAFT 99 (5) Encoding considerations: as specified by Content-Transfer-Encoding 101 (6) Security considerations: none 103 (7) Specification: 105 The "application/directory" Content-Type contains directory 106 information on one directory entry. Using the ABNF notation of RFC 107 822, the syntax for this content is: 109 ::= [ ":" ]* 111 ::= "cn" | "sn" | "fn" | "c" | "st" | "l" | "email" 112 | "title" | "fax" | "pager" | "wphone" | "hphone" 113 | "waddress" | "haddress" | "uri" | "o" | "photo" 114 | "type" | "name" | 116 ::= 119 ::= a character string whose syntax depends on 121 The meanings of the various "types" and the format of the corresponding 122 "values" are given below in Table 1. The corresponding types or 123 fields in several existing directory services are given in Appendix A. 125 type used to hold format of values 126 -------------------------------------------------------------------- 127 waddress work postal address a sequence of text lines separated 128 by 129 haddress home postal address a sequence of text lines separated 130 by 131 c country text 132 cn name text 133 email RFC 822 email address an RFC 822 email address 134 fax fax telephone number text 135 fn first name text 136 l locality name text 137 o organization name text 138 pager pager telephone number text 139 wphone voice telephone number text 140 at work 141 hphone voice telephone number text 142 at home 143 image image an RFC 822 msg-id 144 sound sound an RFC 822 msg-id 145 sn surname text 146 st state or province text 147 Expires January 1996 INTERNET DRAFT 149 title title text 150 type type of object an object type value as defined 151 in this document, registered with 152 IANA, or bilaterally agreed upon 153 (see note below) 154 uri uniform resource 155 identifier an RFC 1738 URL 156 name directory name a text version of the object's 157 directory name 158 -------------------------------------------------------------------- 159 Table 1. Types, their meanings, and syntaxes. 161 Note that text values follow the RFC 822 convention for continued 162 lines, except that a "continued" line in an address marks 163 the next line of the address, not a continuation of the current line. 165 Note that the charset parameter should be used to identify character 166 sets other than US ASCII. If different attributes within the same 167 "application/directory" body component have different character sets, 168 they can both be converted to UNICODE, or another character set 169 which is a superset of both. 171 Note that the "image" and "sound" types contain a Content-ID and are 172 only used in conjunction with the multipart/mixed Content-Type defined 173 in the next section. 175 The allowable values for the "type" type are listed below. 177 "person" 179 Further values may be registered with IANA or bilaterally agreed 180 upon. A bilaterally agreed upon value consists of the two characters 181 "X-" or "x-" followed, with no intervening white space, by any 182 other token. 184 Note that the "name" field may or may not be meaningful, depending 185 on the source directory service. 187 [[ Note that the IANA registration schemes referred to here will be 188 defined in a later version of this document. ]] 190 6. Use of the multipart/mixed Content-Type 192 The multipart/mixed Content-Type can be used to hold directory entries 193 containing both text and non-text information. The first body part must 194 have a Content-Type of "application/directory". This part defines the 195 name and source of the information, holds any text information from the 196 entry, and makes reference to subsequent body parts holding non-text 197 Expires January 1996 INTERNET DRAFT 199 directory information via their Content-IDs. 201 The body parts referred to do not have to be in any particular order, as 202 long as they come after the "application/directory" part referring to 203 them. 205 7. Examples 207 The following example illustrates simple use of the 208 "application/directory" Content-Type. 210 From: Whomever 211 To: Someone 212 Subject: whatever 213 MIME-Version: 1.0 214 Message-ID: 215 Content-Type: application/directory 216 Content-ID: 218 cn: Babs Jensen 219 cn: Barbara J Jensen 220 sn: Jensen 221 email: babs@umich.edu 222 wphone: +1 313 747-4454 224 The next example illustrates the use of RFC 1522 encoding to include 225 non-ascii characters in some of the information returned, and the use of 226 the optional "name" and "source" parameters. 228 Content-Type: application/directory; 229 charset="iso-8859-1"; 230 source="ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US" 231 Content-ID: 232 Content-Transfer-Encoding: Quoted-Printable 234 cn: Bj=F8rn Jensen 235 waddress: 535 W. William St. 236 Ann Arbor, MI 48103 237 sn: Jensen 238 email: bjorn@umich.edu 239 wphone: +1 313 747-4454 241 The final example illustrates the use of the multipart/mixed Content- 242 Type to include non-textual directory data. 244 Content-Type: multipart/mixed; boundary=woof 245 Content-ID: 246 Expires January 1996 INTERNET DRAFT 248 --woof 249 Content-Type: application/directory; 250 charset="iso-8859-1"; 251 source="ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US" 252 Content-ID: 253 Content-Transfer-Encoding: Quoted-Printable 255 cn: Bj=F8rn Jensen 256 sn: Jensen 257 email: bjorn@umich.edu 258 image: 259 sound: 260 wphone: +1 313 747-4454 261 name: cn=3DBjorn Jensen, o=3DUniversity of Michigan,c=3DUS 263 --woof 264 Content-Type: image/jpeg 265 Content-ID: 267 <...image data...> 269 --woof 270 Content-Type: message/external-body; 271 name="myvoice.au"; 272 site="myhost.com"; 273 access-type=ANON-FTP; 274 directory="pub/myname"; 275 mode="image" 277 Content-Type: audio/basic 278 Content-ID: 280 --woof-- 282 8. Security Considerations 284 Internet mail is subject to many well known security attacks, including 285 monitoring, replay, and forgery. Applications should also take care to 286 display directory data in a "safe" environment (e.g., PostScript-valued 287 attributes). 289 9. Bibliography 291 [ldap1] Yeong, W., Howes, T., Kille, S., "Lightweight Directory Access 292 Protocol", Request for Comment (RFC) 1777, March 1995. 294 [ldap2] Howes, T., Kille, S., Yeong, W., Robbins, C.J., "The String 295 Representation of Standard Attribute Syntaxes", Request for 296 Expires January 1996 INTERNET DRAFT 298 Comment (RFC) 1778, March 1995. 300 [rfc822] Crocker, D., "Standard for the Format of ARPA Internet Text 301 Messages", STD 11, RFC 822, August 1982. 303 [mime1] Borenstein, N., Freed, N., "MIME (Multipurpose Internet Mail 304 Extensions) Part One: Mechanisms for Specifying and Describing 305 the Format of Internet Message Bodies", RFC 1521, September 306 1993. 308 [mime2] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 309 Two: Message Header Extensions for Non-ASCII Text", RFC 1522, 310 September 1993. 312 [x500] "Information Processing Systems - Open Systems Interconnection 313 - The Directory: Overview of Concepts, Models and Services", 314 ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988. 316 10. Author's Address 318 Tim Howes 319 University of Michigan 320 ITD Research Systems 321 535 W William St. 322 Ann Arbor, MI 48103-4943 323 USA 324 +1 313 747-4454 325 tim@umich.edu 327 11. Appendix A - Correspondence With Various Directory Services 329 name in name in name in 330 type LDAP/X.500 SOLO WHOIS++ 331 -------------------------------------------------------------------- 332 waddress postalAddress Work-address Work-Postal 333 haddress homePostalAddress Home-Postal 334 c friendlyCountryName,co C Country 335 c,countryName 336 cn commonName,cn Name,CommonName Name 337 email rfc822Mailbox,mail Email-address, Email 338 rfc822Mailbox 339 fax facsimileTelephoneNumber Fax-telephone Work-Fax, 340 Home-Fax 341 fn givenName First name 342 l localityName,l LocalityName 343 o organizationName,o Organization Organization-Name 344 pager pagerTelephoneNumber, 345 pager 346 Expires January 1996 INTERNET DRAFT 348 wphone telephoneNumber Work-telephone Work-Phone 349 hphone homeTelephoneNumber Home-Phone, 350 photo jpegPhoto,photo 351 sn surname,sn Surname 352 st stateOrProvinceName,st StateOrProvinceName State 353 title title,personalTitle Title Title 354 type objectClass Template Template-Type 355 uri labeledURI Description-URI