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）IETFトラスト（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）の使用方法について説明します。イベント状態コンポジタはそれがプレゼンティティの全体的なプレゼンス状態を構築した入力の1つとしてXCAP-操作プレゼンス文書を使用することができ、セッション開始プロトコル（SIP）ベースのプレゼンスシステムにおいて使用されることが意図されます。
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.
インスタントメッセージングとプレゼンス（SIMPLE）のためのセッション開始プロトコル（SIP）仕様は、ユーザは、別のユーザに加入し、ウォッチャーと呼ばれることができ、[7]そのプレゼンス情報を学ぶために、プレゼンティティと呼ばれます。プレゼンスデータモデルは[10]で指定されています。データモデルはperson-、service-、およびデバイスに関連する情報との間の明確な分離を行います。
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は、PUBLISH使用して、プレゼンスユーザエージェント（PUA）は、独立の及び他の不要と思われるアプリケーションによって設定された状態を学ぶ必要がなく、プレゼンス状態のビューを公開することができます。しかし、SIPは、PUBLISH限られた範囲を持っており、プレゼンス状態を設定するためのすべての要件に対応していません。主な問題は、SIPは、それが更新されない限り、ネゴシエート寿命後に期限が切れる柔らかい状態を作成PUBLISHということです。これは、状態が状態をリフレッシュすることができる活性デバイスなしで勝つ必要がある場合のために、それは適しません。
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.
任意の特定のデバイスの活性度とは無関係である永久的なプレゼンス状態の設定が有用である三つの主要なユースケースがあります。最初のケースは、人物に関連した状態を設定することに関するものです。プレゼンは、多くの場合、それが可能な公開できるアクティブデバイスを持っていないときの期間についても、その存在状態を設定したいと思います。良い例、休暇を旅行するなどしています。後者の場合は、プレゼンティティがオンラインそのサービスを実行しているデバイスを持っていない場合でも、通信のために開かれているサービスの状態を設定についてです。サービスのこれらの種類の例としては、電子メール、マルチメディアメッセージングサービス（MMS）、およびショートメッセージサービス（SMS）などがあります。これらのサービスでは、プレゼンは、少なくとも特定の形態では、サービスを持続的に利用できるようにサーバーがプロビジョニングされている、そしてウォッチャーにこれを宣伝できるようにするとよいでしょう。すべての電子メール、MMS、またはSMSサーバが自分でプレゼンス状態を公開することができます（これは可能であったとしても、このような状態が変化することはほとんどないでしょう）、これはいくつかの他のデバイスによって行われなければならないと仮定するのは現実的ではないので、 。サービスの可用性は、そのデバイスに依存しないので、それだけで、このような可用性を公開するために常にアクティブになるように、そのデバイスを必要とすることは非現実的だろう。第三の場合は、積極的にそのような状態をパブリッシュすることが可能な任意のデバイスが存在しない場合に、任意の人、サービス、またはデバイスのデフォルト状態を設定に関する。例えば、プレゼンは、彼または彼女の音声サービスは、現在だけウォッチャーは、このようなサービスはいくつかの点で開いている可能性があることを知らせるために、閉じていることを宣伝したい場合があります。ここでも、デフォルト状態のこのタイプは、任意の特定のデバイスとは無関係であり、むしろ永続考えることができます。
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は、（その存在が主である）SIMPLEベースのプレゼンスシステムに公開プレゼンス状態の主な方法のままであり、特に動的な状態を公開に適している、それが対処するため、この文書で説明されたメカニズムによって補完される必要があるPUBLISHにもかかわらず上記の例を使用します。
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はすでに存在リストとプレゼンス認可ポリシーの操作のためのSIMPLEベースのプレゼンスシステムで使用されています。これは、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）アプリケーションの使用を定義します。プレゼンス情報文書フォーマット（PIDF）PUBLISH SIPに使用されるイベントステートコンポジは既に、それをサポートする必要があるので、[3]は、プレゼンス文書フォーマットとして使用されています。
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 PUBLISHで行わ柔らかい状態発行に関連する方法を詳細に説明しています。
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.
この文書では、キーワード 'MUST'、 'MUST NOT'、 'REQUIRED'、 'SHALL'、 'NOT SHALL'、 'SHOULD'、 'すべきではありません'、 '推奨'、 'MAY'、および 'OPTIONAL' 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.
プレゼンス状態を公開するためのフレームワークは、フレームワークの中央部は、その機能が単一のコヒーレントプレゼンス文書にいくつかのソースから受信したプレゼンス情報を構成するイベント状態合成器素子であり、図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 PUBLISH使用して公開されたソフトステート情報と合成する合成器のための情報源の一つとして見ることができます。これは、通常の場合では、いくつかのPUBLISH SIPとの別のビューを公開のPUAが、単一のXCAP操作プレゼンス文書が存在し得ることが予想される図1に示されています。同図に示すように、複数XCAPクライアントは、（例えば、異なる物理デバイスに）XCAPサーバ上の同じ文書を操作することができ、これは依然としてイベントステートコンポジにのみ1つの入力を生成します。 XCAPサーバーは、XCAPドキュメントの階層における「ユーザー」ツリーの下にXCAP操作プレゼンス文書を格納します。詳細と例については、セクション11のためのセクション9を参照してください。
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によって設定された状態を完全に分離されている公開、直接相互に一つのメカニズムによって設定された状態を操作することは不可能です。コンポはPUBLISHベースの入力をSIPに関してXCAPベースの入力をどのように扱うか、この仕様の範囲を超えているコンポジ政策の問題です。 SIP PUBLISH仕様が既に非直交（またはいくつかの点であっても矛盾）情報を含んでいてもよい、複数の入力からの全体的なプレゼンス状態を構成することができるようにコンポジタを義務付けているので、このXCAP使用率がコンポジタ上の任意の新しい要件を課しません機能。
+---------------+ +------------+
| 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.
また、XCAPの既定のドキュメントの名前空間であるPIDFの名前空間URIは、 '：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サーバは、各ユーザのためにのみ、単一の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クライアントによって提供されるプレゼンス文書の例を提供します。プレゼンス文書は、（人間の）プレゼンが休暇のために残している状況を示しており、彼は電子メールでのみ利用可能であるように、その前に、彼の存在の情報を設定しています。任意の公表ソフトステート情報がない場合には、これは、プレゼンス文書を構成するコンポへの唯一の入力になります。 [9]：「プレゼンス情報データ形式で情報を問い合わせCIPIDは、」[8]と：「プレゼンス情報データフォーマット（PIDF）にリッチプレゼンス機能拡張RPID」例の文書がで指定された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.
someone@example.com：プレゼンティティがアドレス・オブ・レコード（AOR）SIPとSIPユーザであると仮定する。 example.comのXCAPルートURIはhttp://xcap.example.comであると仮定されます。 XCAPユーザ識別子（XUI）は、XCAPの推奨に従って、SIP AORと同一であると仮定されます。 someone@example.com/index：この場合、プレゼンス文書はhttp://xcap.example.com/pidf-manipulation/users/一口に配置されることになります。
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 ...
xcap.example.comのContent-Type：アプリケーション/ PIDF + xmlの... /pidf-manipulation/users/sip:someone@example.com/index HTTP / 1.1ホストをPUT
<?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">
<プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" <XMLバージョン= "1.0" エンコード= "UTF-8"？>のxmlns：RP =「URN：IETF：paramsは：XML：NS：PIDF ：RPID "のxmlns：DM = "壷：IETF：のparams：XML：NS：PIDF：データ・モデル" のxmlns：CI = "壷：IETF：のparams：XML：NS：PIDF：cipid" 実体=" 一口：誰か@ 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>
<タプルID = "x8eg92n"> <状態>
<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>
<基本>開く</基本> </状態> <RP：クラス>のauth-1 </ RP：クラス> <連絡先の優先= "1.0">のmailto：someone@example.com </連絡先> <ノート>私は」 m個の読み取りが週数回を郵送</ノート> </タプル>
<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>
<DM：人のid = "P1"> <RP：クラス>のauth-A </ RP：クラス> <CI：ホームページ> http://www.example.com/~someone </ CI：ホームページ> <RP：活動> <RP：休暇/> </ RP：活動> </ DM：人>
</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 ...
/pidf-manipulation/users/sip:someone@example.com/index/ ~~ /プレゼンス/タプル％5bは、@ ID = 'x8eg92n' ％5D /ノートHTTP / 1.1は、場合-マッチPUT： "XYZ" ホスト：XCAPを。 example.comのContent-Type：アプリケーション/ 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サーバがRFC 2617で指定されたHTTPダイジェスト認証を実装しなければならないXCAPベース指定義務[5]。さらに、XCAPサーバがTLS上でHTTPを実装しなければならない[6]。ダイジェストクライアント認証がTLS上で行われるようにXCAPサーバの管理者は、XCAPルートサービスのURIとしてHTTPS URIを使用することをお勧めします。これらの手段を使用することにより、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-操作
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.
作者は彼らのコメントのためにヤリUrpalainen、ジョナサン・ローゼンバーグ、ヒシャムKhartabil、アキニエミ、ミッコLonnfors、オリバー・ビオ、アレックスAudu、Krisztianキス、ホセコスタ・レケーナ、ジョージFOTI、そしてポール・Kyzivatに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[2]ローゼンバーグ、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]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット（PIDF）"、RFC 3863、2004年8月。
[4] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[4]ニエミ、A.、 "イベント状態の出版のためのセッション開始プロトコル（SIP）の拡張"、RFC 3903、2004年10月。
[5] Franks, J., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[5]フランクス、J.、 "HTTP認証：基本とダイジェストアクセス認証"、RFC 2617、1999年6月。
[6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[6]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。
[7] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[7]ローゼンバーグ、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.ローゼンバーグが、 "RPID：リッチプレゼンス機能拡張プレゼンス情報データフォーマット（PIDF）に"、RFC 4480、2006年7月。
[9] Schulzrinne, H., "CIPID: Contact Information for the Presence Information Data Format", RFC 4482, July 2006.
[9] Schulzrinneと、H.、：、RFC 4482、2006年7月 "CIPIDは、プレゼンス情報データフォーマットの連絡先情報"。
[10] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[10]ローゼンバーグ、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.とK.キス、「プレゼンス情報データフォーマット（PIDF）にセッション開始プロトコル（SIP）ユーザエージェントの機能拡張」、進歩、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.
「過去と未来の時間間隔のステータス情報を示すために、プレゼンス情報データフォーマット（PIDF）に時限プレゼンス拡張機能」[12] Schulzrinneと、H.、RFC 4481、2006年7月。
Authors' Addresses
著者のアドレス
Markus Isomaki Nokia P.O. BOX 100 00045 NOKIA GROUP Finland
まｒくｓ いそまき のきあ Ｐ。お。 ぼＸ １００ ０００４５ のきあ ＧろうＰ ふぃんぁんｄ
EMail: markus.isomaki@nokia.com
メールアドレス：markus.isomaki@nokia.com
Eva Leppanen Nokia P.O. BOX 785 33101 Tampere Finland
エヴァLeppanen Nokiaの私書箱BOX 785 33101タンペレ、フィンランド
EMail: eva-maria.leppanen@nokia.com
メールアドレス：eva-maria.leppanen@nokia.com
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。