idnits 2.17.1 draft-ietf-asid-mime-person-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 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 6 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 ...' == (34 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) -- Missing reference section? 'MIME-DIR' on line 213 looks like a reference -- Missing reference section? 'DIR-WPP' on line 323 looks like a reference -- Missing reference section? 'RFC-822' on line 300 looks like a reference -- Missing reference section? 'RFC-1777' on line 351 looks like a reference -- Missing reference section? 'RFC-1835' on line 351 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tim Howes 2 INTERNET DRAFT Mark Smith 3 draft-ietf-asid-mime-person-00.txt University of Michigan 5 An Application/Directory MIME Content-Type White Pages Person Profile 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 directory information profile for a white pages per- 28 son, to be carried in an application/directory MIME Content-Type. The 29 profile consists of type definitions (e.g., for name and email address) 30 and the corresponding format of values that each type is allowed to con- 31 tain. 33 3. Overview 35 The application/directory MIME Content-Type defined in [MIME-DIR] is 36 used for representing directory information in MIME format. It defines a 37 general framework for carrying "type: value" style information in the 38 body of a MIME message, but does not define specific types or values. 39 This document defines a profile containing the types and corresponding 40 value formats for representing information about an Internet white pages 41 person. The profile reflects the Internet white pages service schema 42 defined in [DIR-WPP]. 44 Expires July 1996 INTERNET DRAFT 46 4. The White Pages Person Profile 48 The profile is defined as follows, using the profile registration tem- 49 plate from Section 8 of [MIME-DIR]. 51 4.1. Person profile definition 53 To: ietf-mime-direct@umich.edu 54 Subject: Registration of application/directory MIME profile wpperson 56 Profile name: wpperson 58 Profile purpose: to hold white pages information about a person 60 Profile types: address, cn, sn, email, o, phone, misc, lastmoddate, 61 lastmodby, lastmodtype, dataowner, datasource 63 The associated type definitions follow, using the type registration tem- 64 plate from Section 9 of [MIME-DIR]. 66 4.2. Address Type Definition 68 To: ietf-mime-direct@umich.edu 69 Subject: Registration of application/directory MIME type address 71 Type name: address 73 Type purpose: to hold postal address information 75 Type encoding: a sequence of text lines separated by SPACE 77 Type special notes: The usual line-folding technique described in 78 [MIME-DIR] can be used to represent multi-line addresses (i.e., 79 applications should interpret folded address lines as separate lines 80 in a single address, not a continuation of one address line). 82 4.3. Cn Type Definition 84 To: ietf-mime-direct@umich.edu 85 Subject: Registration of application/directory MIME type cn 87 Type name: cn 89 Type purpose: to hold a name 91 Type encoding: text 93 Expires July 1996 INTERNET DRAFT 95 4.4. Sn Type Definition 97 To: ietf-mime-direct@umich.edu 98 Subject: Registration of application/directory MIME type sn 100 Type name: sn 102 Type purpose: to hold a last name, family name, or surname 104 Type encoding: text 106 4.5. Email Type Definition 108 To: ietf-mime-direct@umich.edu 109 Subject: Registration of application/directory MIME type email 111 Type name: email 113 Type purpose: to hold an Internet email address 115 Type encoding: text representing an email address as defined in sec- 116 tion 6.1 of [RFC-822] 118 4.6. O Type Definition 120 To: ietf-mime-direct@umich.edu 121 Subject: Registration of application/directory MIME type o 123 Type name: o 125 Type purpose: to hold an organization name 127 Type encoding: text 129 4.7. Phone Type Definition 131 To: ietf-mime-direct@umich.edu 132 Subject: Registration of application/directory MIME type phone 134 Type name: phone 136 Type purpose: to hold a voice, fax, cellular, mobile, or other type 137 of telephone phone number 139 Type encoding: text 141 Type special notes: 143 Expires July 1996 INTERNET DRAFT 145 If this type is to be used to hold multiple kinds of telephone 146 numbers (e.g., fax and voice), it is advisable to distinguish them 147 with some kind of descriptive comment in the value. For example: 149 phone: +1 313 747-4454 (voice) 150 phone: +1 313 764-5140 (fax) 152 4.8. Misc Type Definition 154 To: ietf-mime-direct@umich.edu 155 Subject: Registration of application/directory MIME type misc 157 Type name: misc 159 Type purpose: to hold miscellaneous information 161 Type encoding: text 163 Type special notes: 165 This type is intended to hold miscellaneous descriptive informa- 166 tion about a person that does not fit in one of the other types 167 defined above. It should not be used to hold information for 168 which other types have been defined. 170 4.9. Lastmodby Type Definition 172 To: ietf-mime-direct@umich.edu 173 Subject: Registration of application/directory MIME type lastmodby 175 Type name: lastmodby 177 Type purpose: to hold the directory name of the entity which last 178 modified a directory entity 180 Type encoding: text 182 Type special notes: 184 Note that the text encoding of the directory name may be directory 185 service specific. 187 4.10. Lastmoddate Type Definition 189 To: ietf-mime-direct@umich.edu 190 Subject: Registration of application/directory MIME type lastmoddate 192 Type name: lastmoddate 194 Expires July 1996 INTERNET DRAFT 196 Type purpose: to hold the time when a directory entity was last modi- 197 fied 199 Type encoding: a string containing a time as defined in section 5.1 200 of [RFC-822] for "date-time". 202 4.11. Lastmodtype Type Definition 204 To: ietf-mime-direct@umich.edu 205 Subject: Registration of application/directory MIME type lastmodtype 207 Type name: lastmodtype 209 Type purpose: to hold the type of information last modified in a 210 directory entity 212 Type encoding: text containing a type name as defined in section 5 of 213 [MIME-DIR] for "type". 215 4.12. Dataowner Type Definition 217 To: ietf-mime-direct@umich.edu 218 Subject: Registration of application/directory MIME type dataowner 220 Type name: dataowner 222 Type purpose: to identify the owner of directory information pertain- 223 ing to an entity 225 Type encoding: text 227 4.13. Datasource Type Definition 229 To: ietf-mime-direct@umich.edu 230 Subject: Registration of application/directory MIME type datasource 232 Type name: datasource 234 Type purpose: to identify the source of directory information per- 235 taining to an entity 237 Type encoding: text 239 5. Examples 241 The following example illustrates simple use of the 242 "application/directory" Content-Type with the "person" profile. 244 Expires July 1996 INTERNET DRAFT 246 From: Whomever 247 To: Someone 248 Subject: whatever 249 MIME-Version: 1.0 250 Message-ID: 251 Content-Type: application/directory; profile="person" 252 Content-ID: 254 cn: Babs Jensen 255 cn: Barbara J Jensen 256 sn: Jensen 257 email: babs@umich.edu 258 phone: +1 313 747-4454 (voice) 259 phone: +1 313 764-5140 (fax) 261 The next example illustrates the use of RFC 1522 encoding to include 262 non-ascii characters in some of the "person" profile types. 264 Content-Type: application/directory; 265 profile="person"; 266 charset="iso-8859-1" 267 Content-ID: 268 Content-Transfer-Encoding: Quoted-Printable 270 cn: Bj=F8rn Jensen 271 sn: Jensen 272 address: 535 W. William St. 273 Ann Arbor, MI 48103 274 email: bjorn@umich.edu 275 phone: +1 313 747-4454 277 6. Security Considerations 279 Internet mail is subject to many well known security attacks, including 280 monitoring, replay, and forgery. Applications should also take care to 281 display directory data in a "safe" environment (e.g., PostScript-valued 282 types). 284 7. Acknowledgements 286 This material is based upon work supported by the National Science Foun- 287 dation under Grant No. NCR-9416667. 289 8. Bibliography 291 [RFC-1777]Yeong, W., Howes, T., Kille, S., "Lightweight Directory Access 292 Protocol", Request for Comment (RFC) 1777, March 1995. 294 Expires July 1996 INTERNET DRAFT 296 [RFC-1778]Howes, T., Kille, S., Yeong, W., Robbins, C.J., "The String 297 Representation of Standard Attribute Syntaxes", Request for 298 Comment (RFC) 1778, March 1995. 300 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 301 Messages", STD 11, RFC 822, August 1982. 303 [RFC-1521]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 [RFC-1522]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 [RFC-1835]Deutsch, P., Schoultz, R., Faltstrom, P., Weider, C., "Archi- 317 tecture of the WHOIS++ service", August 1995. 319 [MIME-DIR]Howes, T., Smith, M., "A MIME Content-Type for Directory 320 Information," Internet-Draft draft-ietf-asid-mime-direct- 321 01.txt, January, 1996. 323 [DIR-WPP] Genovese, T., "A Common Schema for the Internet White Pages 324 Service," Internet-Draft draft-ietf-ids-iwps-schema-spec- 325 00.txt, November 1995. 327 9. Author's Address 329 Tim Howes 330 University of Michigan 331 535 W William St. 332 Ann Arbor, MI 48103-4943 333 USA 334 +1 313 747-4454 335 tim@umich.edu 337 Mark Smith 338 University of Michigan 339 535 W William St. 340 Ann Arbor, MI 48103-4943 341 USA 342 +1 313 764-2277 343 mcs@umich.edu 345 Expires July 1996 INTERNET DRAFT 347 10. Appendix A - Correspondence With Various Directory Services 349 The scheme defined here is intended to be general enough to work with 350 any number of directory services, including, but not limited to LDAP 351 [RFC-1777], WHOIS++ [RFC-1835], SOLO, and X.500 [x500]. This appendix 352 provides a mapping between attribute types or fields in these directory 353 services and the scheme defined here. 355 name in name in name in 356 type LDAP/X.500 SOLO WHOIS++ 357 -------------------------------------------------------------------- 358 address postalAddress Work-address Work-Postal 359 homePostalAddress Home-Postal 361 cn commonName Name Name 362 cn CommonName 364 sn surname Surname 365 sn 367 email rfc822Mailbox Email-address Email 368 mail rfc822Mailbox 369 mhsORAddresses X400 371 o organizationName Organization Organization-Name 372 o 374 phone telephoneNumber Work-telephone Work-Phone 375 homeTelephoneNumber Fax-telephone Home-Phone 376 facsimileTelephoneNumber Work-Fax 377 Home-Fax