idnits 2.17.1 draft-jennings-impp-vcard-07.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 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 246. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 259. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (June 25, 2006) is 6514 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) == Unused Reference: '4' is defined on line 182, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 186, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 190, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 195, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 198, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2425 (ref. '1') (Obsoleted by RFC 6350) ** Obsolete normative reference: RFC 2426 (ref. '2') (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 4234 (ref. '3') (Obsoleted by RFC 5234) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 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 Expires: December 27, 2006 J. F. Reschke, Ed. 5 greenbytes 6 June 25, 2006 8 vCard Extensions for Instant Messaging (IM) 9 draft-jennings-impp-vcard-07 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 December 27, 2006. 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. This 46 draft allows a URI that is associated with IM or PP to be specified 47 inside 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 that indicates the address of a 66 service that provides IM, PP, or both. Also defined are some 67 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"[4] 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"[7] 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 with 98 the following information: 100 Type name: IMPP 102 Type purpose: To specify the URI for instant messaging and presence 103 protocol communications with the object the vCard represents. 105 Type encoding: 8bit 107 Type value: A single URI. The type of the URI indicates the protocol 108 that can be used for this contact. 110 Type special notes: The type can include the type parameter "TYPE" to 111 specify an intended use for the URI. The TYPE parameter values can 112 include: 114 o An indication of the type of communication for which this URI is 115 appropriate. This can be a value of PERSONAL or BUSINESS. 116 o An indication of the location of a device associated with this 117 URI. Values can be HOME, WORK, or MOBILE. 118 o The value PREF indicates this is a preferred address and has the 119 same semantics as the PREF value in a TEL type. 121 Additional information can be found in _RFCAAAA_. 123 Intended usage: COMMON 125 _[Note to IANA: Please replace AAAA with the RFC number for this 126 specification.]_ 128 3. Formal Grammar 130 The following ABNF grammar [3] extends the grammar found in RFC 2425 131 [1] and RFC 2426 [2]. 133 ;For name="IMPP" 134 param = impp-param ; Only impp parameters are allowed 136 value = uri 138 impp-param = "TYPE" "=" impp-type *("," impp-type) 140 impp-type = "PERSONAL" / "BUSINESS" / ; purpose of communications 141 "HOME" / "WORK" / "MOBILE" / 142 "PREF" / 143 iana-token / x-name; 144 ; Values are case insensitive 146 4. Example 148 BEGIN:vCard 149 VERSION:3.0 150 FN:Alice Doe 151 IMPP;TYPE=personal,pref:im:alice@example.com 152 END:vCard 154 5. Security Considerations 156 This does not introduce additional security issues beyond the current 157 vCard specification. It is worth noting that many people consider 158 their presence information more sensitive than other address 159 information. Any system that stores or transfers vCards needs to 160 carefully consider the privacy issues around this information. 162 6. Acknowledgments 164 Thanks to Paul Hoffman, Sam Roberts and Pekka Pessi for their 165 comments. 167 7. References 169 7.1. Normative References 171 [1] Howes, T., Smith, M., and F. Dawson, "A MIME-Content-Type for 172 Directory Information", RFC 2425, September 1998. 174 [2] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 175 RFC 2426, September 1998. 177 7.2. Informational References 179 [3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 180 Specifications: ABNF", RFC 4234, October 2005. 182 [4] Butcher, S., "Uniform Resource Locator Schemes for Internet 183 Relay Chat Entities", draft-butcher-irc-url-04 (work in 184 progress), January 2004. 186 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 187 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 188 Session Initiation Protocol", RFC 3261, June 2002. 190 [6] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) 191 and Uniform Resource Identifiers (URIs) for the Extensible 192 Messaging and Presence Protocol (XMPP)", 193 draft-saintandre-xmpp-iri-04 (work in progress), March 2006. 195 [7] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, 196 August 2004. 198 [8] Peterson, J., "Common Profile for Instant Messaging (CPIM)", 199 RFC 3860, August 2004. 201 Appendix A. Change Log (to be removed by RFC Editor before publication) 203 A.1. Since draft-jennings-impp-vcard-06.xml 205 Remove "Notational Conventions" (weren't actually used). Take out 206 reference to RFC2119 accordingly. 208 Highlight editing instructions for the RFC Editor. 210 Add link to mention of registration request email. 212 Update reference to ABNF RFC and XMPP URI/IRI draft. 214 Add Julian Reschke as Editor. 216 Authors' Addresses 218 Cullen Jennings 219 Cisco Systems 220 170 West Tasman Drive 221 MS: SJC-21/2 222 San Jose, CA 95134 223 USA 225 Phone: +1 408 902-3341 226 Email: fluffy@cisco.com 228 Julian F. Reschke (editor) 229 greenbytes GmbH 230 Hafenweg 16 231 Muenster, NW 48155 232 Germany 234 Phone: +49 251 2807760 235 Email: julian.reschke@greenbytes.de 237 Intellectual Property Statement 239 The IETF takes no position regarding the validity or scope of any 240 Intellectual Property Rights or other rights that might be claimed to 241 pertain to the implementation or use of the technology described in 242 this document or the extent to which any license under such rights 243 might or might not be available; nor does it represent that it has 244 made any independent effort to identify any such rights. Information 245 on the procedures with respect to rights in RFC documents can be 246 found in BCP 78 and BCP 79. 248 Copies of IPR disclosures made to the IETF Secretariat and any 249 assurances of licenses to be made available, or the result of an 250 attempt made to obtain a general license or permission for the use of 251 such proprietary rights by implementers or users of this 252 specification can be obtained from the IETF on-line IPR repository at 253 http://www.ietf.org/ipr. 255 The IETF invites any interested party to bring to its attention any 256 copyrights, patents or patent applications, or other proprietary 257 rights that may cover technology that may be required to implement 258 this standard. Please address the information to the IETF at 259 ietf-ipr@ietf.org. 261 Disclaimer of Validity 263 This document and the information contained herein are provided on an 264 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 265 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 266 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 267 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 268 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 269 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 271 Copyright Statement 273 Copyright (C) The Internet Society (2006). This document is subject 274 to the rights, licenses and restrictions contained in BCP 78, and 275 except as set forth therein, the authors retain all their rights. 277 Acknowledgment 279 Funding for the RFC Editor function is currently provided by the 280 Internet Society.