idnits 2.17.1 draft-jennings-impp-vcard-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 373. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (September 21, 2006) is 6399 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2425 (ref. '1') (Obsoleted by RFC 6350) ** Obsolete normative reference: RFC 2426 (ref. '2') (Obsoleted by RFC 6350) ** Obsolete normative reference: RFC 4234 (ref. '4') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4622 (ref. '6') (Obsoleted by RFC 5122) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track J. Reschke, Ed. 5 Expires: March 25, 2007 greenbytes 6 September 21, 2006 8 vCard Extensions for Instant Messaging (IM) 9 draft-jennings-impp-vcard-08 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 25, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes an extension to vCard to support Instant 43 Messaging (IM) and Presence Protocol (PP) applications. IM and PP 44 are becoming increasingly common ways of communicating, and users 45 want to save this contact information in their address books. It 46 allows a URI that is associated with IM or PP to be specified inside 47 of a vCard. 49 Editorial Note (To be removed by RFC Editor before publication) 51 This work is being discussed on the imc-vcard@imc.org mailing list. 53 1. Overview 55 As more and more people use various instant messaging (IM) and 56 presence protocol (PP) applications, it becomes important for them to 57 be able to share this contact address information along with the rest 58 of their contact information. RFC 2425 [1] and RFC 2426 [2] define a 59 standard format for this information, which is referred to as vCard. 60 This document defines a new type in a vCard for representing instant 61 IM and PP URIs. It is very similar to existing types for 62 representing email address and telephone contact information. 64 The type entry to hold this new contact information is an IMPP type. 65 The IMPP entry has a single URI (see RFC 3986 [3]) that indicates the 66 address of a service that provides IM, PP, or both. Also defined are 67 some parameters that give hints as to when certain URIs would be 68 appropriate. A given vCard can have multiple IMPP entries, but each 69 entry can contain only one URI. Each IMPP entry can contain multiple 70 parameters. Any combination of parameters is valid, although a 71 parameter should occur at most once in a given IMPP entry. 73 The type of URI indicates what protocols might be usable for 74 accessing it, but this document does not define any of the types. 75 For example a URI type of 77 "sip" [5] indicates to use SIP/SIMPLE, 78 "xmpp" [6] indicates to use XMPP, 79 "irc" [7] indicates to use IRC, 80 "ymsgr" indicates to use yahoo, 81 "msn" might indicate to use Microsoft messenger, 82 "aim" indicates to use AOL, and 83 "im" [8] or "pres" [9] indicates to use a CPIM or CPP gateway. 85 The normative definition of this new vCard type is given in 86 Section 2, and an informational ABNF is provided in Section 3. 88 2. IANA Considerations 90 The required email to define this extension (as defined in RFC2425) 91 was sent on October 29, 2004 to the ietf-mime-direct@imc.org mailing 92 list with the subject "Registration of text/directory MIME type IMPP" 93 (see 94 ). 96 This specification updates the "text/directory MIME Types" 97 subregistry in the "text/directory MIME Registrations" registry at 98 http://www.iana.org/assignments/text-directory-registrations with the 99 following information: 101 Type name: IMPP 103 Type purpose: To specify the URI for instant messaging and presence 104 protocol communications with the object the vCard represents. 106 Type encoding: 8bit 108 Type value: A single URI. The type of the URI indicates the protocol 109 that can be used for this contact. 111 Type special notes: The type may include the type parameter "TYPE" to 112 specify an intended use for the URI. The TYPE parameter values 113 include one or more of the following: 115 o An indication of the type of communication for which this URI is 116 appropriate. This can be a value of PERSONAL or BUSINESS. 117 o An indication of the location of a device associated with this 118 URI. Values can be HOME, WORK, or MOBILE. 119 o The value PREF indicates this is a preferred address and has the 120 same semantics as the PREF value in a TEL type. 122 Additional information can be found in _RFCAAAA_. 124 Intended usage: COMMON 126 _[Note to IANA: Please replace AAAA with the RFC number for this 127 specification.]_ 129 3. Formal Grammar 131 The following ABNF grammar [4] extends the grammar found in RFC 2425 132 [1] (Section 5.8.2) and RFC 2426 [2] (Section 4). 134 ;For name="IMPP" 135 param = impp-param ; Only impp parameters are allowed 137 value = URI 138 ; URI defined in Section 3 of [3] 140 impp-param = "TYPE" "=" impp-type *("," impp-type) 142 impp-type = "PERSONAL" / "BUSINESS" / ; purpose of communications 143 "HOME" / "WORK" / "MOBILE" / 144 "PREF" / 145 iana-token / x-name; 146 ; Values are case insensitive 148 4. Example 150 BEGIN:vCard 151 VERSION:3.0 152 FN:Alice Doe 153 IMPP;TYPE=personal,pref:im:alice@example.com 154 END:vCard 156 5. Security Considerations 158 This does not introduce additional security issues beyond the current 159 vCard specification. It is worth noting that many people consider 160 their presence information more sensitive than other address 161 information. Any system that stores or transfers vCards needs to 162 carefully consider the privacy issues around this information. 164 6. Acknowledgments 166 Thanks to Brian Carpenter, Lars Eggert, Ted Hardie, Paul Hoffman, Sam 167 Roberts and Pekka Pessi for their comments. 169 7. References 171 7.1. Normative References 173 [1] Howes, T., Smith, M., and F. Dawson, "A MIME-Content-Type for 174 Directory Information", RFC 2425, September 1998. 176 [2] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 177 RFC 2426, September 1998. 179 [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 180 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 181 January 2005. 183 [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 184 Specifications: ABNF", RFC 4234, October 2005. 186 7.2. Informational References 188 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 189 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 190 Session Initiation Protocol", RFC 3261, June 2002. 192 [6] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) 193 and Uniform Resource Identifiers (URIs) for the Extensible 194 Messaging and Presence Protocol (XMPP)", RFC 4622, July 2006. 196 [7] Butcher, S., "Uniform Resource Locator Schemes for Internet 197 Relay Chat Entities", draft-butcher-irc-url-04 (work in 198 progress), January 2004. 200 [8] Peterson, J., "Common Profile for Instant Messaging (CPIM)", 201 RFC 3860, August 2004. 203 [9] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, 204 August 2004. 206 Appendix A. Change Log (to be removed by RFC Editor before publication) 208 A.1. Since draft-jennings-impp-vcard-06.xml 210 Remove "Notational Conventions" (weren't actually used). Take out 211 reference to RFC2119 accordingly. 213 Highlight editing instructions for the RFC Editor. 215 Add link to mention of registration request email. 217 Update reference to ABNF RFC and XMPP URI/IRI draft. 219 Add Julian Reschke as Editor. 221 Appendix B. Since draft-jennings-impp-vcard-07.xml 223 Update XMPP URI/IRI reference. 225 Add and resolve issues "abnf-ref-normative", "clarify-type- 226 recurrence" and "cite-rfc3986-for-URI". 228 Add open issue "mention-other-approaches". 230 Appendix C. Resolved issues (to be removed by RFC Editor before 231 publication) 233 Issues that were either rejected or resolved in this version of this 234 document. 236 C.1. ref-rfc4622 238 Type: edit 240 julian.reschke@greenbytes.de (2006-07-26): Update ref to XMPP URI/IRI 241 spec. 243 Resolution: Done. 245 C.2. abnf-ref-normative 247 Type: change 249 julian.reschke@greenbytes.de (2006-09-13): Ted Hardie: I believe 250 citing the ABNF RFC as normative is also required. 252 Resolution (2006-09-13): Done. 254 C.3. cite-rfc3986-for-URI 256 Type: change 258 julian.reschke@greenbytes.de (2006-09-13): Ted Hardie: This document 259 apparently imports the definition of uri from 2425, which in turn 260 says that URI is "as defined in 1738". 1738's description of URIs has 261 long been superseded, and its formal description of genericurl (the 262 closest thing to this) is in RFC822's BNF-like grammar, not ABNF. 263 May I suggest this document cite RFC 3986 directly? It's a full 264 standard. 266 Resolution (2006-09-13): Done. 268 C.4. clarify-type-recurrence 270 Type: change 272 julian.reschke@greenbytes.de (2006-09-14): Clarify that type 273 parameter contains one or more values. 275 Resolution (2006-09-14): Done. 277 Appendix D. Open issues (to be removed by RFC Editor prior to 278 publication) 280 D.1. edit 282 Type: edit 284 julian.reschke@greenbytes.de (2006-06-25): Umbrella issue for 285 editorial fixes/enhancements. 287 D.2. irc-uri 289 Type: edit 291 julian.reschke@greenbytes.de (2006-06-25): Take out reference to IRC 292 URI draft (which is dead)? 294 D.3. mention-other-approaches 296 Type: edit 298 julian.reschke@greenbytes.de (2006-09-21): Lars Eggert (IESG 299 discussion): Might want to mention that some vendors have already 300 extended the vcard format to include IM addresses. 302 julian.reschke@greenbytes.de (2006-09-21): I think there are two 303 sides to this: (1) is there a deployed format that we could use 304 instead of inventing a new one, and (2) if we decide to invent a new 305 one, should we discuss other approaches we rejected? My take: (1) 306 the format used by Apple (mentioned by Lars) assigns a new type for 307 each IMPP URI scheme - that seems to be a bad idea as it doesn't 308 allow clients to uniformly treat different IMPP systems without prior 309 knowledge of what the URI scheme is. So no, the format used by Apple 310 doesn't seem to be a good idea. As for (2), I'd like to avoid that 311 additional work. However I'm open to add minimal text mentioning 312 other approaches if people make a concrete proposal for spec text. 314 Authors' Addresses 316 Cullen Jennings 317 Cisco Systems 318 170 West Tasman Drive 319 MS: SJC-21/2 320 San Jose, CA 95134 321 USA 323 Phone: +1 408 902-3341 324 Email: fluffy@cisco.com 326 Julian F. Reschke (editor) 327 greenbytes GmbH 328 Hafenweg 16 329 Muenster, NW 48155 330 Germany 332 Phone: +49 251 2807760 333 Email: julian.reschke@greenbytes.de 335 Full Copyright Statement 337 Copyright (C) The Internet Society (2006). 339 This document is subject to the rights, licenses and restrictions 340 contained in BCP 78, and except as set forth therein, the authors 341 retain all their rights. 343 This document and the information contained herein are provided on an 344 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 345 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 346 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 347 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 348 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 349 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 351 Intellectual Property 353 The IETF takes no position regarding the validity or scope of any 354 Intellectual Property Rights or other rights that might be claimed to 355 pertain to the implementation or use of the technology described in 356 this document or the extent to which any license under such rights 357 might or might not be available; nor does it represent that it has 358 made any independent effort to identify any such rights. Information 359 on the procedures with respect to rights in RFC documents can be 360 found in BCP 78 and BCP 79. 362 Copies of IPR disclosures made to the IETF Secretariat and any 363 assurances of licenses to be made available, or the result of an 364 attempt made to obtain a general license or permission for the use of 365 such proprietary rights by implementers or users of this 366 specification can be obtained from the IETF on-line IPR repository at 367 http://www.ietf.org/ipr. 369 The IETF invites any interested party to bring to its attention any 370 copyrights, patents or patent applications, or other proprietary 371 rights that may cover technology that may be required to implement 372 this standard. Please address the information to the IETF at 373 ietf-ipr@ietf.org. 375 Acknowledgment 377 Funding for the RFC Editor function is provided by the IETF 378 Administrative Support Activity (IASA).