[要約] RFC 4770は、インスタントメッセージング（IM）のためのvCard拡張機能に関する規格です。このRFCの目的は、IMでの連絡先情報の交換を容易にするために、vCard形式を拡張することです。
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)
インスタントメッセージング用のVカードエクステンション（IM）
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）The IETF Trust（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.
このドキュメントでは、インスタントメッセージング（IM）およびプレゼンスプロトコル（PP）アプリケーションをサポートするVCARDへの拡張機能について説明します。IMとPPは、コミュニケーションの一般的な方法になりつつあり、ユーザーはこの連絡先情報をアドレス帳に保存したいと考えています。IMまたはPPに関連付けられているURIがVCard内で指定されます。
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
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と呼ばれるこの情報の標準形式を定義します。このドキュメントでは、インスタントIMおよびPP URIを表すためのVCardの新しいタイプを定義します。これは、電子メールアドレスと電話の連絡先情報を表すための既存のタイプに非常に似ています。
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エントリには、IM、PP、またはその両方を提供するサービスのアドレスを示す単一のURI（RFC 3986 [3]を参照）があります。また、特定のURIが適切である時期に関するヒントを与えるいくつかのパラメーターも定義されています。特定のVCARDには複数のIMPPエントリを持つことができますが、各エントリには1つのURIのみを含めることができます。各IMPPエントリには、複数のパラメーターを含めることができます。パラメーターの任意の組み合わせは有効ですが、パラメーターはせいぜい、特定のIMPPエントリに1回発生するはずです。
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.
The normative definition of this new vCard type is given in Section 2, and an informational ABNF is provided in Section 3.
この新しいVCARDタイプの規範的定義はセクション2に示されており、情報ABNFはセクション3に記載されています。
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メーリングリストに送信されました。「（<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登録」レジストリの「テキスト/ディレクトリマイムタイプ」サブレジストリを更新します。
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:
タイプスペシャルノート：タイプには、URIの意図された使用を指定するタイプパラメーター「タイプ」を含めることができます。型パラメーター値には、次の1つ以上が含まれます。
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 値は、これが優先アドレスであり、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
value = URI ; URI defined in Section 3 of [3]
value = uri;[3]のセクション3で定義されているURI
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
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.
ブライアン・カーペンター、ラース・エガート、テッド・ハーディ、ポール・ホフマン、サム・ロバーツ、ペッカ・ペッシのコメントに感謝します。
[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コンテンツタイプ」、RFC 2425、1998年9月。
[2] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[2] Dawson、F。and T. Howes、「Vcard Mimeディレクトリプロファイル」、RFC 2426、1998年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）：Generic Syntax」、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 4234、2005年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：SESSION INIATIATION Protocol"、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）のための国際化されたリソース識別子（IRIS）および均一なリソース識別子（URI）」、RFC 4622、2006年7月。
[7] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[7] ピーターソン、J。、「インスタントメッセージングの共通プロファイル（CPIM）」、RFC 3860、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 West Tasman Drive MS：SJC-21/2 San Jose、CA 95134 USA
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、NW 48155ドイツ
Phone: +49 251 2807760
EMail: julian.reschke@greenbytes.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。