[要約] RFC 4482は、プレゼンス情報データ形式のためのCIPID（連絡先情報）に関する情報を提供する。このRFCの目的は、プレゼンス情報の交換における連絡先情報の標準化と一貫性を確保することである。
Network Working Group H. Schulzrinne
Request for Comments: 4482 Columbia U.
Category: Standards Track July 2006
CIPID: Contact Information for the Presence Information Data Format
CIPID：存在情報データ形式の連絡先情報
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 Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for the Presence Information Data format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons.
存在情報データ形式（PIDF）は、プレゼンテーションのために存在情報を提示するための基本的なXML形式を定義します。プレゼンス情報データ形式（CIPID）の連絡先情報は、アドレス帳エントリやアイコンへの参照を含むプレゼンティとその連絡先に関する追加の連絡先情報を提供するPIDFに要素を追加する拡張機能です。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology and Conventions .....................................3
3. CIPID Elements ..................................................3
3.1. Card Element ...............................................3
3.2. Display-Name Element .......................................3
3.3. Homepage Element ...........................................3
3.4. Icon Element ...............................................4
3.5. Map Element ................................................4
3.6. Sound Element ..............................................4
4. Example .........................................................4
5. The XML Schema Definition .......................................6
6. IANA Considerations .............................................7
6.1. URN Sub-Namespace Registration for .........................7
'urn:ietf:params:xml:ns:pidf:cipid'
6.2. Schema Registration for Schema
'urn:ietf:params:xml:ns:pidf:cipid' ........................7
7. Internationalization Considerations .............................8
8. Security Considerations .........................................8
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References ....................................10
Presence information facilitates communication; its usefulness can be enhanced by providing basic information about a presentity or contact. This specification describes a basic set of information elements that allow a watcher to retrieve additional information about a presentity or contact.
存在情報はコミュニケーションを容易にします。その有用性は、紹介または接触に関する基本的な情報を提供することで強化できます。この仕様では、ウォッチャーがプレゼンテーションまたは連絡先に関する追加情報を取得できるようにする情報要素の基本セットについて説明します。
This specification defines extensions to the PIDF [9] Extensible Markup Language [7][8][10] (XML) document format.
この仕様では、拡張機能をPIDF [9]拡張マークアップ言語[7] [8] [10]（XML）ドキュメント形式に定義します。
We describe elements for providing a "business card", references to the homepage, map, representative sound, display name, and an icon. This additional presence information can be used in PIDF [9] documents, together with Rich Presence Information Data format [11] (RPID), future-status [12], and other PIDF extensions.
「名刺」、ホームページ、マップ、代表的なサウンド、ディスプレイ名、およびアイコンへの参照を提供するための要素について説明します。この追加の存在情報は、PIDF [9]ドキュメントで使用でき、リッチプレゼンス情報データ形式[11]（RPID）、将来の状態[12]、およびその他のPIDF拡張機能とともに使用できます。
All elements extend the <person> or, less commonly, <tuple> element in the presence data model [13]. The <tuple> element is only extended with Contact Information for the Presence Information Data format (CIPID) elements if the information describes a service referring to another person that is marked by an RPID <relationship> element with a value other than 'self'. All elements described in this document are optional.
すべての要素は、<persone>またはそれほど一般的ではない、<13]の<sulter> <tuple>要素を拡張します[13]。<tuple>要素は、「self」以外の値を持つrpid <lationssion>要素でマークされている他の人に言及するサービスを説明している場合、存在情報データ形式（CIPID）要素の連絡先情報でのみ拡張されます。このドキュメントで説明されているすべての要素はオプションです。
RPID and CIPID both provide "rich" presence that goes beyond the basic 'open' and 'closed' status information in PIDF. The presence information described in these two documents can be supplied independently, although in practice, both will often appear in the same PIDF document. CIPID elements describe the more static aspects of somebody's presence information, while RPID focuses on elements that will likely change throughout the day. Thus, CIPID information can often be statically configured by the user through the graphical user interface of a presence client; this is less likely to be sufficient for RPID.
RPIDとCIPIDはどちらも、PIDFの基本的な「オープン」および「クローズド」ステータス情報を超えた「リッチ」な存在感を提供します。これらの2つのドキュメントで説明されている存在情報は独立して提供できますが、実際には、両方とも同じPIDFドキュメントに表示されることがよくあります。Cipid要素は、誰かの存在情報のより静的な側面を説明し、RPIDは1日を通して変化する可能性が高い要素に焦点を当てています。したがって、CIPID情報は、多くの場合、存在クライアントのグラフィカルユーザーインターフェイスを介してユーザーが静的に構成できます。これは、RPIDで十分である可能性が低くなります。
The namespace URI for these elements defined by this specification is a URN [2], using the namespace identifier 'ietf' defined by [4] and extended by [6]:
この仕様で定義されたこれらの要素の名前空間URIは、[4]で定義され、[6]で拡張された名前空間識別子「IETF」を使用して、uRN [2]です。
urn:ietf:params:xml:ns:pidf:cipid
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
キーワードは、このドキュメントでは、BCP 14、RFC 2119 [1]に記載されているように解釈されるように解釈する必要があります。
Unless otherwise noted below, each element may only appear at most once.
以下に特に述べない限り、各要素はせいぜい1回しか表示されません。
The <card> element includes a URI pointing to a business card, e.g., in LDAP Data Interchange Format [15] (LDIF) or vCard [14] format.
<card>要素には、LDAPデータインターチェンジ形式[15]（LDIF）またはVCard [14]形式など、名刺を指すURIが含まれています。
The <display-name> element includes the name identifying the tuple or person that the presentity suggests should be shown by the watcher user interface. It is left to the watcher user interface design to choose whether to heed this suggestion or to use some other suitable string. The CIPID information MAY contain multiple display names, but only if they are labeled with different 'xml:lang' attributes. This allows a Korean-speaking presentity to convey its display name in different languages, Latin and Hangul, for example.
<display-name>要素には、Tupleまたは人の識別名が含まれています。この提案に注意するか、他の適切な文字列を使用するかを選択するために、Watcherユーザーインターフェイス設計に任されています。CIPID情報には、複数のディスプレイ名が含まれている場合がありますが、異なる「XML：Lang」属性でラベル付けされている場合のみです。これにより、たとえば、韓国語を話すことで、さまざまな言語、ラテン語、ハングルでディスプレイ名を伝えることができます。
The <homepage> element provides a URI pointing to general information about the tuple or person, typically a web home page.
<homepage>要素は、タプルまたは人、通常はWebホームページに関する一般的な情報を指すURIを提供します。
The <icon> element provides a URI pointing to an image (icon) representing the tuple or person. The watcher can use this information to represent the tuple or person in a graphical user interface. Presentities SHOULD provide images of sizes and aspect ratios that are appropriate for rendering as an icon. Support for JPEG, PNG, and GIF formats is REQUIRED.
<アイコン>要素は、タプルまたは人を表す画像（アイコン）を指すURIを提供します。ウォッチャーは、この情報を使用して、グラフィカルユーザーインターフェイス内のタプルまたは人を表すことができます。プレゼンテーションは、アイコンとしてレンダリングするのに適したサイズとアスペクト比の画像を提供する必要があります。JPEG、PNG、およびGIF形式のサポートが必要です。
The <map> element provides a URI pointing to a map related to the tuple or person. The watcher can use this information to represent the tuple or person in a graphical user interface. The map may be either an image, an HTML client-side image map, or a geographical information system (GIS) document, e.g., encoded as GML. Support for images formatted as PNG and GIF is REQUIRED.
<Map>要素は、タプルまたは人に関連するマップを指すURIを提供します。ウォッチャーは、この情報を使用して、グラフィカルユーザーインターフェイス内のタプルまたは人を表すことができます。マップは、画像、HTMLクライアント側の画像マップ、またはGMLとしてエンコードされた地理情報システム（GIS）ドキュメントのいずれかです。PNGとGIFとしてフォーマットされた画像のサポートが必要です。
The <sound> element provides a URI pointing to a sound related to the tuple or person. The watcher MAY use the sound object, such as a MIDI or MP3 file, referenced by the URL to inform the watcher that the presentity has assumed the status OPEN. Implementors are advised to create user interfaces that provide the watcher with the opportunity to choose whether to play such sounds. Support for sounds coded as MPEG-2 Layer 3 (MP3) is RECOMMENDED. The sound object might also be used to indicate how to pronounce the presentity's name.
<sound>要素は、タプルまたは人に関連するサウンドを指すURIを提供します。ウォッチャーは、MIDIまたはMP3ファイルなど、URLが参照するSoundオブジェクトを使用して、Watherがステータスを開いていることを想定していることを監視者に通知する場合があります。実装者は、ウォッチャーにそのようなサウンドを再生するかどうかを選択する機会を提供するユーザーインターフェイスを作成することをお勧めします。MPEG-2レイヤー3（MP3）としてコード化されたサウンドのサポートをお勧めします。Soundオブジェクトは、プレゼンテーションの名前を発音する方法を示すためにも使用される場合があります。
An example using CIPID only is shown below:
CIPIDのみを使用する例を以下に示します。
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:c="urn:ietf:params:xml:ns:pidf:cipid"
entity="pres:someone@example.com">
<tuple id="bs35r9">
<status>
<basic>open</basic>
</status>
<contact priority="0.8">im:alice@example.net</contact>
<timestamp>2005-11-21T16:14:29Z</timestamp>
</tuple>
<dm:person id="p1">
<c:card>http://example.com/~alice/card.vcd</c:card>
<c:display-name>Alice Lewis</c:card>
<c:homepage>http://example.com/~alice</c:homepage>
<c:icon>http://example.com/~alice/me.png</c:icon>
<c:map>http://example.com/~alice/gml-map.xml</c:map>
<c:sound>http://example.com/~alice/hello.wav</c:sound>
<dm:timestamp>2005-11-21T09:00:00+05:00</dm:timestamp>
</dm:person>
</presence>
An example combining RPID and CIPID is shown below:
RPIDとCIPIDを組み合わせた例を以下に示します。
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:c="urn:ietf:params:xml:ns:pidf:cipid"
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
xsi:schemaLocation="urn:ietf:params:xml:ns:pidf pidf.xsd
urn:ietf:params:xml:ns:pidf:data-model data-model.xsd
urn:ietf:params:xml:ns:pidf:cipid cipid.xsd
urn:ietf:params:xml:ns:pidf:rpid rpid.xsd"
entity="pres:someone@example.com">
<tuple id="bs35r9">
<status>
<basic>open</basic>
</status>
<contact priority="0.8">im:someone@mobile.example.net</contact>
<timestamp>2005-05-30T22:00:29Z</timestamp>
</tuple>
<tuple id="bs78">
<status>
<basic>closed</basic>
</status>
<r:relationship><r:assistant/></r:relationship>
<c:card>http://example.com/~assistant/card.vcd</c:card>
<c:homepage>http://example.com/~assistant</c:homepage>
<contact priority="0.1">im:assistant@example.com</contact>
<timestamp>2005-05-30T22:00:29Z</timestamp>
</tuple>
<dm:person id="p1">
<c:card>http://example.com/~someone/card.vcd</c:card>
<c:homepage>http://example.com/~someone</c:homepage>
<c:icon>http://example.com/~someone/icon.gif</c:icon>
<c:map>http://example.com/~someone/gml-map.xml</c:map>
<c:sound>http://example.com/~someone/whoosh.wav</c:sound>
<dm:timestamp>2005-05-30T22:02:44+05:00</dm:timestamp>
</dm:person>
</presence>
The schema is shown below.
スキーマを以下に示します。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:cipid"
xmlns:cipid="urn:ietf:params:xml:ns:pidf:cipid"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation>
Describes CIPID tuple extensions for PIDF.
</xs:documentation>
</xs:annotation>
<xs:element name="card" type="xs:anyURI"/>
<xs:element name="display-name" type="xs:string"/>
<xs:element name="homepage" type="xs:anyURI"/>
<xs:element name="icon" type="xs:anyURI"/>
<xs:element name="map" type="xs:anyURI"/>
<xs:element name="sound" type="xs:anyURI"/>
</xs:schema>
Figure 1: CIPID schema
図1：CIPIDスキーマ
This document calls for IANA to register a new XML namespace URN and schema per [6].
このドキュメントでは、IANAが新しいXMLネームスペースのurnとスキーマを登録することを求めています[6]。
6.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:cipid'
URI: urn:ietf:params:xml:ns:pidf:cipid Description: This is the XML namespace for XML elements defined by RFC 4482 to describe contact information presence information extensions for the status element in the PIDF presence document format in the application/pidf+xml content type. Registrant Contact: IETF, SIMPLE working group, simple@ietf.org; Henning Schulzrinne, hgs@cs.columbia.edu XML:
uri：urn：ietf：params：xml：ns：pidf：cipid説明：これは、アプリケーション/アプリケーション/のPIDF存在要素のステータス要素のステータス要素の存在情報拡張のためにRFC 4482で定義されたXML要素のXML名空間です/PIDF XMLコンテンツタイプ。登録者の連絡先：IETF、Simple Working Group、simple@ietf.org;Henning Schulzrinne、hgs@cs.columbia.edu xml：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>CIPID: Contact Information for the Presence Information
Data Format</title>
</head>
<body>
<h1>Namespace for contact information presence extension
(status)</h1>
<h2>urn:ietf:params:xml:ns:pidf:cipid</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4482.txt">
RFC4482</a>.</p>
</body>
</html>
END
URI: urn:ietf:params:xml:ns:pidf:cipid
Registrant Contact: IESG
XML: See Figure 1
CIPID delivers only URLs, except for the <display-name> element. The resolution of the URLs can negotiate appropriate language and character sets within the URL-designated protocol.
cipidは、<display-name>要素を除き、URLのみを配信します。URLの解像度は、URL指定プロトコル内で適切な言語と文字セットをネゴシエートできます。
For the display name and to handle Internationalized Resource Identifiers (IRIs) [16], since CIPID is represented in XML, it provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists.
ディスプレイ名と、Internationalizedリソース識別子（IRIS）[16]を処理するために、CIPIDはXMLで表されるため、Unicode文字セットとUTF-8を含むよりコンパクトな表現を使用して、エンコード情報をエンコードするネイティブサポートを提供します。コンフォーマントXMLプロセッサは、UTF-8とUTF-16の両方を認識します。XMLには、<？xml？>宣言で「エンコード」属性を使用して他の文字エンコーディングを特定して使用するための規定が含まれていますが、UTF-8の使用は、サポートの互換性が存在するパーサーエンコードが存在する環境で推奨されます。
The XML 'xml:lang' attribute can be used to identify the language and script for the <display-name> element. The specification allows multiple occurrences of this element so that the presentity can convey display names in multiple scripts and languages. If no 'xml: lang' attribute is provided, the default value is "i-default" [3].
XML 'XML：Lang'属性を使用して、<display-name>要素の言語とスクリプトを識別できます。この仕様により、この要素の複数の発生が可能になり、プレゼンテーションが複数のスクリプトと言語で表示名を伝えることができます。'xml：lang'属性が提供されていない場合、デフォルト値は「i-default」です[3]。
The security issues are similar to those for RPID [11]. Watchers need to restrict which content types of content pointed to by <icon>, <homepage>, <map>, <sound>, and <vcard> elements they render.
セキュリティの問題は、RPID [11]の問題に似ています。ウォッチャーは、<Icon>、<Icon>、<homepage>、<map>、<sound>、<vcard>要素によって指摘されたコンテンツのコンテンツを制限する必要があります。
Also, when a watcher accesses these URIs, the presentity may deduce that the watcher is currently using the presence application. Thus, a presence application concerned about leaking this information may want to cache these objects for later use. (A presentity could easily customize the URLs for each watcher, so that it can tell who is referencing the objects.) This caching behavior may cause the information to become stale, out-of-sync with the current data until the cache is refreshed. Fortunately, the elements in CIPID are expected to retain the same content for periods measured in days, so that privacy-conscious applications may well decide to perform caching over durations that reveal little current activity information. Presentities need to keep in mind that clients may cache the content referenced by URIs for long periods as they use their presence system to construct presence documents using this extension. If the referenced content needs to change frequently, the presentity could, for example, update the presence document with a new URI to encourage clients to notice.
また、ウォッチャーがこれらのURIにアクセスすると、監視者が現在プレゼンスアプリケーションを使用しているとプレゼンティが推測する可能性があります。したがって、この情報を漏らすことを懸念する存在アプリケーションは、後で使用するためにこれらのオブジェクトをキャッシュすることをお勧めします。（プレゼンテーションは、各ウォッチャーのURLを簡単にカスタマイズできるため、オブジェクトを参照している人がわかります。）このキャッシング動作により、キャッシュが更新されるまで、現在のデータとともに情報が古くなってしまう可能性があります。幸いなことに、CIPIDの要素は、数日で測定された期間に同じコンテンツを保持することが期待されているため、プライバシーを意識したアプリケーションは、現在のアクティビティ情報をほとんど明らかにしない期間上でキャッシュを実行することを決定する可能性があります。プレゼンテーションは、クライアントがこの拡張機能を使用して存在するドキュメントを構築するために存在システムを使用しているため、URISが参照するコンテンツを長期間キャッシュすることができることに留意する必要があります。参照されたコンテンツが頻繁に変更する必要がある場合、たとえば、プレゼンテーションでは、クライアントが気付かないようにするために、新しいURIでプレゼンスドキュメントを更新することができます。
Icons and other URIs in this document could be used as a covert channel to convey messages to the watcher, outside the content monitoring that might be in place for instant messages or other communications channels. Thus, entities that worry about such channels may want to prohibit the usage of URLs pointing to resources outside their domain, for example.
このドキュメントのアイコンやその他のURIは、即座のメッセージやその他の通信チャネルのために設置されている可能性のあるコンテンツ監視の外で、ウォッチャーにメッセージを伝えるためのカバーチャネルとして使用できます。したがって、そのようなチャネルを心配するエンティティは、たとえば、ドメインの外側のリソースを指すURLの使用を禁止したい場合があります。
Implementors must take care to adhere to the mechanisms for verifying the identity in the referenced server's certificate against the URI. For instance, if the URI scheme is https, the requirements of RFC 2818 [5], section 3.1, must be met. In particular, the domain represented in the URI must match the subjectAltName in the certificate presented by the referenced server. If this identity check fails, the referenced content SHOULD NOT be retrieved and MUST NOT be used.
実装者は、URIに対する参照サーバーの証明書のIDを確認するためのメカニズムを遵守するように注意する必要があります。たとえば、URIスキームがHTTPSの場合、RFC 2818 [5]の要件、セクション3.1を満たす必要があります。特に、URIに表されるドメインは、参照されるサーバーが提示した証明書のsumbesaltnameと一致する必要があります。このIDチェックが失敗した場合、参照されるコンテンツを取得してはならず、使用してはなりません。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[3] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[4] Moats、R。、「IETFドキュメント用のurnネームスペース」、RFC 2648、1999年8月。
[5] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[5] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[6] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[7] Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C REC REC-xmlschema-1-20041028, October 2004.
[7] Maloney、M.、Beech、D.、Thompson、H。、およびN. Mendelsohn、「XML Schema Part 1：Structures Second Edition」、W3C Rec Rec-XMLSchema-1-20041028、2004年10月。
[8] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", W3C REC REC-xmlschema-2-20041028, October 2004.
[8] Malhotra、A。およびP. Biron、「XML Schema Part 2：DataTypes Second Edition」、W3C Rec Rec-XMLSchema-20041028、2004年10月。
[9] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[9] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年8月。
[10] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC REC-xml-20040204, February 2004.
[10] Yergeau、F.、Paoli、J.、Sperberg-Mcqueen、C.、Bray、T.、およびE. Maler、「拡張マークアップ言語（XML）1.0（第3版）」、W3C Rec Rec-XML-20040204、2月2004年。
[11] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[11] Schulzrinne、H.、Gurbani、V.、Kyzivat、P。、およびJ. Rosenberg、「rpid：Rich Expentionが存在情報データ形式（PIDF）（PIDF）への拡張」、RFC 4480、2006年7月。
[12] Schulzrinne, H., "Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals", RFC 4481, July 2006.
[12] Schulzrinne、H。、「過去および将来の時間間隔のステータス情報を示すための存在情報データ形式（PIDF）へのタイミングのプレゼンス拡張」、RFC 4481、2006年7月。
[13] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[13] Rosenberg、J。、「存在のためのデータモデル」、RFC 4479、2006年7月。
[14] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[14] Dawson、F。and T. Howes、「Vcard Mimeディレクトリプロファイル」、RFC 2426、1998年9月。
[15] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[15] Good、G。、「LDAPデータインターチェンジ形式（LDIF） - 技術仕様」、RFC 2849、2000年6月。
[16] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[16] Duerst、M。and M. Suignard、「Internationalized Resource Identiers（IRIS）」、RFC 3987、2005年1月。
Acknowledgements
謝辞
This document is based on discussions within the IETF SIMPLE working group. Spencer Dawkins, Vijay Gurbani, Avshalom Houri, Hisham Khartabil, Paul Kyzivat, Eva Leppanen, Mikko Lonnfors, Aki Niemi, Jon Peterson, Jonathan Rosenberg, and Robert Sparks provided helpful comments.
このドキュメントは、IETF Simpleワーキンググループ内の議論に基づいています。スペンサー・ドーキンス、ヴィジェイ・グルバニ、アヴシャロム・ホイ、ヒシャム・ハルタビル、ポール・キジバット、エヴァ・レパネン、ミッコ・ロンフォース、アキ・ニエミ、ジョン・ピーターソン、ジョナサン・ローゼンバーグ、ロバートスパークスは有益なコメントを提供しました。
Author's Address
著者の連絡先
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク、ニューヨーク10027米国
Phone: +1 212 939 7004
EMail: hgs+simple@cs.columbia.edu
URI: http://www.cs.columbia.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。