Network Working Group C. Jennings
Request for Comments: 4770 Cisco Systems
Category: Standards Track J. Reschke, Ed.
greenbytes
January 2007
Network Working Group C. Jennings
Request for Comments: 4770 Cisco Systems
Category: Standards Track J. Reschke, Ed.
greenbytes
January 2007
vCard Extensions for Instant Messaging (IM)
用于即时消息（IM）的vCard扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes an extension to vCard to support Instant Messaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. It allows a URI that is associated with IM or PP to be specified inside a vCard.
本文档介绍vCard的扩展，以支持即时消息（IM）和状态协议（PP）应用程序。IM和PP正在成为越来越常见的通信方式，用户希望将这些联系信息保存在他们的通讯簿中。它允许在vCard中指定与IM或PP关联的URI。
Table of Contents
目录
1. Overview ........................................................2
2. IANA Considerations .............................................3
3. Formal Grammar ..................................................4
4. Example .........................................................4
5. Security Considerations .........................................4
6. Acknowledgments .................................................4
7. References ......................................................5
7.1. Normative References .......................................5
7.2. Informational References ...................................5
1. Overview ........................................................2
2. IANA Considerations .............................................3
3. Formal Grammar ..................................................4
4. Example .........................................................4
5. Security Considerations .........................................4
6. Acknowledgments .................................................4
7. References ......................................................5
7.1. Normative References .......................................5
7.2. Informational References ...................................5
As more and more people use various instant messaging (IM) and presence protocol (PP) applications, it becomes important for them to be able to share this contact address information, along with the rest of their contact information. RFC 2425 [1] and RFC 2426 [2] define a standard format for this information, which is referred to as vCard. This document defines a new type in a vCard for representing instant IM and PP URIs. It is very similar to existing types for representing email address and telephone contact information.
随着越来越多的人使用各种即时消息（IM）和状态协议（PP）应用程序，能够共享此联系人地址信息以及其他联系人信息变得非常重要。RFC 2425[1]和RFC 2426[2]定义了此信息的标准格式，称为vCard。本文档在vCard中定义了一个新类型，用于表示即时IM和PP URI。它与现有的表示电子邮件地址和电话联系信息的类型非常相似。
The type entry to hold this new contact information is an IMPP type. The IMPP entry has a single URI (see RFC 3986 [3]) that indicates the address of a service that provides IM, PP, or both. Also defined are some parameters that give hints as to when certain URIs would be appropriate. A given vCard can have multiple IMPP entries, but each entry can contain only one URI. Each IMPP entry can contain multiple parameters. Any combination of parameters is valid, although a parameter should occur, at most, once in a given IMPP entry.
保存此新联系人信息的类型条目是IMPP类型。IMPP条目有一个URI（请参阅RFC 3986[3]），它指示提供IM、PP或两者的服务的地址。还定义了一些参数，这些参数提示某些URI何时合适。给定的vCard可以有多个IMPP条目，但每个条目只能包含一个URI。每个IMPP条目可以包含多个参数。参数的任何组合都是有效的，尽管参数在给定的IMPP条目中最多出现一次。
The type of URI indicates what protocols might be usable for accessing it, but this document does not define any of the types. For example, a URI type of
URI的类型指示哪些协议可用于访问它，但本文档未定义任何类型。例如，URI类型为
o "sip" [5] indicates to use SIP/SIMPLE,
o "xmpp" [6] indicates to use XMPP,
o "irc" indicates to use IRC,
o "ymsgr" indicates to use yahoo,
o "msn" might indicate to use Microsoft messenger,
o "aim" indicates to use AOL, and
o "im" [7] or "pres" [8] indicates that a CPIM or CPP gateway should
be used.
o "sip" [5] indicates to use SIP/SIMPLE,
o "xmpp" [6] indicates to use XMPP,
o "irc" indicates to use IRC,
o "ymsgr" indicates to use yahoo,
o "msn" might indicate to use Microsoft messenger,
o "aim" indicates to use AOL, and
o "im" [7] or "pres" [8] indicates that a CPIM or CPP gateway should
be used.
The normative definition of this new vCard type is given in Section 2, and an informational ABNF is provided in Section 3.
第2节给出了这种新vCard类型的规范性定义，第3节提供了信息性ABNF。
The required email to define this extension (as defined in RFC 2425 [1]) was sent on October 29, 2004, to the ietf-mime-direct@imc.org mailing list with the subject "Registration of text/directory MIME type IMPP" (see <http://www.imc.org/ietf-mime-direct/mail-archive/msg00068.html>).
定义此扩展所需的电子邮件（如RFC 2425[1]中所定义）已于2004年10月29日发送至ietf mime-direct@imc.org主题为“文本/目录MIME类型IMPP注册”的邮件列表（请参阅<http://www.imc.org/ietf-mime-direct/mail-archive/msg00068.html>).
This specification updates the "text/directory MIME Types" subregistry in the "text/directory MIME Registrations" registry at http://www.iana.org/assignments/text-directory-registrations with the following information:
本规范更新“文本/目录MIME注册”注册表中的“文本/目录MIME类型”子区，地址为http://www.iana.org/assignments/text-directory-registrations 提供以下信息：
Type name: IMPP
类型名称：IMPP
Type purpose: To specify the URI for instant messaging and presence protocol communications with the object the vCard represents.
类型用途：指定与vCard表示的对象进行即时消息和状态协议通信的URI。
Type encoding: 8bit
类型编码：8位
Type value: A single URI. The type of the URI indicates the protocol that can be used for this contact.
类型值：单个URI。URI的类型指示可用于此联系人的协议。
Type special notes: The type may include the type parameter "TYPE" to specify an intended use for the URI. The TYPE parameter values include one or more of the following:
类型特别说明：类型可能包括类型参数“Type”，以指定URI的预期用途。类型参数值包括以下一个或多个值：
o An indication of the type of communication for which this URI is appropriate. This can be a value of PERSONAL or BUSINESS.
o 此URI适用的通信类型的指示。这可能是个人或业务的价值。
o An indication of the location of a device associated with this URI. Values can be HOME, WORK, or MOBILE.
o 与此URI关联的设备位置的指示。值可以是家庭、工作或移动。
o The value PREF indicates this is a preferred address and has the same semantics as the PREF value in a TEL type.
o 值PREF表示这是首选地址，并且与TEL类型中的PREF值具有相同的语义。
Additional information can be found in RFC 4770.
更多信息可在RFC 4770中找到。
Intended usage: COMMON
预期用途：普通
The following ABNF grammar [4] extends the grammar found in RFC 2425 [1] (Section 5.8.2) and RFC 2426 [2] (Section 4).
以下ABNF语法[4]扩展了RFC 2425[1]（第5.8.2节）和RFC 2426[2]（第4节）中的语法。
;For name="IMPP"
param = impp-param ; Only impp parameters are allowed
;For name="IMPP"
param = impp-param ; Only impp parameters are allowed
value = URI ; URI defined in Section 3 of [3]
value=URI；[3]第3节中定义的URI
impp-param = "TYPE" "=" impp-type *("," impp-type)
impp-param = "TYPE" "=" impp-type *("," impp-type)
impp-type = "PERSONAL" / "BUSINESS" / ; purpose of communications
"HOME" / "WORK" / "MOBILE" /
"PREF" /
iana-token / x-name;
; Values are case insensitive
impp-type = "PERSONAL" / "BUSINESS" / ; purpose of communications
"HOME" / "WORK" / "MOBILE" /
"PREF" /
iana-token / x-name;
; Values are case insensitive
BEGIN:vCard
VERSION:3.0
FN:Alice Doe
IMPP;TYPE=personal,pref:im:alice@example.com
END:vCard
BEGIN:vCard
VERSION:3.0
FN:Alice Doe
IMPP;TYPE=personal,pref:im:alice@example.com
END:vCard
This does not introduce additional security issues beyond the current vCard specification. It is worth noting that many people consider their presence information more sensitive than other address information. Any system that stores or transfers vCards needs to carefully consider the privacy issues around this information.
这不会带来当前vCard规范之外的其他安全问题。值得注意的是，许多人认为他们的存在信息比其他地址信息更敏感。任何存储或传输VCARD的系统都需要仔细考虑此信息周围的隐私问题。
Thanks to Brian Carpenter, Lars Eggert, Ted Hardie, Paul Hoffman, Sam Roberts, and Pekka Pessi for their comments.
感谢Brian Carpenter、Lars Eggert、Ted Hardie、Paul Hoffman、Sam Roberts和Pekka Pessi的评论。
[1] Howes, T., Smith, M., and F. Dawson, "A MIME Content-Type for Directory Information", RFC 2425, September 1998.
[1] Howes，T.，Smith，M.，和F.Dawson，“目录信息的MIME内容类型”，RFC2425，1998年9月。
[2] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[2] Dawson，F.和T.Howes，“vCard MIME目录配置文件”，RFC24261998年9月。
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[3] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[4] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[5] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[6] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 4622, July 2006.
[6] Saint Andre，P.，“可扩展消息和状态协议（XMPP）的国际化资源标识符（IRI）和统一资源标识符（URI）”，RFC 4622，2006年7月。
[7] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[7] 彼得森，J.，“即时通讯（CPIM）的通用配置文件”，RFC3860，2004年8月。
[8] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[8] 彼得森，J.，“在场的共同概况（CPP）”，RFC 3859，2004年8月。
Authors' Addresses
作者地址
Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 USA
Cullen Jennings Cisco Systems 170西塔斯曼大道MS:SJC-21/2美国加利福尼亚州圣何塞95134
Phone: +1 408 902-3341
EMail: fluffy@cisco.com
Phone: +1 408 902-3341
EMail: fluffy@cisco.com
Julian F. Reschke (editor) greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F.Reschke（编辑）greenbytes GmbH Hafenweg 16 Muenster，西北48155德国
Phone: +49 251 2807760
EMail: julian.reschke@greenbytes.de
Phone: +49 251 2807760
EMail: julian.reschke@greenbytes.de
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。