idnits 2.17.1 draft-jennings-impp-vcard-04.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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 239. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 216. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 223. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 229. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 245), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 4) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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 (October 22, 2004) is 7124 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 178, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 182, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 186, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 189, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 192, 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) == Outdated reference: A later version (-08) exists of draft-saintandre-xmpp-uri-06 Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IMPP C. Jennings 2 Internet-Draft Cisco Systems 3 Expires: April 22, 2005 October 22, 2004 5 vCard Extensions for IM 6 draft-jennings-impp-vcard-04 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 22, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document describes an extension to vCard to support Instant 40 Messaging (IM) and Presence Protocol (PP) applications. IM and PP 41 are becoming increasingly common ways of communicating, and users 42 want to save this contact information in their address books. This 43 draft allows a URI that is associated with IM or PP to be specified 44 inside of a vCard. 46 1. Conventions 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [3]. 52 2. Overview 54 As more and more people use various instant messaging (IM) and 55 presence protocol (PP) applications, it becomes important for them to 56 be able to share this contact address information along with the rest 57 of their contact information. RFC 2425 [1] and RFC 2426 [2] define a 58 standard format for this information which is referred to as vCard. 59 This document defines a new type in a vCard for representing instant 60 IM and PP URIs. It is very similar to existing types for 61 representing email address and telephone contact information. 63 The type entry to hold this new contact information is an IMPP type. 64 The IMPP entry has a single URI that indicates the address of a 65 service that provides IM, PP, or both. Also defined are some 66 parameters that give hints as to when certain URIs would be 67 appropriate. A given vCard can have multiple IMPP entries but each 68 entry can contain only one URI. Each IMPP entry can contain multiple 69 parameters. Any combination of parameters is valid, though a 70 parameter should occur at most once in a given IMPP entry. 72 The type of URI indicates what protocols might be useable for 73 accessing it, but this document does not define any of the types. 74 For example a URI type of 76 "sip"[6] indicates to use SIP/SIMPLE, 77 "xmpp"[7] indicates to use XMPP, 78 "irc"[5] indicates to use IRC, 79 "ymsgr" indicates to use yahoo, 80 "msn" might indicate to use Microsoft messenger, 81 "aim" indicates to use AOL, and 82 "im"[9] or "pres"[8] indicates to use a CPIM or CPP gateway. 84 The normative definition of this new vCard type is given in Section 85 3, and an informational ABNF is provided in Section 4. 87 3. IMPP Type Definition 89 To: ietf-mime-direct@imc.org 91 Subject: Registration of text/directory MIME type IMPP 93 Type name: IMPP 95 Type purpose: To specify the URI for instant messaging and presence 96 protocol communication with the object the vCard represents. 98 Type encoding: 8bit 100 Type value: A single URI. The type of the URI indicates the protocol 101 that can be used for this contact. 103 Type special notes: The type can include the type parameter "TYPE" to 104 specify an intended use for the URI. The TYPE parameter values can 105 include: 107 An indication of the type of communication for which this URI is 108 appropriate. This can be a value of PERSONAL or BUSINESS. 110 An indication of the location of a device associated with this 111 URI. Values can be HOME, WORK, or MOBILE. 113 The value PREF indicates this is a preferred address and has the 114 same semantics as the PREF value in a TEL type. 116 Intended usage: COMMON 118 4. Formal Grammar 120 The following ABNF grammar[4] extends the grammar found in RFC 2425 121 [1] and RFC 2426 [2]. 123 ;For name="IMPP" 124 param = impp-param ; Only impp parameters are allowed 126 value = uri 128 impp-param = "TYPE" "=" impp-type *("," impp-type) 130 impp-type = "PERSONAL" / "BUSINESS" / ; purpose of communications 131 "HOME" / "WORK" / "MOBILE" / 132 "PREF" / 133 iana-token / x-name; 134 ; Values are case insensitive 136 5. Example 138 BEGIN:vCard 139 VERSION:3.0 140 FN:Alice Doe 141 IMPP;TYPE=personal,pref:im:alice@example.com 142 END:vCard 144 6. IANA Considerations 146 Section 3 forms the IANA registration. 148 7. Security Considerations 150 This does not introduce additional security issues beyond current 151 vCard specification. It is worth noting that many people consider 152 their presence information more sensitive than some other address 153 information. Any system that stores or transfers vCards needs to 154 carefully consider the privacy issues around this information. 156 8. Acknowledgments 158 Thanks to Paul Hoffman, Sam Roberts and Pekka Pessi for comments. 160 9. References 162 9.1 Normative References 164 [1] Howes, T., Smith, M. and F. Dawson, "A MIME -- --Content-Type 165 for Directory Information", RFC 2425, September 1998. 167 [2] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 168 2426, September 1998. 170 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 171 Levels", BCP 14, RFC 2119, March 1997. 173 9.2 Informational References 175 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 176 Specifications: ABNF", RFC 2234, November 1997. 178 [5] Butcher, S., "Uniform Resource Locator Schemes for Internet 179 Relay Chat Entities", draft-butcher-irc-url-04 (work in 180 progress), January 2004. 182 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 183 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 184 Session Initiation Protocol", RFC 3261, June 2002. 186 [7] Saint-Andre, P., "XMPP URI Format", draft-saintandre-xmpp-uri-06 187 (work in progress), October 2004. 189 [8] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, 190 August 2004. 192 [9] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 193 3860, August 2004. 195 Author's Address 197 Cullen Jennings 198 Cisco Systems 199 170 West Tasman Drive 200 MS: SJC-21/2 201 San Jose, CA 95134 202 USA 204 Phone: +1 408 902-3341 205 EMail: fluffy@cisco.com 207 Intellectual Property Statement 209 The IETF takes no position regarding the validity or scope of any 210 Intellectual Property Rights or other rights that might be claimed to 211 pertain to the implementation or use of the technology described in 212 this document or the extent to which any license under such rights 213 might or might not be available; nor does it represent that it has 214 made any independent effort to identify any such rights. Information 215 on the procedures with respect to rights in RFC documents can be 216 found in BCP 78 and BCP 79. 218 Copies of IPR disclosures made to the IETF Secretariat and any 219 assurances of licenses to be made available, or the result of an 220 attempt made to obtain a general license or permission for the use of 221 such proprietary rights by implementers or users of this 222 specification can be obtained from the IETF on-line IPR repository at 223 http://www.ietf.org/ipr. 225 The IETF invites any interested party to bring to its attention any 226 copyrights, patents or patent applications, or other proprietary 227 rights that may cover technology that may be required to implement 228 this standard. Please address the information to the IETF at 229 ietf-ipr@ietf.org. 231 Disclaimer of Validity 233 This document and the information contained herein are provided on an 234 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 235 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 236 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 237 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 238 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 239 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 241 Copyright Statement 243 Copyright (C) The Internet Society (2004). This document is subject 244 to the rights, licenses and restrictions contained in BCP 78, and 245 except as set forth therein, the authors retain all their rights. 247 Acknowledgment 249 Funding for the RFC Editor function is currently provided by the 250 Internet Society.