idnits 2.17.1 draft-jennings-impp-vcard-05.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 246. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 223. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 236. ** 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (July 11, 2005) is 6863 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: '5' is defined on line 185, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 189, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 193, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 196, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 199, 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 2234 (ref. '4') (Obsoleted by RFC 4234) Summary: 5 errors (**), 0 flaws (~~), 8 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: January 12, 2006 July 11, 2005 6 vCard Extensions for Instant Messaging (IM) 7 draft-jennings-impp-vcard-05 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 12, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document describes an extension to vCard to support Instant 41 Messaging (IM) and Presence Protocol (PP) applications. IM and PP 42 are becoming increasingly common ways of communicating, and users 43 want to save this contact information in their address books. This 44 draft allows a URI that is associated with IM or PP to be specified 45 inside of a vCard. 47 1. Conventions 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC 2119 [3]. 53 2. 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 useable for 74 accessing it, but this document does not define any of the types. 75 For example a URI type of 77 "sip"[6] indicates to use SIP/SIMPLE, 78 "xmpp"[7] indicates to use XMPP, 79 "irc"[5] 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"[9] or "pres"[8] indicates to use a CPIM or CPP gateway. 85 The normative definition of this new vCard type is given in 86 Section 3, and an informational ABNF is provided in Section 4. 88 3. 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 93 IMPP". 95 This specification updates the "text/directory MIME Types" 96 subregistry in the "text/directory MIME Registrations" registry at 97 http://www.iana.org/assignments/text-directory-registrations with the 98 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 4. Formal Grammar 130 The following ABNF grammar [4] 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 5. 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 6. 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 7. Acknowledgments 164 Thanks to Paul Hoffman, Sam Roberts and Pekka Pessi for their 165 comments. 167 8. References 169 8.1 Normative References 171 [1] Howes, T., Smith, M., and F. Dawson, "A MIME -- --Content-Type 172 for Directory Information", RFC 2425, September 1998. 174 [2] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 175 RFC 2426, September 1998. 177 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 178 Levels", BCP 14, RFC 2119, March 1997. 180 8.2 Informational References 182 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 183 Specifications: ABNF", RFC 2234, November 1997. 185 [5] Butcher, S., "Uniform Resource Locator Schemes for Internet 186 Relay Chat Entities", draft-butcher-irc-url-04 (work in 187 progress), January 2004. 189 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 190 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 191 Session Initiation Protocol", RFC 3261, June 2002. 193 [7] Saint-Andre, P., "XMPP URI Format", draft-saintandre-xmpp-uri-08 194 (work in progress), December 2004. 196 [8] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, 197 August 2004. 199 [9] Peterson, J., "Common Profile for Instant Messaging (CPIM)", 200 RFC 3860, August 2004. 202 Author's Address 204 Cullen Jennings 205 Cisco Systems 206 170 West Tasman Drive 207 MS: SJC-21/2 208 San Jose, CA 95134 209 USA 211 Phone: +1 408 902-3341 212 Email: fluffy@cisco.com 214 Intellectual Property Statement 216 The IETF takes no position regarding the validity or scope of any 217 Intellectual Property Rights or other rights that might be claimed to 218 pertain to the implementation or use of the technology described in 219 this document or the extent to which any license under such rights 220 might or might not be available; nor does it represent that it has 221 made any independent effort to identify any such rights. Information 222 on the procedures with respect to rights in RFC documents can be 223 found in BCP 78 and BCP 79. 225 Copies of IPR disclosures made to the IETF Secretariat and any 226 assurances of licenses to be made available, or the result of an 227 attempt made to obtain a general license or permission for the use of 228 such proprietary rights by implementers or users of this 229 specification can be obtained from the IETF on-line IPR repository at 230 http://www.ietf.org/ipr. 232 The IETF invites any interested party to bring to its attention any 233 copyrights, patents or patent applications, or other proprietary 234 rights that may cover technology that may be required to implement 235 this standard. Please address the information to the IETF at 236 ietf-ipr@ietf.org. 238 Disclaimer of Validity 240 This document and the information contained herein are provided on an 241 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 242 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 243 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 244 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 245 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 246 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 248 Copyright Statement 250 Copyright (C) The Internet Society (2005). This document is subject 251 to the rights, licenses and restrictions contained in BCP 78, and 252 except as set forth therein, the authors retain all their rights. 254 Acknowledgment 256 Funding for the RFC Editor function is currently provided by the 257 Internet Society.