[要約] RFC 4827は、XML Configuration Access Protocol (XCAP)を使用してプレゼンスドキュメントの内容を操作するための方法を提供しています。このRFCの目的は、プレゼンス情報の管理と共有を容易にすることです。
Network Working Group M. Isomaki
Request for Comments: 4827 E. Leppanen
Category: Standards Track Nokia
May 2007
An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents
拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）の使用を操作するためのドキュメントコンテンツを操作する
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 a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents. It is intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity.
このドキュメントでは、存在情報データ形式（PIDF）ベースのプレゼンスドキュメントの内容を操作するための拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）の使用について説明します。これは、セッション開始プロトコル（SIP）ベースの存在システムで使用することを目的としています。イベント状態のコンポジタは、XCAPが管理する存在ドキュメントを使用して、プレゼンスの全体的な存在状態を構築する入力の1つとして使用できます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Relationship with Presence State Published Using SIP
PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Application Usage ID . . . . . . . . . . . . . . . . . . . . . 6
5. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Structure of Manipulated Presence Information . . . . . . . . . 6
7. Additional Constraints . . . . . . . . . . . . . . . . . . . . 6
8. Resource Interdependencies . . . . . . . . . . . . . . . . . . 6
9. Naming Conventions . . . . . . . . . . . . . . . . . . . . . . 6
10. Authorization Policies . . . . . . . . . . . . . . . . . . . . 6
11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
12. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
13.1. XCAP Application Usage ID . . . . . . . . . . . . . . . . 9
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
15.1. Normative References . . . . . . . . . . . . . . . . . . . 9
15.2. Informative References . . . . . . . . . . . . . . . . . . 9
The Session Initiation Protocol (SIP) for Instant Messaging and Presence (SIMPLE) specifications allow a user, called a watcher, to subscribe to another user, called a presentity, in order to learn its presence information [7]. The presence data model has been specified in [10]. The data model makes a clean separation between person-, service-, and device-related information.
インスタントメッセージングと存在感（シンプル）仕様のセッション開始プロトコル（SIP）により、ウォッチャーと呼ばれるユーザーが、プレゼンテーションと呼ばれる別のユーザーに登録して、その存在情報を学習することができます[7]。存在データモデルは[10]で指定されています。データモデルは、人、サービス、およびデバイス関連の情報をきれいに分離します。
A SIP-based mechanism, SIP PUBLISH method, has been defined for publishing presence state [4]. Using SIP PUBLISH, a Presence User Agent (PUA) can publish its view of the presence state, independently of and without the need to learn about the states set by other PUAs. However, SIP PUBLISH has a limited scope and does not address all the requirements for setting presence state. The main issue is that SIP PUBLISH creates a soft state that expires after the negotiated lifetime unless it is refreshed. This makes it unsuitable for cases where the state should prevail without active devices capable of refreshing the state.
SIPベースのメカニズムであるSIPパブリッシュメソッドは、プレゼンス状態を公開するために定義されています[4]。SIPパブリッシュを使用して、プレゼンスユーザーエージェント（PUA）は、他のPUAによって設定された状態について学ぶ必要がなく、存在状態の見解を公開できます。ただし、SIPパブリッシュの範囲は限られており、存在状態を設定するためのすべての要件に対処するわけではありません。主な問題は、SIPパブリッシュが、更新されない限り、交渉された生涯の後に期限切れになるソフト状態を作成することです。これにより、州をリフレッシュできるアクティブなデバイスなしで州が勝つ必要がある場合には適していません。
There are three main use cases where setting of permanent presence state that is independent of activeness of any particular device is useful. The first case concerns setting person-related state. The presentity would often like to set its presence state even for periods when it has no active devices capable of publishing available. Good examples are traveling, vacations, and so on. The second case is about setting state for services that are open for communication, even if the presentity does not have a device running that service online. Examples of these kinds of services include e-mail, Multimedia Messaging Service (MMS), and Short Message Service (SMS). In these services, the presentity is provisioned with a server that makes the service persistently available, at least in certain forms, and it would be good to be able to advertise this to the watchers. Since it is not realistic to assume that all e-mail, MMS, or SMS servers can publish presence state on their own (and even if this were possible, such state would almost never change), this has to be done by some other device. And since the availability of the service is not dependent on that device, it would be impractical to require that device to be constantly active just to publish such availability. The third case concerns setting the default state of any person, service, or device in the absence of any device capable of actively publishing such state. For instance, the presentity might want to advertise that his or her voice service is currently closed, just to let the watchers know that such service might be open at some point. Again, this type of default state is independent of any particular device and can be considered rather persistent.
特定のデバイスの活性化とは無関係に、永続的な存在状態の設定が役立つ3つの主要なユースケースがあります。最初のケースは、人関連の状態の設定に関するものです。プレゼンテーションは、公開可能なアクティブなデバイスがない期間であっても、その存在状態を設定したいことがよくあります。良い例は、旅行、休暇などです。2番目のケースは、オンラインでそのサービスを実行しているデバイスがプレゼンティにない場合でも、通信用に開かれたサービスの状態を設定することです。これらの種類のサービスの例には、電子メール、マルチメディアメッセージングサービス（MMS）、およびショートメッセージサービス（SMS）が含まれます。これらのサービスでは、少なくとも特定の形式でサービスを永続的に利用できるようにするサーバーでプレゼンテーションがプロビジョニングされており、これをウォッチャーに宣伝できることは良いことです。すべての電子メール、MMS、またはSMSサーバーが自分でプレゼンス状態を公開できると仮定することは現実的ではないため（そして、これが可能であっても、そのような状態はほとんど変わらないでしょう）、これは他のデバイスで行う必要があります。また、サービスの可用性はそのデバイスに依存していないため、このような可用性を公開するためだけにそのデバイスが常にアクティブであることを要求することは非現実的です。3番目のケースは、そのような状態を積極的に公開できるデバイスがない場合、すべての人、サービス、またはデバイスのデフォルト状態を設定することに関するものです。たとえば、プレゼンテーションは、彼または彼女の音声サービスが現在閉鎖されていることを宣伝したいと思うかもしれません。繰り返しますが、このタイプのデフォルト状態は特定のデバイスから独立しており、かなり永続的であると見なすことができます。
Even though SIP PUBLISH remains the main way of publishing presence state in SIMPLE-based presence systems and is especially well-suited for publishing dynamic state (which presence mainly is), it needs to be complemented by the mechanism described in this document to address the use cases presented above.
SIPパブリッシュは、シンプルベースのプレゼンスシステムでプレゼンス状態を公開する主な方法であり、特に動的状態を公開するのに適しています（主に存在感があります）が、このドキュメントに記載されているメカニズムによって補完する必要があります。上記のユースケース。
XML Configuration Access Protocol (XCAP) [2] allows a client to read, write, and modify application configuration data stored in XML format on a server. The data has no expiration time, so it must be explicitly inserted and deleted. The protocol allows multiple clients to manipulate the data, provided that they are authorized to do so. XCAP is already used in SIMPLE-based presence systems for manipulation of presence lists and presence authorization policies. This makes XCAP an ideal choice for doing device-independent presence document manipulation.
XML構成アクセスプロトコル（XCAP）[2]により、クライアントはサーバー上にXML形式で保存されているアプリケーション構成データを読み取り、書き込み、変更できます。データには有効期限がないため、明示的に挿入して削除する必要があります。このプロトコルにより、複数のクライアントがデータを操作できるようになります。XCAPは、存在リストの操作と存在感の認証ポリシーの操作のために、単純な存在システムで既に使用されています。これにより、XCAPはデバイスに依存しない存在感のドキュメント操作を行うための理想的な選択肢になります。
This document defines an XML Configuration Access Protocol (XCAP) application usage for manipulating the contents of presence document. Presence Information Document Format (PIDF) [3] is used as the presence document format, since the event state compositor already has to support it, as it is used in SIP PUBLISH.
このドキュメントでは、プレゼンスドキュメントの内容を操作するためのXML構成アクセスプロトコル（XCAP）アプリケーションの使用法を定義します。Inction Information Document Format（PIDF）[3]は、SIPパブリッシュで使用されているため、イベント状態のコンポジタがすでにサポートする必要があるため、存在ドキュメント形式として使用されます。
Section 3 describes in detail how the presence document manipulated with XCAP is related to soft state publishing done with SIP PUBLISH.
セクション3では、XCAPで操作された存在ドキュメントがSIPパブリッシュで行われたソフトステートパブリッシングにどのように関連しているかを詳細に説明します。
XCAP requires application usages to standardize several pieces of information, including a unique application usage ID (AUID) and an XML schema for the manipulated data. These are specified starting from Section 4.
XCAPでは、一意のアプリケーション使用法ID（AUID）や操作データのXMLスキーマなど、いくつかの情報を標準化するためのアプリケーション使用法が必要です。これらは、セクション4から指定されています。
In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワード「必須」、「必須」、「必要」、「必要」、「しない」、「そうでない」、「必要」、「推奨」、「5月」、および「オプション」RFC 2119 [1]に記載されているように解釈され、準拠した実装の要件レベルを示します。
Comprehensive terminology of presence and event state publishing is provided in "Session Initiation Protocol (SIP) Extension for Event State Publication" [4].
プレゼンスとイベント状態出版の包括的な用語は、「イベント州の出版物のセッション開始プロトコル（SIP）拡張」で提供されています[4]。
The framework for publishing presence state is described in Figure 1. A central part of the framework is the event state compositor element, whose function is to compose presence information received from several sources into a single coherent presence document.
Presence状態を公開するためのフレームワークを図1に示します。フレームワークの中心部分は、いくつかのソースから受け取った存在情報を1つのコヒーレントプレゼンスドキュメントに作成することであるイベント状態コンポジタ要素です。
The presence state manipulated with XCAP can be seen as one of the information sources for the compositor to be combined with the soft state information published using SIP PUBLISH. This is illustrated in Figure 1. It is expected that, in the normal case, there can be several PUAs publishing their separate views with SIP PUBLISH, but only a single XCAP manipulated presence document. As shown in the figure, multiple XCAP clients (for instance, in different physical devices) can manipulate the same document on the XCAP server, but this still creates only one input to the event state compositor. The XCAP server stores the XCAP manipulated presence document under the "users" tree in the XCAP document hierarchy. See Section 9 for details and Section 11 for an example.
XCAPで操作された存在状態は、SIPパブリッシュを使用して公開されたソフトステート情報と組み合わせるための情報源の1つと見なすことができます。これは図1に示されています。通常の場合、SIPパブリッシュで個別のビューを公開するいくつかのPUAがあることが予想されますが、XCAP操作の存在ドキュメントは1つだけです。図に示すように、複数のXCAPクライアント（たとえば、異なる物理デバイスで）は、XCAPサーバーで同じドキュメントを操作できますが、これはイベント状態コンポジタへの1つの入力のみを作成します。XCAPサーバーは、XCAPドキュメント階層の「ユーザー」ツリーの下にXCAP操作の存在ドキュメントを保存します。詳細についてはセクション9、例についてはセクション11を参照してください。
As individual inputs, the presence states set by XCAP and SIP PUBLISH are completely separated, and it is not possible to directly manipulate the state set by one mechanism with the other. How the compositor treats XCAP-based inputs with respect to SIP PUBLISH-based inputs is a matter of compositor policy, which is beyond the scope of this specification. Since the SIP PUBLISH specification already mandates the compositor to be able to construct the overall presence state from multiple inputs, which may contain non-orthogonal (or in some ways even conflicting) information, this XCAP usage does not impose any new requirements on the compositor functionality.
個々の入力として、XCAPおよびSIPパブリッシュによって設定された存在状態は完全に分離されており、あるメカニズムによって設定された状態を他のメカニズムで直接操作することはできません。CompositorがSIPパブリッシュベースの入力に関してXCAPベースの入力をどのように扱うかは、この仕様の範囲を超えたコンポジタポリシーの問題です。SIPパブリッシュの仕様はすでに複数の入力から全体的な存在状態を構築できることを義務付けているため、非有数（または何らかの形で矛盾する）情報を含む可能性があります。機能。
+---------------+ +------------+
| Event State | | Presence |<-- SIP SUBSCRIBE
| Compositor +---------+ Agent |--> SIP NOTIFY
| | | (PA) |
+-------+-------+ +------------+
^ ^ ^
| | |
| | | +---------------+
+--------+ | +-------| XCAP server |
| | +-------+-------+
| | ^ ^
| SIP Publish | | XCAP |
| | | |
+--+--+ +--+--+ +-------+ +-------+
| PUA | | PUA | | XCAP | | XCAP |
| | | | | client| | client|
+-----+ +-----+ +-------+ +-------+
Figure 1: Framework for Presence Publishing and Event State Composition
図1：プレゼンスのフレームワーク公開とイベントの状態構成
The protocol interface between XCAP server and the event state compositor is not specified here.
XCAPサーバーとイベント状態コンポジタ間のプロトコルインターフェイスは、ここでは指定されていません。
XCAP requires application usages to define a unique application usage ID (AUID) in either the IETF tree or a vendor tree. This specification defines the 'pidf-manipulation' AUID within the IETF tree, via the IANA registration in Section 13.
XCAPでは、IETFツリーまたはベンダーツリーのいずれかで一意のアプリケーション使用ID（AUID）を定義するためのアプリケーション使用法が必要です。この仕様は、セクション13のIANA登録を介して、IETFツリー内の「PIDF操作」AUIDを定義します。
The MIME type for this application usage is 'application/pidf+xml'.
このアプリケーション使用のMIMEタイプは「アプリケーション/PIDF XML」です。
The XML Schema of the presence information is defined in the Presence Information Data Format (PIDF) [3]. The PIDF also defines a mechanism for extending presence information. See [8], [9], [11], and [12] for currently defined PIDF extensions and their XML Schemas.
存在情報のXMLスキーマは、存在情報データ形式（PIDF）[3]で定義されています。PIDFは、存在情報を拡張するためのメカニズムも定義します。現在定義されているPIDF拡張機能とそのXMLスキーマについては、[8]、[9]、[11]、および[12]を参照してください。
The namespace URI for PIDF is 'urn:ietf:params:xml:ns:pidf' which is also the XCAP default document namespace.
PIDFの名前空間URIは「urn：ietf：params：xml：ns：pidf」です。
There are no constraints on the document beyond those described in the XML schemas (PIDF and its extensions) and in the description of PIDF [3].
XMLスキーマ（PIDFおよびその拡張）に記載されているものを超えて、PIDF [3]の説明に記載されているものを超えたドキュメントに制約はありません。
There are no resource interdependencies beyond the possible interdependencies defined in PIDF [3] and XCAP [2] that need to be defined for this application usage.
PIDF [3]およびXCAP [2]で定義されている可能性のある相互依存性を超えたリソースの相互依存性はありません。
The XCAP server MUST store only a single XCAP manipulated presence document for each user. The presence document MUST be located under the "users" tree, using filename "index". See an example in Section 11.
XCAPサーバーは、ユーザーごとに1つのXCAP操作存在ドキュメントのみを保存する必要があります。存在ドキュメントは、ファイル名「インデックス」を使用して「ユーザー」ツリーの下に配置する必要があります。セクション11の例を参照してください。
This application usage does not modify the default XCAP authorization policy, which allows only a user (owner) to read, write, or modify their own documents. A server can allow privileged users to modify documents that they do not own, but the establishment and indication of such policies is outside the scope of this document.
このアプリケーションの使用は、デフォルトのXCAP認証ポリシーを変更することはありません。これにより、ユーザー（所有者）のみが独自のドキュメントを読み取り、書き込み、または変更できます。サーバーは、特権ユーザーが所有していないドキュメントを変更できるようにすることができますが、そのようなポリシーの確立と兆候はこのドキュメントの範囲外です。
The section provides an example of a presence document provided by an XCAP Client to an XCAP Server. The presence document illustrates the situation where a (human) presentity has left for vacation, and before that, has set his presence information so that he is only available via e-mail. In the absence of any published soft state information, this would be the sole input to the compositor forming the presence document. The example document contains PIDF extensions specified in "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)" [8] and "CIPID: Contact Information in Presence Information Data Format" [9].
このセクションは、XCAPクライアントがXCAPサーバーに提供する存在ドキュメントの例を示しています。存在文書は、（人間の）紹介が休暇に残された状況を示しています。公開されているソフト状態情報がない場合、これはプレゼンスドキュメントを形成するコンポジタへの唯一の入力となります。この例には、「rpid：rick inconess extensionsへの拡張情報（pidf）」[8]および「cipid：存在情報データ形式の連絡先情報」[9]で指定されたPIDF拡張機能が含まれています。
It is assumed that the presentity is a SIP user with Address-of-Record (AOR) sip:someone@example.com. The XCAP root URI for example.com is assumed to be http://xcap.example.com. The XCAP User Identifier (XUI) is assumed to be identical to the SIP AOR, according to XCAP recommendations. In this case, the presence document would be located at http://xcap.example.com/pidf-manipulation/users/ sip:someone@example.com/index.
プレゼンテーションは、record-of-record（aor）sip：soney@example.comを備えたSIPユーザーであると想定されています。たとえば、XCAPルートURIはhttp://xcap.example.comであると想定されています。XCAPユーザー識別子（XUI）は、XCAPの推奨に従って、SIP AORと同一であると想定されています。この場合、プレゼンスドキュメントはhttp://xcap.example.com/pidf-manipulation/users/ sip：soney@example.com/indexにあります。
The presence document is created with the following XCAP operation:
プレゼンスドキュメントは、次のXCAP操作で作成されます。
PUT /pidf-manipulation/users/sip:someone@example.com/index HTTP/1.1
Host: xcap.example.com
Content-Type: application/pidf+xml
...
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
entity="sip:someone@example.com">
<tuple id="x8eg92m">
<status>
<basic>closed</basic>
</status>
<rp:user-input>idle</rp:user-input>
<rp:class>auth-1</rp:class>
<contact priority="0.5">sip:user@example.com</contact>
<note>I'm available only by e-mail.</note>
<timestamp>2004-02-06T16:49:29Z</timestamp>
</tuple>
<tuple id="x8eg92n">
<status>
<basic>open</basic>
</status>
<rp:class>auth-1</rp:class>
<contact priority="1.0">mailto:someone@example.com</contact>
<note>I'm reading mail a couple of times a week</note>
</tuple>
<dm:person id="p1">
<rp:class>auth-A</rp:class>
<ci:homepage>http://www.example.com/~someone</ci:homepage>
<rp:activities>
<rp:vacation/>
</rp:activities>
</dm:person>
</presence>
</存在感>
When the user wants to change the note related to e-mail service, it is done with the following XCAP operation:
ユーザーが電子メールサービスに関連するメモを変更したい場合、次のXCAP操作で行われます。
PUT /pidf-manipulation/users/sip:someone@example.com/index/
~~/presence/tuple%5b@id='x8eg92n'%5d/note HTTP/1.1
If-Match: "xyz"
Host: xcap.example.com
Content-Type: application/xcap-el+xml
...
<note>I'm reading mails on Tuesdays and Fridays</note>
A presence document may contain information that is highly sensitive. Its delivery to watchers needs to happen strictly according to the relevant authorization policies. It is also important that only authorized clients are able to manipulate the presence information.
プレゼンスドキュメントには、非常に敏感な情報が含まれている場合があります。ウォッチャーへの配信は、関連する認可ポリシーに従って厳密に行う必要があります。また、認定されたクライアントのみが存在情報を操作できることも重要です。
The XCAP base specification mandates that all XCAP servers MUST implement HTTP Digest authentication specified in RFC 2617 [5]. Furthermore, XCAP servers MUST implement HTTP over TLS [6]. It is recommended that administrators of XCAP servers use an HTTPS URI as the XCAP root services' URI, so that the digest client authentication occurs over TLS. By using these means, XCAP client and server can ensure the confidentiality and integrity of the XCAP presence document manipulation operations, and that only authorized clients are allowed to perform them.
XCAPベース仕様は、すべてのXCAPサーバーがRFC 2617で指定されたHTTPダイジェスト認証を実装する必要があることを義務付けています[5]。さらに、XCAPサーバーはTLSを介してHTTPを実装する必要があります[6]。XCAPサーバーの管理者は、XCAPルートサービス 'URIとしてHTTPS URIを使用して、TLSを介してDigestクライアント認証が発生するようにすることをお勧めします。これらの手段を使用することにより、XCAPクライアントとサーバーは、XCAPプレゼンスドキュメント操作操作の機密性と整合性を確保でき、認定クライアントのみがそれらを実行することが許可されます。
There is an IANA consideration associated with this specification.
この仕様に関連するIANAの考慮事項があります。
This section registers a new XCAP Application Usage ID (AUID) according to the IANA procedures defined in [2].
このセクションでは、[2]で定義されているIANA手順に従って、新しいXCAPアプリケーション使用ID（AUID）を登録します。
Name of the AUID: pidf-manipulation
AUIDの名前：pidf-manipulation
Description: Pidf-manipulation application usage defines how XCAP is used to manipulate the contents of PIDF-based presence documents.
説明：PIDF操作アプリケーションの使用は、XCAPがPIDFベースの存在ドキュメントの内容を操作するために使用する方法を定義します。
The authors would like to thank Jari Urpalainen, Jonathan Rosenberg, Hisham Khartabil, Aki Niemi, Mikko Lonnfors, Oliver Biot, Alex Audu, Krisztian Kiss, Jose Costa-Requena, George Foti, and Paul Kyzivat for their comments.
著者は、Jari Urpalainen、Jonathan Rosenberg、Hisham Khartabil、Aki niemi、Mikko Lonnfors、Oliver Biot、Alex Audu、Krisztian Kiss、Jose Costa-Requena、George Foti、Paul Kyzivatにコメントに感謝します。
[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] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[2] Rosenberg、J。、「拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）」、RFC 4825、2007年5月。
[3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[3] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年8月。
[4] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[4] Niemi、A。、「イベント州の出版物のセッション開始プロトコル（SIP）拡張」、RFC 3903、2004年10月。
[5] Franks, J., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[5] Franks、J。、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[6] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[7] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[7] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[8] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[8] Schulzrinne、H.、Gurbani、V.、Kyzivat、P。、およびJ. Rosenberg、「rpid：Rich Expentionが存在情報データ形式（PIDF）（PIDF）への拡張」、RFC 4480、2006年7月。
[9] Schulzrinne, H., "CIPID: Contact Information for the Presence Information Data Format", RFC 4482, July 2006.
[9] Schulzrinne、H。、「CIPID：存在情報データ形式の連絡先情報」、RFC 4482、2006年7月。
[10] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[10] Rosenberg、J。、「存在のためのデータモデル」、RFC 4479、2006年7月。
[11] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Work in Progress, July 2006.
[11] Lonnfors、M。and K. Kiss、「セッション開始プロトコル（SIP）ユーザーエージェント機能プレゼンス情報データ形式（PIDF）への拡張機能」、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月。
Authors' Addresses
著者のアドレス
Markus Isomaki Nokia P.O. BOX 100 00045 NOKIA GROUP Finland
Markus isomaki nokia P.O.ボックス100 00045ノキアグループフィンランド
EMail: markus.isomaki@nokia.com
Eva Leppanen Nokia P.O. BOX 785 33101 Tampere Finland
Eva Leppanen Nokia P.O.ボックス785 33101タンペレフィンランド
EMail: eva-maria.leppanen@nokia.com
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エディター機能の資金は現在、インターネット協会によって提供されています。