Network Working Group J. Rosenberg
Request for Comments: 5025 Cisco
Category: Standards Track December 2007
Presence Authorization Rules
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted.
認可は、プレゼンスシステムにおける重要な機能です。また、認可規則として知られている認可ポリシーは、どのウォッチャー、およびときに与えることができるどのようなプレゼンス情報を指定します。この仕様は、プレゼンス認可ルールを表現するための拡張マークアップ言語（XML）ドキュメントフォーマットを定義します。他の技術が許可されているが、このような文書は、XML構成アクセスプロトコル（XCAP）を使用して、クライアントによって操作することができます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Structure of Presence Authorization Documents ...................3
3.1. Conditions .................................................4
3.1.1. Identity ............................................4
3.1.1.1. Acceptable Forms of Authentication .........4
3.1.1.2. Computing a URI for the Watcher ............5
3.1.2. Sphere ..............................................6
3.2. Actions ....................................................7
3.2.1. Subscription Handling ...............................7
3.3. Transformations ............................................9
3.3.1. Providing Access to Data Component Elements .........9
3.3.1.1. Device Information .........................9
3.3.1.2. Person Information ........................10
3.3.1.3. Service Information .......................11
3.3.2. Providing Access to Presence Attributes ............12
3.3.2.1. Provide Activities ........................12
3.3.2.2. Provide Class .............................12
3.3.2.3. Provide DeviceID ..........................13
3.3.2.4. Provide Mood ..............................13
3.3.2.5. Provide Place-is ..........................13
3.3.2.6. Provide Place-type ........................13
3.3.2.7. Provide Privacy ...........................13
3.3.2.8. Provide Relationship ......................14
3.3.2.9. Provide Sphere ............................14
3.3.2.10. Provide Status-Icon ......................14
3.3.2.11. Provide Time-Offset ......................14
3.3.2.12. Provide User-Input .......................14
3.3.2.13. Provide Note .............................15
3.3.2.14. Provide Unknown Attribute ................15
3.3.2.15. Provide All Attributes ...................16
4. When to Apply the Authorization Policies .......................17
5. Implementation Requirements ....................................17
6. Example Document ...............................................18
7. XML Schema .....................................................19
8. Schema Extensibility ...........................................21
9. XCAP Usage .....................................................22
9.1. Application Unique ID .....................................22
9.2. XML Schema ................................................22
9.3. Default Namespace .........................................22
9.4. MIME Type .................................................22
9.5. Validation Constraints ....................................22
9.6. Data Semantics ............................................22
9.7. Naming Conventions ........................................23
9.8. Resource Interdependencies ................................23
9.9. Authorization Policies ....................................23
10. Security Considerations .......................................23
11. IANA Considerations ...........................................24
11.1. XCAP Application Usage ID ................................24
11.2. URN Sub-Namespace Registration ...........................25
11.3. XML Schema Registrations .................................25
12. Acknowledgements ..............................................26
13. References ....................................................26
13.1. Normative References .....................................26
13.2. Informative References ...................................27
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 [17], in order to learn their presence information [18]. This subscription is handled by a presence agent. However, presence information is sensitive, and a presence agent needs authorization from the presentity prior to handing out presence information. As such, a presence authorization document format is needed. This specification defines a format for such a document, called a presence authorization document.
インスタントメッセージングとプレゼンスのためのセッション開始プロトコル（SIP）（SIMPLE）の仕様は、自分のプレゼンス情報[18]を学ぶために、[17]プレゼンと呼ばれ、ユーザーは、他のユーザに加入し、ウォッチャーと呼ばれることができます。このサブスクリプションが存在エージェントによって処理されます。しかし、プレゼンス情報は敏感であり、プレゼンスエージェントは、以前のプレゼンス情報を配っにプレゼンティティからの承認を必要とします。そのため、プレゼンスの認可文書形式が必要とされています。この仕様は、プレゼンス認可文書と呼ばれるような文書のためのフォーマットを定義します。
[8] specifies a framework for representing authorization policies, and is applicable to systems such as geo-location and presence. This framework is used as the basis for presence authorization documents. In the framework, an authorization policy is a set of rules. Each rule contains conditions, actions, and transformations. The conditions specify under what conditions the rule is to be applied to presence server processing. The actions element tells the server what actions to take. The transformations element indicates how the presence data is to be manipulated before being presented to that watcher, and as such, defines a privacy filtering operation. [8] identifies a small number of specific conditions common to presence and location services, and leaves it to other specifications, such as this one, to fill in usage specific details.
[8]認可ポリシーを表現するためのフレームワークを指定し、そのような地理的位置とプレゼンスのようなシステムにも適用可能です。このフレームワークは、プレゼンス認可文書のための基礎として使用されます。フレームワークでは、認可ポリシーは、ルールのセットです。各ルールは、条件、アクション、および変換が含まれています。条件は、ルールがプレゼンスサーバの処理に適用されるどのような条件の下で指定します。アクション要素は、どのような行動を取るようにサーバに指示します。変換要素は、プレゼンスデータがそのウォッチャーに提示される前に操作する方法を示し、そのようなものとして、プライバシーフィルタ処理を定義します。 [8]の存在及びロケーションサービスに共通する特定の条件の小さな数を特定し、使用の特定の詳細を入力するために、このいずれかのような他の仕様にそれを残します。
A presence authorization document can be manipulated by clients using several means. One such mechanism is the XML Configuration Access Protocol (XCAP) [2]. This specification defines the details necessary for using XCAP to manage presence authorization documents.
プレゼンス認可文書は、いくつかの手段を使用しているクライアントによって操作することができます。一つのそのような機構は、XML構成アクセスプロトコル（XCAP）[2]です。この仕様は、プレゼンス認可文書を管理するためにXCAPを使用するために必要な詳細を定義します。
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"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" RFC 2119に記載されるように解釈されるべきである[1]と対応する実装の要求レベルを示します。
A presence authorization document is an XML document, formatted according to the schema defined in [8]. Presence authorization documents inherit the MIME type of common policy documents, application/auth-policy+xml. As described in [8], this document is composed of rules that contain three parts - conditions, actions, and transformations. Each action or transformation, which is also called a permission, has the property of being a positive grant of information to the watcher. As a result, there is a well-defined mechanism for combining actions and transformations obtained from several sources. This mechanism is privacy safe, since the lack of any action or transformation can only result in less information being presented to a watcher.
プレゼンス認可文書[8]で定義されたスキーマに従ってフォーマットされたXML文書です。プレゼンス認可文書は、共通の政策文書、アプリケーション/ AUTH-政策+ XMLのMIMEタイプを継承します。条件、アクション、および変換 - に記載されているように[8]、本文書は、3つの部分を含むルールで構成されています。また、許可呼ばれる各アクションまたは変換は、ウォッチャへの情報の正付与性質を有しています。結果として、いくつかの供給源から得られる作用及び変換を組み合わせるための明確に定義されたメカニズムがあります。任意のアクションまたは変換の欠如が唯一のウォッチャに提示されている以下の情報になりますので、このメカニズムは、プライバシ安全です。
This section defines the new conditions, actions, and transformations defined by this specification.
このセクションでは、この仕様で定義された新たな条件、アクション、および変換を定義します。
Although the <identity> element is defined in [8], that specification indicates that the specific usages of the framework document need to define details that are protocol and usage specific. In particular, it is necessary for a usage of the common policy framework to:
<アイデンティティ>要素は、[8]で定義されているが、その仕様は、フレームワーク文書の特定の用途は、プロトコルおよび使用に特異的であり、詳細を定義する必要があることを示しています。特に、共通のポリシーフレームワークの使用のために必要です。
o Define acceptable means of authentication.
O認証の許容可能な手段を定義します。
o Define the procedure for representing the identity of the WR (Watcher/Requestor) as a URI or Internationalized Resource Identifier (IRI) [13].
O URIまたは国際リソース識別子（IRI）[13]のようにWR（ウォッチャー/リクエスタ）のアイデンティティを表現するための手順を定義します。
This sub-section defines those details for systems based on [18]. It does so in general terms, so that the recommendations defined here apply to existing and future authentication mechanisms in SIP.
このサブセクションでは、[18]に基づいて、システムのそれらの詳細を規定します。ここで定義された勧告は、SIPにおける既存および将来の認証メカニズムに適用されるように、それは、一般的にそう。
When used with SIP, a request is considered authenticated if one of the following is true:
SIPで使用する場合、次のいずれかに該当する場合、要求は認証とみなされます。
The watcher proves its identity to the server through a form of cryptographic authentication, including authentication based on a shared secret or a certificate, and that authentication yields an identity for the watcher.
ウォッチャーは、共有秘密または証明書に基づく認証を含む暗号化認証の形、を介してサーバにその身元を証明し、その認証がウォッチャーのIDを生成します。
The request comes from a sender that is asserting the identity of the watcher, and:
リクエストは、ウォッチャのアイデンティティを主張しており、送信者から来ています：
1. the assertion includes a claim that the asserting party used a form of cryptographic authentication (as defined above) to determine the identity of the watcher, and
1.アサーションは、（上記で定義した通り）をアサート当事者がウォッチャのアイデンティティを決定するために、暗号化認証の形式を使用する、請求項を含み、そして
Based on this definition, examples of valid authentication techniques include SIP [5], digest authentication [4], cryptographically verified identity assertions (RFC 4474 [15]), and identity assertions made in closed network environments (RFC 3325 [16]).
この定義に基づいて、有効な認証技術の例は、SIP [5]、ダイジェスト認証を含む[4]、暗号検証IDアサーション（RFC 4474 [15]）、および閉じたネットワーク環境で作られたIDアサーション（RFC 3325 [16]）。
However, the anonymous authentication described on page 194 of RFC 3261 [5] is not considered a valid mechanism for authentication
しかし、匿名認証は、RFC 3261の194ページで説明[5]認証のための有効なメカニズムと考えられていません
because it does not produce an identity for the watcher. However, an anonymous From header field, when used in conjunction with RFC 4474 [15], is considered an acceptable mechanism for authentication, since it still implies that the asserting node performed authentication that produced the identity of the watcher.
それはウォッチャーのIDを生成しませんので。それが依然としてアサートノードがウォッチャのアイデンティティを生成認証を行うことを意味するので、RFC 4474 [15]と組み合わせて使用されるヘッダフィールドから、しかし、匿名は、認証のために許容可能なメカニズムであると考えられます。
Computing the URI for the watcher depends on whether the identity is being ascertained through authentication or through an asserted identity.
ウォッチャーのためのURIを計算することは身元が認証を介して、またはアサートアイデンティティを通じて確認されているかどうかに依存します。
If an identity assertion is being utilized, the asserted identity itself (which is in the form of a URI for acceptable forms of identity assertion) is utilized as the URI. If the identity assertion mechanism asserts multiple URIs for the watcher, then each of them is used for the comparisons outlined in [8], and if any of them match a <one> or <except> element, the watcher is considered a match.
IDアサーションが利用されている場合、（IDアサーションの許容される形態のURIの形である）がアサートアイデンティティ自体はURIとして利用されます。 IDアサーション機構がウォッチャーのために複数のURIをアサートする場合、それらの各々は、[8]に概説比較のために使用され、それらのいずれかは、<1>又は一致する場合要素<除い>、ウォッチャが一致とみなされます。
If an identity is being determined directly by a cryptographic authentication, that authentication must produce a URI, or must produce some form of identifier that can be linked, through provisioning, to a URI that is bound to that identifier.
アイデンティティが暗号認証によって直接的に決定されている場合、その認証は、URIを生成しなければならない、又はその識別子にバインドされたURIに、プロビジョニングを介して、連結することができる識別子のいくつかのフォームを生成しなければなりません。
For example, in the case of SIP Digest authentication, the authentication process produces a username scoped within a realm. That username and realm are bound to an Address of Record (AOR) through provisioning, and the resulting AOR is used as the watcher URI. Consider the following "user record" in a database:
例えば、SIPダイジェスト認証の場合、認証プロセスは、レルム内のスコープ名を生成します。そのユーザ名とレルムは、プロビジョニングを通じてレコード（AOR）のアドレスにバインドされ、得られたAORをウォッチャーURIとして使用されます。データベースで、次の「ユーザー・レコード」を考えてみましょう：
SIP AOR: sip:alice@example.com digest username: ali digest password: f779ajvvh8a6s6 digest realm: example.com
SIPのAOR：SIP：alice@example.comユーザー名をダイジェスト：アリは、パスワードをダイジェスト：レルムをダイジェストf779ajvvh8a6s6：example.com
If the presence server receives a SUBSCRIBE request, challenges it with the realm set to "example.com", and the subsequent SUBSCRIBE contains an Authorization header field with a username of "ali" and a digest response generated with the password "f779ajvvh8a6s6", the identity used in matching operations is "sip:alice@example.com".
プレゼンスサーバは、SUBSCRIBEリクエストを受信した場合、「example.com」に設定されている領域でそれに挑戦し、それ以降はSUBSCRIBE「アリ」のユーザー名とパスワード「f779ajvvh8a6s6」で生成されたダイジェスト応答でAuthorizationヘッダフィールドが含まれています、マッチング操作に使用されるIDは「：alice@example.com一口」です。
In SIP systems, it is possible for a user to have aliases - that is, there are multiple SIP AORs "assigned" to a single user. In terms of this specification, there is no relationship between those aliases. Each would look like a different user. This will be the consequence for systems where the watcher is in a different domain than the presentity. However, even if the watcher and presentity are in the same domain, and the presence server knows that there are aliases for the watcher, these aliases are not mapped to each other or used in any way.
SIPシステムでは、別名を持っているユーザーのために可能である - つまり、単一のユーザに「割り当てられた」複数のSIPのAORがあります。この仕様の面では、これらの別名の間には関係がありません。それぞれが別のユーザーのようになります。これは、ウォッチャーがプレゼンとは異なるドメインにあるシステムのための結果となります。しかし、ウォッチャーとプレゼンが同じドメイン内にあり、プレゼンスサーバがウォッチャーの別名があることを知っている場合でも、これらのエイリアスは、相互にマッピングされたか、どのような方法で使用されていません。
SIP also allows for anonymous requests. If a request is anonymous because the watcher utilized an authentication mechanism that does not provide an identity to the presence server (such as the SIP digest "anonymous" username), the request is considered unauthenticated (as discussed above) and will match only an empty <identity> element. If a request is anonymous because it contains a Privacy header field [14], but still contains an asserted identity meeting the criteria defined above, that identity is utilized, and the fact that the request was anonymous has no impact on the identity processing.
SIPはまた、匿名の要求が可能になります。ウォッチャは、（上述のように）、要求が認証されていないと考えられている（例えば、SIPダイジェスト「匿名」ユーザー名など）をプレゼンスサーバに識別情報を提供していないとのみ空に一致する認証メカニズムを利用したため、要求が匿名である場合<アイデンティティ>要素。それはプライバシーヘッダフィールド[14]を含んでいるが、それでもそのIDが利用される、上記で定義された基準を満たすアサートされたアイデンティティを含み、要求が匿名であるという事実は、同一の処理に影響を及ぼさないため、要求が匿名である場合。
It is important to note that SIP frequently uses both SIP URI and tel URI [12] as identifiers, and to make matters more confusing, a SIP URI can contain a phone number in its user part, in the same format used in a tel URI. A WR identity that is a SIP URI with a phone number will NOT match the <one> and <except> conditions whose 'id' is a tel URI with the same number. The same is true in the reverse. If the WR identity is a tel URI, this will not match a SIP URI in the <one> or <except> conditions whose user part is a phone number. URIs of different schemes are never equivalent.
SIPが頻繁に識別子としてSIP URI及びTEL URI [12]の両方を使用し、問題がさらに混乱にするために、SIP URIは、TEL URIで使用したのと同じ形式で、そのユーザーの一部に電話番号を含めることができることに注意することは重要ことをです。電話番号とSIP URIをあるWRのアイデンティティは、その「ID」と同じ番号のTEL URIをある<1>と<除く>の条件とは一致しません。同じことが逆に真です。 WRのアイデンティティはTEL URIであれば、これは、そのユーザー一部の電話番号である条件<除い> <1>にSIP URIと一致したりしません。異なるスキームのURIは等価では決してありません。
The <sphere> element is defined in [8]. However, each application making use of the common policy specification needs to determine how the presence server computes the value of the <sphere> to be used in the evaluation of the condition.
<球>要素は、[8]で定義されています。しかし、一般的なポリシーの仕様を利用する各アプリケーションは、プレゼンスサーバは、条件の評価に使用される<球>の値を計算する方法を決定する必要があります。
To compute the value of <sphere>, the presence agent examines all published presence documents for the presentity. If at least one of them includes the <sphere> element [9] as part of the person data component [10], and all of those containing the element have the same value for it, which is the value used for the <sphere> in presence policy processing. If, however, the <sphere> element was not present in any of the published documents, or it was present but had inconsistent values, its value is considered undefined in terms of presence policy processing.
<球>の値を計算するには、プレゼンスエージェントは、プレゼンのためのすべての公開プレゼンス文書を調べます。それらの少なくとも1つは、個人データ成分の一部として<球>要素[9] [10]を含み、元素を含有するものの全ては、<球>のために使用される値であり、それに対して同じ値を有する場合プレゼンスポリシーの処理インチしかし、<球>要素が公開された文書のいずれにも存在しなかった、またはそれが存在していたが、一貫性のない値を持っていた場合、その値は、プレゼンスポリシー処理の面で未定義と考えられています。
Care must be taken in using <sphere> as a condition for determining the subscription handling. Since the value of <sphere> changes dynamically, a state change can cause a subscription to be suddenly terminated. The watcher has no way to know, aside from polling, when their subscription would be reinstated as the value of <sphere> changes. For this reason, <sphere> is primarily useful for matching on rules that define transformations.
ケアは、サブスクリプションの取り扱いを決定するための条件として、<球>を使用して撮影する必要があります。動的に<球>の値が変化するので、状態変化は、サブスクリプションが突然終了されることがあります。ウォッチャーはさておき、そのサブスクリプションが<球>の値が変化すると復活するだろうポーリング、から、知る方法がありません。この理由のため、<球は>変換を定義するルールに一致させるため、主に有用です。
The <sub-handling> element specifies the subscription authorization decision that the server should make. It also specifies whether or not the presence document for the watcher should be constructed using "polite blocking". Usage of polite blocking and the subscription authorization decision are specified jointly since proper privacy handling requires a correlation between them. As discussed in [8], since the combination algorithm runs independently for each permission, if correlations exist between permissions, they must be merged into a single variable. That is what is done here. The <sub-handling> element is an enumerated Integer type. The defined values are:
<サブハンドリング>要素は、サーバが実行するサブスクリプション認可決定を指定します。また、ウォッチャーのプレゼンス文書は「丁寧なブロッキングを」使用して構築する必要があるかどうかを指定します。適切なプライバシーの取り扱いは、それらの間の相関関係を必要とするため、丁寧ブロックおよびサブスクリプション認可判断の使用が共同で指定されています。 [8]で議論するように組み合わせアルゴリズムは、各許可を独立に実行されるため相関がアクセス許可の間に存在する場合、それらは、単一の変数に統合されなければなりません。それはここで行われているものです。 <サブハンドリング>要素は、列挙された整数型です。定義された値は次のとおりです。
block: This action tells the server to reject the subscription, placing it in the "terminated" state. It has the value of zero, and it represents the default value. No value of the <sub-handling> element can ever be lower than this. Strictly speaking, it is not necessary for a rule to include an explicit block action, since the default in the absence of any action will be block. However, it is included for completeness.
ブロック：このアクションは、「終了」状態に置く、サブスクリプションを拒否するようにサーバーに指示します。これは、ゼロの値を持ち、それはデフォルト値を表します。 <サブ取り扱い>要素のいかなる値が今までこれより低くなることはできません。厳密に言えば、それは任意のアクションが存在しない場合のデフォルトはブロックされるので、明示的なブロックのアクションを含むように、ルールは必要ありません。しかし、それは完全を期すために含まれています。
confirm: This action tells the server to place the subscription in the "pending" state, and await input from the presentity to determine how to proceed. It has a value of ten.
このアクションは、「保留」状態でサブスクリプションを配置するために、サーバーに指示し、処理方法を決定するためにプレゼンティティからの入力を待つ：確認。それは10の値を持ちます。
polite-block: This action tells the server to place the subscription into the "active" state, and to produce a presence document that indicates that the presentity is unavailable. A reasonable document would exclude device and person information elements, and include only a single service whose basic status is set to closed [3]. This action has a value of twenty.
丁寧なブロック：このアクションは、「アクティブ」状態にサブスクリプションを配置するために、そしてプレゼンが利用できないことを示しているプレゼンス文書を生成するために、サーバーに指示します。妥当な文書は、デバイスと個人情報要素を除外して、その基本的なステータス閉に設定されている単一のサービスを含むことになる[3]。このアクションは、20の値を持ちます。
allow: This action tells the server to place the subscription into the "active" state. This action has a value of thirty.
許可：このアクションは、「アクティブ」状態にサブスクリプションを配置するために、サーバーに指示します。このアクションは、30の値を持ちます。
NOTE WELL: Placing a value of block for this element does not guarantee that a subscription is denied! If any matching rule has any other value for this element, the subscription will receive treatment based on the maximum of those other values. This is based on the combining rules defined in [8].
よの注：この要素のブロックの値を配置すると、サブスクリプションが拒否されたことを保証するものではありません！任意のマッチングルールがこの要素の任意の他の値を有する場合、サブスクリプションは、それらの他の値の最大値に基づいて治療を受けます。これは、[8]で定義された合成規則に基づいています。
Future specifications that wish to define new types of actions MUST define an entirely new action (separate from <sub-handling>), and define their own set of values for that action. A document could contain both <sub-handling> and a subscription handling action defined by a future specification; in that case, since each action is always a positive grant of information, the resulting action is the least restrictive one across both elements.
アクションの新しいタイプを定義したい将来の仕様は、（<サブ取り扱い>とは別の）全く新しいアクションを定義し、そのアクションの値の独自のセットを定義しなければなりません。文書には、両方の<サブ取り扱い>および将来の仕様で定義されたサブスクリプションの処理アクションを含めることができます。各アクションは、常に情報の正グラントであるので、その場合には、得られたアクションは、両方の要素を横切る少なくとも制限するものです。
The exact behavior of a presence server upon a change in the sub-handling value can be described by utilizing the subscription processing state machine in Figure 1 of RFC 3857 [6].
サブ処理値の変化時に、プレゼンスサーバの正確な動作は、RFC 3857の図1にサブスクリプション処理状態機械を利用して記述することができる[6]。
If the <sub-handling> permission changes value to "block", this causes a "rejected" event to be generated into the subscription state machine for all affected subscriptions. This will cause the state machine to move into the "terminated" state, resulting in the transmission of a NOTIFY to the watcher with a Subscription-State header field with value "terminated" and a reason of "rejected" [7], which terminates their subscription. If a new subscription arrives later on, and the value of <sub-handling> that applies to that subscription is "block", the subscription processing follows the "subscribe, policy=reject" branch from the "init" state, and a 403 response to the SUBSCRIBE is generated.
<サブ取扱い>許可は、「ブロック」に値を変更した場合、これは、影響を受けるすべてのサブスクリプションのサブスクリプション・ステート・マシン内に生成されるイベントを「拒否」が発生します。これが終了すると、状態機械は「終了」値とSubscription-StateヘッダフィールドとウォッチャにNOTIFYの送信及び[7]「拒否」の理由で、その結果、「終了」状態に移動させるであろうそのサブスクリプション。新しいサブスクリプションは、後に到着し、そのサブスクリプションに適用される<サブ取り扱い>の値が「ブロック」で、サブスクリプション処理は、以下の場合は、「初期化」状態からの分岐、および403を「サブスクライブ、ポリシーが拒否します=」 SUBSCRIBEに対する応答が生成されます。
If the <sub-handling> permission changes value to "confirm", the processing depends on the states of the affected subscriptions. Unfortunately, the state machine in RFC 3857 does not define an event corresponding to an authorization decision of "pending". If the subscription is in the "active" state, it moves back into the "pending" state. This causes a NOTIFY to be sent, updating the Subscription-State [7] to "pending". No reason is included in the Subscription-State header field (none are defined to handle this case). No further documents are sent to this watcher. There is no change in state if the subscription is in the "pending", "waiting", or "terminated" states. If a new subscription arrives later on, and the value of <sub-handling> that applies to that subscription is "confirm", the subscription processing follows the "subscribe, no policy" branch from the "init" state, and a 202 response to the SUBSCRIBE is generated, followed by a NOTIFY with Subscription-State of "pending". No presence document is included in that NOTIFY.
<サブ取扱い>許可を「確認」する値を変更した場合、処理が影響を受けたサブスクリプションの状態に依存します。残念ながら、RFC 3857でのステートマシンは「保留」の認可判断に対応するイベントを定義していません。サブスクリプションが「アクティブ」状態にある場合、それは「保留」状態に戻ります。これは、[7]「保留」するサブスクリプションのステートを更新し、送信するNOTIFYの原因となります。理由は、（いずれもこのケースを扱うために定義されていない）Subscription-Stateヘッダフィールドに含まれていません。それ以上の文書は、この環視者に送信されません。サブスクリプションは、「保留中」、「待機中」、または「終了」の状態にある場合、状態の変更はありません。新しいサブスクリプションは、後に到着し、そのサブスクリプションに適用される<サブ取り扱い>の値が「確認」した場合、サブスクリプション処理は、「初期化」状態から「購読、ノー政策」支店、および202応答を以下の購読するには、生成された「保留」のサブスクリプションのステートでNOTIFYが続きます。いいえプレゼンス文書は、そのNOTIFYには含まれません。
If the <sub-handling> permission changes value from "blocked" or "confirm" to "polite-block" or "allow", this causes an "approved" event to be generated into the state machine for all affected subscriptions. If the subscription was in the "pending" state, the state machine will move to the "active" state, resulting in the transmission of a NOTIFY with a Subscription-State header field of "active", and the inclusion of a presence document in that NOTIFY.
<サブ取扱い>許可は、「ブロック」または「確認」から値を変更した場合、「丁寧・ブロック」や、これが影響を受けるすべてのサブスクリプションのためのステートマシンに生成されるように、「承認」イベントが発生し、「許可する」に。サブスクリプションは「保留」状態にあった場合、状態機械は「アクティブ」のSubscription-StateヘッダフィールドとNOTIFYの送信の結果、「アクティブ」状態に移動し、プレゼンス文書を含めることであろうそれは、NOTIFY。
If the subscription was in the "waiting" state, it will move into the "terminated" state. If a new subscription arrives later on, and the value of <sub-handling> that applies to that subscription is "polite-block" or "allow", the subscription processing follows the "subscribe, policy=accept" branch from the "init" state, and a 200 OK response to the SUBSCRIBE is generated, followed by a NOTIFY with Subscription-State of "active" with a presence document in the body of the NOTIFY.
サブスクリプションは「待ち」状態にあった場合、それは「終了」状態に移行します。新しいサブスクリプションは、後に到着し、そのサブスクリプションに適用される<サブ取り扱い>の値が「丁寧・ブロック」または「許可」である場合は、サブスクリプション処理は「INITから「購読政策=受け入れる」ブランチを次のNOTIFYの身体におけるプレゼンス文書と 『アクティブ」状態、及び加入する200 OK応答は、サブスクリプションのステートとNOTIFY続いて、生成されます』。
The transformations defined here are used to drive the behavior of the privacy filtering operation. Each transformation defines the visibility a watcher is granted to a particular component of the presence document. One group of transformations grants visibility to person, device, and service data elements based on identifying information for those elements. Another group of transformations provides access to particular data elements in the presence document.
ここで定義された変換は、プライバシーフィルタ操作の動作を駆動するために使用されています。各変換は、ウォッチャーがプレゼンスドキュメントの特定のコンポーネントに付与された可視性を定義します。変換の一つのグループは、それらの要素のための識別情報に基づいて、人物、デバイス、及びサービスデータ要素に可視性を付与します。変換の別のグループは、プレゼンス文書内の特定のデータ要素へのアクセスを提供します。
The transformations in this section provide access to person, device, and service data component elements. Once access has been granted to such an element, access to specific presence attributes for that element is controlled by the permissions defined in Section 3.3.2.
このセクションの変換は人物、デバイス、及びサービスデータ構成要素へのアクセスを提供します。アクセスは、このような要素に付与されていたら、その要素は、3.3.2項で定義された権限によって制御されているため、具体的な存在へのアクセスが属性。
The <provide-devices> permission allows a watcher to see <device> information present in the presence document. It is a set variable. Each member of the set provides a way to identify a device or group of devices. This specification defines three types of elements in the set - <class>, which identifies a device occurrence by class; <deviceID>, which identifies a device occurrence by device ID; and <occurrence-id>, which identifies a device occurrence by occurrence ID. The device ID and occurrence ID are defined in [10]. Each member of the set is identified by its type (class, deviceID, or occurrence-id) and value (value of the class, value of the deviceID, or value of the occurrence-id).
<提供-装置>許可は、ウォッチャーはプレゼンス文書内に存在する<デバイス>情報を見ることを可能にします。これは、設定された変数です。セットの各メンバーは、デバイスまたはデバイスのグループを識別するための方法を提供します。この仕様は、セット内の要素の3種類の定義 - <クラス>、クラスによってデバイスの発生を識別する。 <deviceIDの>、デバイスIDによってデバイスの発生を識別する。そして発生IDによってデバイスの発生を識別する<発生-ID>。デバイスID及び発生IDは[10]で定義されています。セットの各メンバーは、そのタイプ（クラスとデバイス、または発生-ID）と値（階級の値とデバイスの値、または発生-IDの値）によって識別されます。
For example, consider the following <provide-devices> element:
たとえば、次の<提供-デバイス>要素を考慮してください。
<provide-devices> <deviceID>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</deviceID> <class>biz</class> </provide-devices>
<提供-装置> <deviceIDの> URN：UUID：f81d4fae-7dec-11D0-a765-00a0c91e6bf6 </ deviceIDの> <クラス> BIZ </クラス> </提供、デバイス>
This set has two members. This is combined with a <provide-devices> element from a different rule:
このセットには、二つの部材を持っています。これは、異なるルールから<提供-装置>要素と組み合わされます。
<provide-devices> <class>home</class> <class>biz</class> </provide-devices>
<提供-デバイス> <クラス>ホーム</クラス> <クラス>ビズ</クラス> </提供-デバイス>
The result of the set combination (using the union operation) is a set with three elements:
（和演算を使用して）設定された組み合わせの結果は、3つの要素が設定されています。
<provide-devices> <class>home</class> <class>biz</class> <deviceID>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</deviceID> </provide-devices>
<提供-デバイス> <クラス>ホーム</クラス> <クラス>ビズ</クラス> <deviceIDの> URN：UUID：f81d4fae-7dec-11D0-a765-00a0c91e6bf6 </のdeviceID> </提供-デバイス>
The <provide-devices> element can also take on the special value <all-devices>, which is a short-hand notation for all device occurrences present in the presence document.
<提供-装置>要素は、プレゼンス文書内に存在するすべてのデバイスの出現のためのショートハンド表記である特別な値<全デバイス>、をとることができます。
Permission is granted to see a particular device occurrence if one of the device identifiers in the set identifies that device occurrence. If a <class> permission is granted to the watcher, and the <class> of the device occurrence matches the value of the <class> permission based on case-sensitive equality, the device occurrence is included in the presence document. If a <deviceID> permission is granted to the watcher, and the <deviceID> of the device occurrence matches the value of the <deviceID> permission based on URI equivalence, the device occurrence is included in the presence document. If an <occurrence-id> permission is granted to the watcher, and the <occurrence-id> of the device occurrence matches the value of the <occurrence-id> permission based on case-sensitive equality, the device occurrence is included in the presence document. In addition, a device occurrence is included in the presence document if the <all-devices> permission was granted to the watcher.
許可は、セット内のデバイス識別子の一つは、そのデバイスの発生を識別する場合、特定のデバイスの発生を見ることが許可されます。 <クラス>許可をウォッチャに付与され、そしてデバイス発生の<クラス>は、大文字と小文字を区別し平等に基づいて<クラス>許可の値と一致する場合、デバイスの発生をプレゼンス文書に含まれています。 <deviceIDの>許可をウォッチャに付与され、そして<deviceIDの>デバイスの発生がURI等価に基づいて<deviceIDの>許可の値と一致する場合、デバイスの発生をプレゼンス文書に含まれています。 <発生-ID>許可をウォッチャに付与され、デバイスの発生<発生-ID>は、大文字と小文字を区別し平等に基づいて<発生-ID>許可の値と一致する場合、デバイスの発生が中に含まれている場合プレゼンス文書。 <全デバイス>許可をウォッチャに付与された場合に加えて、デバイスの発生は、プレゼンス文書に含まれています。
The <provide-persons> permission allows a watcher to see the <person> information present in the presence document. It is a set variable. Each member of the set provides a way to identify a person occurrence. This specification defines two types of elements in the set - <class>, which identifies a person occurrence by class, and <occurrence-id>, which identifies an occurrence by its occurrence ID. Each member of the set is identified by its type (class or occurrence-id) and value (value of the class or value of the occurrence-id). The <provide-persons> element can also take on the special value <all-persons>, which is a short-hand notation for all person occurrences present in the presence document. The set combination is done identically to the <provide-devices> element.
<提供-者>許可はウォッチャーがプレゼンス文書に存在する<人>の情報を見ることができます。これは、設定された変数です。セットの各メンバーは、人の発生を識別するための方法を提供します。クラスによって人物の発生を識別し、<クラス>、および<発生-ID>、その発生IDによって発生を識別する - この仕様は、セット内の要素の二つのタイプを定義します。セットの各メンバーは、そのタイプ（クラスまたは発生-ID）と値（発生-IDのクラスまたは値の値）によって識別されます。 <提供-者>要素は、プレゼンス文書に存在するすべての人の発生のためのショートハンド表記である特別な値<全者>、をとることができます。セットの組み合わせは、<提供-デバイス>要素と同一に行われます。
Permission is granted to see a particular person occurrence if one of the person identifiers in the set identifies that person occurrence. If a <class> permission is granted to the watcher, and the <class> of the person occurrence matches the value of the <class> permission based on case-sensitive equality, the person occurrence is included in the presence document. If an <occurrence-id> permission is granted to the watcher, and the <occurrence-id> of the person occurrence matches the value of the <occurrence-id> permission based on case-sensitive equality, the person occurrence is included in the presence document. In addition, a person occurrence is included in the presence document if the <all-persons> permission was granted to the watcher.
許可がセット者識別子の一つは、その人の発生を識別する場合、特定の人物の出現を確認するために付与されます。 <クラス>許可がウォッチャーに付与され、そして人の発生の<クラス>は、大文字と小文字を区別平等に基づいて、<クラス>パーミッションの値と一致した場合、人の発生が存在文書に含まれています。 <発生-ID>許可をウォッチャに付与され、人の発生<発生-ID>は、大文字と小文字を区別し平等に基づいて<発生-ID>許可の値と一致する、人の発生が中に含まれている場合プレゼンス文書。 <すべての者>許可がウォッチャに付与された場合に加えて、人の発生が存在文書に含まれています。
The <provide-services> permission allows a watcher to see service information present in <tuple> elements in the presence document. Like <provide-devices>, it is a set variable. Each member of the set provides a way to identify a service occurrence. This specification defines four types of elements in the set - <class>, which identifies a service occurrence by class; <occurrence-id>, which identifies a service by its occurrence ID; <service-uri>, which identifies a service by its service URI; and <service-uri-scheme>, which identifies a service by its service URI scheme. Each member of the set is identified by its type (class, occurrence-id, service-uri, or service-uri-scheme) and value (value of the class, value of the occurrence-id, value of the service-uri, or value of the service-uri-scheme). The <provide-services> element can also take on the special value <all-services>, which is a short-hand notation for all service occurrences present in the presence document. The set combination is done identically to the <provide-persons> element.
<-サービスを提供>許可がウォッチャーは、プレゼンス文書内の<タプル>要素に存在するサービスの情報を見ることができます。 <提供-デバイス>のように、それは、設定された変数です。セットの各メンバーは、サービス発生を識別するための方法を提供します。この仕様は、セット内の要素の4種類の定義 - <クラス>、クラスによってサービス発生を識別する。 <発生-ID>、その発生IDによってサービスを識別する。 <サービスURI>、そのサービスURIによるサービスを識別する。そして、<サービス-URI-スキーム>、そのサービスURIスキームによってサービスを識別する。セットの各メンバーは、その種類（クラス、発生-ID、サービスURI、又はサービスURI-方式）と値（階級の値、発生-IDの値は、サービスURIの値によって識別され、またはサービス-URI-スキームの値）。 <提供-サービス>要素は、プレゼンス文書内に存在するすべてのサービス発生のためのショートハンド表記である特別な値<全サービス>、をとることができます。セットの組み合わせは、<提供-者>要素と同一に行われます。
Permission is granted to see a particular service occurrence if one of the service identifiers in the set identifies that service occurrence. If a <class> permission is granted to the watcher, and the <class> of the service occurrence matches the value of the <class> permission based on case-sensitive equality, the service occurrence is included in the presence document. If a <service-uri> permission is granted to the watcher, and the <service-uri> of the service occurrence matches the value of the <service-uri> permission based on URI equivalence, the service occurrence is included in the presence document. If an <occurrence-id> permission is granted to the watcher, and the <occurrence-id> of the service occurrence matches the value of the <occurrence-id> permission based on case- sensitive equality, the service occurrence is included in the presence document. If a <service-uri-scheme> permission is granted to the watcher, and the scheme of the service URI for the service occurrence matches the value of <service-uri-scheme> based on case-sensitive equality, the service occurrence is included in the presence document. In addition, a service occurrence is included in the presence document if the <all-services> permission was granted to the watcher.
許可は、セット内のサービス識別子の一つは、そのサービスの発生を識別する場合、特定のサービスの発生を見ることが許可されます。 <クラス>許可がウォッチャーに付与され、そしてサービス発生の<クラス>は、大文字と小文字を区別平等に基づいて、<クラス>パーミッションの値と一致している場合は、サービスの発生が存在文書に含まれています。 <サービス-URI>許可がウォッチャーに付与され、そして<サービス-URI>サービス発生のURIの等価性に基づいて、<サービス-URI>パーミッションの値と一致した場合、サービスの発生が存在文書に含まれています。 <発生-id>の許可がウォッチャーに付与され、そしてサービス発生の<発生-id>は、<発生-id>の許可の値と一致している場合は大文字と小文字を区別平等に基づいて、サービスの発生が含まれていますプレゼンス文書。 <サービス-URI-スキーム>許可がウォッチャーに付与され、サービスの発生のためのサービスURIのスキームでは、大文字と小文字が区別平等に基づいて、<サービス-URI-スキーム>の値と一致している場合は、サービスの発生が含まれていますプレゼンス文書インチ<すべてのサービス>許可がウォッチャに付与された場合に加えて、サービスの発生が存在文書に含まれています。
The permissions of Section 3.3.1 provide coarse-grained access to presence data by allowing or blocking specific services or devices, and allowing or blocking person information.
3.3.1の権限は、特定のサービスやデバイスを許可またはブロックすることにより、プレゼンスデータへの粗粒度のアクセスを提供し、人物情報を許可または遮断します。
Once person, device, or service information is included in the document, the permissions in this section define which presence attributes are reported there. Certain information is always reported. In particular, the <contact>, <service-class> [9], <basic> status, and <timestamp> elements in all <tuple> elements, if present, are provided to watchers. The <timestamp> element in all <person> elements, if present, is provided to watchers. The <timestamp> and <deviceID> elements in all <device> elements, if present, are provided to all watchers.
人物、デバイス、またはサービスの情報が文書に含まれると、このセクションの権限は、属性がそこに報告されている存在を定義します。特定の情報は常に報告されます。特に、<接点>、<サービスクラス> [9]、<基本>ステータス、およびすべての<タプル>要素内の<タイムスタンプ>要素は、存在する場合、ウォッチャに提供されます。 <タイムスタンプ>全ての<人>要素内の要素は、存在する場合、ウォッチャに提供されます。 <タイムスタンプ>およびすべての<デバイス>要素内の<deviceIDの>要素は、存在する場合、全てのウォッチャに提供されます。
This permission controls access to the <activities> element defined in [9]. The name of the element providing this permission is <provide-activities>, and it is a Boolean type. If its value is TRUE, then the <activities> element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
この許可は、[9]で定義された<活動>要素へのアクセスを制御します。この権限を提供する要素の名前は<-活動を提供>であり、それはブール型です。その値がTRUEの場合、人のデータ要素内の<活動>要素は、ウォッチャに報告されます。 FALSEの場合、このプレゼンス属性が存在すれば削除されます。
This permission controls access to the <class> element defined in [9]. The name of the element providing this permission is <provide-class>, and it is a Boolean type. If its value is TRUE, then any <class> element in a person, service, or device data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
この許可は、[9]で定義された<class>要素へのアクセスを制御します。この権限を提供する要素の名前は、<提供クラス>であり、それはブール型です。その値がTRUEの場合、人、サービス、またはデバイスのデータ要素内の任意の<class>要素は、ウォッチャに報告されます。 FALSEの場合、このプレゼンス属性が存在すれば削除されます。
This permission controls access to the <deviceID> element in a <tuple> element, as defined in [9]. The name of the element providing this permission is <provide-deviceID>, and it is a Boolean type. If its value is TRUE, then the <deviceID> element in the service data element is reported to the watcher. If FALSE, this presence attribute is removed if present. Note that the <deviceID> in a device data element is always included, and not controlled by this permission.
[9]で定義されるように、この権限は、<タプル>要素内の<deviceIDの>要素へのアクセスを制御します。この権限を提供する要素の名前は<提供-のdeviceID>であり、それはブール型です。その値がTRUEの場合、サービスデータ要素内の<deviceIDの>要素は、ウォッチャに報告されます。 FALSEの場合、このプレゼンス属性が存在すれば削除されます。 <deviceIDの>デバイスのデータ要素で常に含まれており、この権限によって制御されていないことに注意してください。
This permission controls access to the <mood> element defined in [9]. The name of the element providing this permission is <provide-mood>, and it is a Boolean type. If its value is TRUE, then the <mood> element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
この許可は、[9]で定義された<ムード>要素へのアクセスを制御します。この権限を提供する要素の名前は<提供-気分>であり、それはブール型です。その値がTRUEの場合、人のデータ要素内の<ムード>要素は、ウォッチャに報告されます。 FALSEの場合、このプレゼンス属性が存在すれば削除されます。
This permission controls access to the <place-is> element defined in [9]. The name of the element providing this permission is <provide-place-is>, and it is a Boolean type. If its value is TRUE, then the <place-is> element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
この許可は、[9]で定義された<場所-です>要素へのアクセスを制御します。この権限を提供する要素の名前は<提供--ある場所>であり、それはブール型です。その値がTRUEの場合、人のデータ要素内の<場所-です>要素は、ウォッチャに報告されます。 FALSEの場合、このプレゼンス属性が存在すれば削除されます。
This permission controls access to the <place-type> element defined in [9]. The name of the element providing this permission is <provide-place-type>, and it is a Boolean type. If its value is TRUE, then the <place-type> element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
この許可は、[9]で定義された<場所-type>要素へのアクセスを制御します。この権限を提供する要素の名前は<インプレース型を提供>であり、それはブール型です。その値がTRUEの場合、人のデータ要素における<場所-type>要素は、ウォッチャに報告されます。 FALSEの場合、このプレゼンス属性が存在すれば削除されます。
This permission controls access to the <privacy> element defined in [9]. The name of the element providing this permission is <provide-privacy>, and it is a Boolean type. If its value is TRUE, then the <privacy> element in the person or service data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
この許可は、[9]で定義された<プライバシー>要素へのアクセスを制御します。この権限を提供する要素の名前は<提供-プライバシー>であり、それはブール型です。その値がTRUEの場合、人やサービスのデータ要素内の<プライバシー>要素は、ウォッチャに報告されます。 FALSEの場合、このプレゼンス属性が存在すれば削除されます。
This permission controls access to the <relationship> element defined in [9]. The name of the element providing this permission is <provide-relationship>, and it is a Boolean type. If its value is TRUE, then the <relationship> element in the service data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
この許可は、[9]で定義された<関係>要素へのアクセスを制御します。この権限を提供する要素の名前は<提供-関係>であり、それはブール型です。その値がTRUEの場合、サービスデータ要素内の<関係>要素は、ウォッチャに報告されます。 FALSEの場合、このプレゼンス属性が存在すれば削除されます。
This permission controls access to the <sphere> element defined in [9]. The name of the element providing this permission is <provide-sphere>, and it is a Boolean type. If its value is TRUE, then the <sphere> element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
この許可は、[9]で定義された<球>要素へのアクセスを制御します。この権限を提供する要素の名前は<提供-球>であり、それはブール型です。その値がTRUEの場合、人のデータ要素内の<球>要素は、ウォッチャに報告されます。 FALSEの場合、このプレゼンス属性が存在すれば削除されます。
This permission controls access to the <status-icon> element defined in [9]. The name of the element providing this permission is <provide-status-icon>, and it is a Boolean type. If its value is TRUE, then any <status-icon> element in the person or service data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
この権限は、[9]で定義された<ステータスアイコン>要素へのアクセスを制御します。この権限を提供する要素の名前は<提供-ステータスアイコン>であり、それはブール型です。その値がTRUEの場合、人やサービスのデータ要素のいずれかの<ステータスアイコン>要素は、ウォッチャに報告されます。 FALSEの場合、このプレゼンス属性が存在すれば削除されます。
This permission controls access to the <time-offset> element defined in [9]. The name of the element providing this permission is <provide-time-offset>, and it is a Boolean type. If its value is TRUE, then the <time-offset> element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
この権限は、[9]で定義された<時間オフセット>要素へのアクセスを制御します。この権限を提供する要素の名前は<提供-時間オフセット>であり、それはブール型です。その値がTRUEの場合、人のデータ要素内の<時間オフセット>要素は、ウォッチャに報告されます。 FALSEの場合、このプレゼンス属性が存在すれば削除されます。
This permission controls access to the <user-input> element defined in [9]. The name of the element providing this permission is <provide-user-input>, and it is an enumerated integer type. Its value defines what information is provided to watchers in person, device, or service data elements:
この権限は、[9]で定義された<ユーザ入力>要素へのアクセスを制御します。この権限を与える要素の名前は、<与えるユーザ入力を>であり、列挙された整数型です。その値は情報が人物、デバイス、またはサービスデータ要素におけるウォッチャに提供されるものを定義します。
false: This value indicates that the <user-input> element is removed from the document. It is assigned the numeric value of 0.
偽：この値は、<ユーザ入力>要素が文書から除去されることを示しています。これは、0の数値が割り当てられます。
bare: This value indicates that the <user-input> element is to be retained. However, any "idle-threshold" and "since" attributes are to be removed. This value is assigned the numeric value of 10.
裸：この値は、<ユーザ入力>要素が保持されることを示します。しかし、いずれの属性が削除される「ので、」「しきい値をアイドル」と。この値は、10の数値が割り当てられます。
thresholds: This value indicates that the <user-input> element is to be retained. However, only the "idle-threshold" attribute is to be retained. This value is assigned the numeric value of 20.
しきい値：この値は、<ユーザ入力>要素が保持されることを示します。しかし、唯一の「アイドルしきい値」属性は保持されます。この値は、20の数値が割り当てられます。
full: This value indicates that the <user-input> element is to be retained, including any attributes. This value is assigned the numeric value of 30.
フル：この値は、<ユーザ入力>要素は、任意の属性を含む、保持されるべきであることを示しています。この値は、30の数値が割り当てられます。
This permission controls access to the <note> element defined in [3] for <tuple> and [10] for <person> and <device>. The name of the element providing this permission is <provide-note>, and it is a Boolean type. If its value is TRUE, then any <note> elements in the person, service, or device data elements are reported to the watcher. If FALSE, this presence attribute is removed if present.
この許可は<者>と<デバイス>のための<タプル>及び[10] [3]で定義された<注意>要素へのアクセスを制御します。この権限を提供する要素の名前は<提供ノート>であり、それはブール型です。その値がTRUEの場合、任意の<注意>人、サービス、またはデバイスのデータ要素内の要素は、ウォッチャに報告されています。 FALSEの場合、このプレゼンス属性が存在すれば削除されます。
This permission has no bearing on any <note> values present within <activities>, <mood>, <place-is>, <place-type>, <privacy>, <relationship>, or <service-class> elements. Notes within these elements are essentially values for their respective elements, and are present if the respective element is permitted in the presence document. For example, if an <activities> element is present in a presence document, and there is a <note> value for it, that note is present in the document sent to the watcher if the <provide-activities> permission is given, regardless of whether the <provide-note> permission is given.
この許可は、任意の<活動>、<ムード>内に存在する<ノート>値は、<場所-である>、<場所型>、<プライバシー>、<関係>、または<サービスクラス>要素とは関係ありません。これらの要素内のノートは、基本的に、それぞれの要素の値、およびそれぞれの要素は、プレゼンス文書に許可されている場合に存在します。 <活動>要素は、プレゼンス文書中に存在し、そしてそれのための<注意>値が存在する場合、例えば、そのノートは、<提供-活動>場合ウォッチャに送信された文書に存在するアクセス許可にかかわらず、与えられ<提供-ノート>許可が与えられているかどうかの。
It is important that systems be allowed to include proprietary or new presence information and that users be able to set permissions for that information, without requiring an upgrade of the presence server and authorization system. For this reason, the <provide-unknown-attribute> permission is defined. This permission indicates that the unknown presence attribute with the given name and namespace (supplied as mandatory attributes of the <provide-unknown-attribute> element) should be included in the document. Its type is Boolean.
システムが独自たり、新しいプレゼンス情報を含めると、ユーザーがプレゼンスサーバと認証システムのアップグレードを必要とせずに、その情報の権限を設定することができることを許可することが重要です。このため、<提供-不明な属性>許可が定義されます。この許可は与えられた名前と名前空間を持つ未知の存在属性は、文書に含まれるべきである（<提供-不明な属性>要素の必須属性として供給されている）ことを示しています。そのタイプはブールです。
The value of the name attribute MUST be an unqualified element name (meaning that a namespace prefix MUST NOT be included), and the value of the ns attribute MUST be a namespace URI. The two are combined to form a qualified element name, which will be matched to all unknown child elements of the Presence Information Data Format (PIDF) <tuple>, <device>, or <person> elements with the same qualified name. In this context, "unknown" means that the presence server is not aware of any schemas that define authorization policies for that element. By definition, this will exclude the <provide-unknown-attribute> rule from being applied to any of the presence status extensions defined by RPID, since authorization policies for those are defined here.
name属性の値は、（名前空間接頭辞が含まれてはならないことを意味する）修飾されていない要素名でなければならない、とNS属性の値は、名前空間URIでなければなりません。 2は、プレゼンス情報データフォーマット（PIDF）<タプル>、<デバイス>、または<人>同じ修飾名を持つすべての要素未知の子要素にマッチします修飾要素名を、形成するために結合されています。この文脈では、「未知のは、」プレゼンス・サーバは、その要素の認可ポリシーを定義したスキーマを認識していないことを意味します。定義によると、これはそれらのための認可ポリシーをここで定義されているので、RPIDによって定義されたプレゼンスステータスの拡張子のいずれにも適用されることから、<提供-不明な属性>ルールを除外します。
Another consequence of this definition is that the interpretation of the <provide-unknown-attribute> element can change should the presence server be upgraded. For example, consider a server that, prior to the upgrade, had an authorization document that used <provide-unknown-attribute> with a value of TRUE for some attribute, say foo. This attribute was from a namespace and schema unknown to the server, and so the attribute was provided to watchers. However, after upgrade, the server is now aware of a new namespace and schema for a permission that grants access to the foo attribute. Now, the <provide-unknown-attribute> permission for the foo attribute will be ignored, resulting in a removal of those elements from presence documents sent to watchers. The system remains privacy safe, but behavior might not be as expected. Developers of systems that allow clients to set policies are advised to check the capabilities of the server (using the mechanism described in Section 8) before uploading a new authorization document, to make sure that the behavior will be as expected.
この定義の他の結果は、<提供-不明な属性>要素の解釈は、プレゼンスサーバをアップグレードする必要が変更することができるということです。例えば、いくつかの属性にTRUEの値と、アップグレード前に、<提供未知の属性>を使用する許可文書を持っていたサーバーを検討し、FOOを言います。この属性は、サーバーへの名前空間とスキーマ不明からだったので、属性がウォッチャーに提供されました。ただし、アップグレード後、サーバーは現在のfoo属性へのアクセスを許可する許可のための新しい名前空間とスキーマを認識しています。さて、<提供-不明な属性> fooの属性の権限をウォッチャーに送信されたプレゼンス文書からこれらの要素の除去が得られ、無視されます。システムは、プライバシー、安全なままですが、期待通りに動作がないかもしれません。クライアントがポリシーを設定できるようにするシステムの開発が期待通りに動作が可能になることを確認するために、新しい認証文書をアップロードする前に、（セクション8に記載のメカニズムを使用して）サーバの機能を確認することをお勧めします。
This permission grants access to all presence attributes in all of the person, device, and tuple elements that are present in the document (the ones present in the document are determined by the <provide-persons>, <provide-devices>, and <provide-services> permissions). It is effectively a macro that expands into a set of provide-activities, provide-class, provide-deviceID, provide-mood, provide-place-is, provide-place-type, provide-privacy, provide-relationship, provide-sphere, provide-status-icon, provide-time-offset, provide-user-input, provide-note, and provide-unknown-attribute permissions such that each presence attribute in the document has a permission for it. This implies that, so long as an entire person, service, or device occurrence is provided, every single presence attribute, including ones not known to the server and/or defined in future presence document extensions, is granted to the watcher.
これは、すべての存在へのアクセスを許可するには、人、機器、およびドキュメントに存在しているタプルの要素のすべての属性（文書内に存在するものは、<提供-者>によって決定されている権限、<提供-デバイス>、および< >権限） - サービスを提供しています。それが効果的に提供し、活動のセットに展開されるマクロで、提供クラスを提供-のdeviceIDを提供-気分を、提供-ある場所を、提供-球を、提供-関係を、提供-プライバシーを、インプレース型を提供提供-時間オフセット、提供 - ユーザ入力、提供、ノート、ステータス・アイコン・提供、および提供-未知の属性の権限を文書内の各プレゼンス属性は、そのための権限を持っているように。これは、限り提供され、全人、サービス、またはデバイスの発生として、サーバーに知られている、および/または将来のプレゼンス文書の拡張子で定義されていないものも含め、すべての単一のプレゼンス属性は、ウォッチャーに付与される、ということを意味します。
This specification does not mandate at what point in the processing of presence data the privacy filtering aspects of the authorization policy are applied. However, they must be applied such that the final presence document sent to the watcher is compliant to the privacy policy described in the authorization documents that apply to the user (there can be more than one; the rules for combining them are described in [8]). More concretely, if the presence document sent to a watcher is D, and the privacy filtering operation applied do a presence document x is F(x), then D MUST have the property that D = F(D). In other words, further applications of the privacy filtering operation would not result in any further changes of the presence document, making further application of the filtering operation a no-op. A corollary of this is that F(F(D)) = D for all D.
この仕様は、承認ポリシーの側面をフィルタリングし、プライバシーが適用されるプレゼンスデータの処理にどの時点で強制しません。しかし、彼らはウォッチャに送信され、最終的なプレゼンス文書は（複数存在することができ、ユーザに適用する承認文書に記載のプライバシーポリシーに準拠しているように適用されなければならない。それらを組み合わせるためのルールはで説明されている[8 ]）。ウォッチャに送信されたプレゼンス文書はDであり、そしてプライバシーフィルタリング動作が適用された場合、より具体的には、プレゼンス文書XがFであるか（X）、次いでDは、D = F（D）の特性を持たなければなりません。換言すれば、プライバシーフィルタリング操作のさらなる用途は、フィルタリング動作ノー・オペレーションのさらなる応用を行う、プレゼンス文書の任意のさらなる変化をもたらさないであろう。これの当然の結果は、全てのDのF（F（D））= D
The subscription processing aspects of the document get applied by the server when it decides to accept or reject the subscription.
それはサブスクリプションを受け入れるか拒否することを決定したときに、文書のサブスクリプション処理の側面は、サーバによって適用されます。
The rules defined by the document in this specification form a "contract" of sorts between a client that creates this document and the server that executes the policies it contains. Consequently, presence servers implementing this specification MUST support all of the conditions, actions, and transformations defined in this specification. If servers were to implement a subset of these, clients would need a mechanism to discover which subset is supported. No such mechanism is defined.
この仕様で文書で定義されたルールは、このドキュメントとそれに含まれるポリシーを実行するサーバを作成し、クライアントの間で一種の「契約」を形成します。したがって、この仕様を実装するプレゼンス・サーバは、この仕様で定義された条件、アクション、および変換のすべてをサポートしなければなりません。サーバはこれらのサブセットを実装した場合、クライアントはサポートされているサブセットを発見するためのメカニズムが必要になります。そのようなメカニズムが定義されていません。
It is RECOMMENDED that clients support all of the actions, transformations, and conditions defined in this specification. If a client supports a subset, it is possible that a user might manipulate their authorization rules from a different client, supporting a different subset, and store those results on the server. When the user goes back to the first client and views their presence authorization rules there, the client may not be able to properly render or manipulate the document retrieved from the server, since it may contain conditions, actions, or transformations not supported by the client. The only reason that this normative requirement is not a MUST is that there are valid conditions in which a user manipulates their presence authorization rules from a single client, in which case this problem does not occur.
クライアントがこの仕様で定義されたアクション、変換、および条件のすべてをサポートすることが推奨されます。クライアントはサブセットをサポートしている場合、ユーザーが別のサブセットをサポートし、さまざまなクライアントから自分の認可規則を操作して、サーバー上でこれらの結果を格納するかもしれないという可能性です。ユーザーが最初にクライアントに戻り、そこに自分の存在の承認規則を表示すると、それは、クライアントでサポートされていない条件、アクション、または変換を含むことがあるため、クライアントは、適切にサーバから取得した文書をレンダリングしたり操作することができないかもしれません。この規範的要件はMUSTではない唯一の理由は、ユーザは、この問題が発生しない場合には、単一のクライアントから、自分の存在の承認規則を操作する有効な条件があるということです。
This specification makes no normative recommendations on the mechanism used to transport presence authorization documents from clients to their servers. Although Section 9 defines how to utilize XCAP, XCAP is not normatively required by this specification.
この仕様は、そのサーバーへのクライアントからのプレゼンス認可文書を輸送するために使用されるメカニズムには規範的な提言を行うものではありません。セクション9は、XCAPを使用する方法を定義しているが、XCAPは、規範的この仕様によって必要とされません。
The following presence authorization document specifies permissions for the user "user@example.com". The watcher is allowed to access presence information (the 'allow' value for <sub-handling>). They will be granted access to the presence data of all services whose contact URI schemes are sip and mailto. Person information is also provided. However, since there is no <provide-devices>, no device information will be given to the watcher. Within the service and person information provided to the watcher, the <activities> element will be shown, as will the <user-input> element. However, any "idle-threshold" and "since" attributes in the <user-input> element will be removed. Finally, the presence attribute <foo> will be shown to the watcher. Any other presence attributes will be removed.
次プレゼンス認可文書は「user@example.com」のユーザーの権限を指定します。ウォッチャーは、プレゼンス情報（<サブハンドリング>ための「許可」の値）へのアクセスを許可されています。彼らは、接触URIスキーム一口であり、mailtoの全てのサービスが存在するデータへのアクセス権が付与されます。人物情報も提供されます。何<提供-デバイス>が存在しないので、何のデバイス情報をウォッチャに与えられません。 <ユーザ入力>要素はれるようウォッチャに提供されるサービスと個人情報の中に、<活動>要素は、表示されます。 <ユーザ入力>に属性「ので、」しかし、任意の「アイドル閾値」と要素が除去されます。最後に、プレゼンス属性は、<foo>のウォッチャに表示されます。その他のプレゼンス属性が削除されます。
<?xml version="1.0" encoding="UTF-8"?> <cr:ruleset xmlns="urn:ietf:params:xml:ns:pres-rules" xmlns:pr="urn:ietf:params:xml:ns:pres-rules" xmlns:cr="urn:ietf:params:xml:ns:common-policy"> <cr:rule id="a"> <cr:conditions> <cr:identity> <cr:one id="sip:user@example.com"/> </cr:identity> </cr:conditions> <cr:actions> <pr:sub-handling>allow</pr:sub-handling> </cr:actions> <cr:transformations> <pr:provide-services> <pr:service-uri-scheme>sip</pr:service-uri-scheme> <pr:service-uri-scheme>mailto</pr:service-uri-scheme> </pr:provide-services> <pr:provide-persons> <pr:all-persons/> </pr:provide-persons> <pr:provide-activities>true</pr:provide-activities> <pr:provide-user-input>bare</pr:provide-user-input> <pr:provide-unknown-attribute ns="urn:vendor-specific:foo-namespace" name="foo">true</pr:provide-unknown-attribute> </cr:transformations> </cr:rule> </cr:ruleset>
<？xml version = "1.0" エンコード= "UTF-8"？> <CR：ルールセットのxmlns = "URN：IETF：paramsは：XML：NS：PRES-ルール" のxmlns：PR = "URN：IETF：paramsは：XML ：NS：PRES-ルール」のxmlns：CR = "URN：IETF：paramsは：XML：NS：共通ポリシー"> <CR：ルールID = ""> <CR：条件> <CR：アイデンティティ> <CR。 1つのID = "SIP：user@example.com" /> </ CR：アイデンティティ> </ CR：条件> <CR：アクション> <PR：サブハンドリング> </ PR可能：サブハンドリング> </ CR ：アクション> <CR：変換> <PR：提供-サービス> <PR：サービス-URI-スキーム>一口</ PR：サービス-URI-スキーム> <PR：サービス-URI-スキーム>のmailto </ PR：サービス-uri-スキーム> </ PR：提供-サービス> <PR：提供-者> <PR：すべて-人/> </ PR：提供-者> <PR：提供-活動>真</ PR：provide-活動> <PR：提供-ユーザ入力>裸</ PR：提供-ユーザ入力を> <PR：提供-未知の属性NS = "壷：ベンダー固有：FOO-名前空間" 名前= "foo" という>真</ PR：提供-不明な属性> </ CR：変換> </ CR：ルール> </ CR：ルールセット>
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:pres-rules" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:cr="urn:ietf:params:xml:ns:common-policy" xmlns:pr="urn:ietf:params:xml:ns:pres-rules" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:import namespace="urn:ietf:params:xml:ns:common-policy"/> <xs:simpleType name="booleanPermission"> <xs:restriction base="xs:boolean"/> </xs:simpleType> <xs:element name="service-uri-scheme" type="xs:token"/> <xs:element name="class" type="xs:token"/> <xs:element name="occurrence-id" type="xs:token"/> <xs:element name="service-uri" type="xs:anyURI"/> <xs:complexType name="provideServicePermission"> <xs:choice> <xs:element name="all-services"> <xs:complexType/> </xs:element> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:choice> <xs:element ref="pr:service-uri"/> <xs:element ref="pr:service-uri-scheme"/> <xs:element ref="pr:occurrence-id"/> <xs:element ref="pr:class"/> <xs:any namespace="##other" processContents="lax"/> </xs:choice> </xs:sequence> </xs:choice> </xs:complexType> <xs:element name="provide-services" type="pr:provideServicePermission"/> <xs:element name="deviceID" type="xs:anyURI"/> <xs:complexType name="provideDevicePermission"> <xs:choice> <xs:element name="all-devices"> <xs:complexType/> </xs:element> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:choice> <xs:element ref="pr:deviceID"/> <xs:element ref="pr:occurrence-id"/> <xs:element ref="pr:class"/> <xs:any namespace="##other" processContents="lax"/> </xs:choice> </xs:sequence>
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：PRES-ルール" のxmlns：XSの=の "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ」のxmlns：CR = "URN：IETF：paramsは：XML：NS：共通のポリシー" のxmlns：PR = "URN：IETF：paramsは：XML：NS：PRES-ルール" のelementFormDefault = "修飾" attributeFormDefault = "非修飾"> <XS：インポートの名前空間= "壷：IETF：のparams：XML：NS：共通ポリシー" /> <XS：単純型名= "booleanPermission"> <XS：制限ベース= "XS：ブール" /> </ XS：単純> <XS：要素名= "サービス-URI-スキーム" タイプ= "XS：トークン" /> <XS：要素名= "クラス" タイプ= "XS：トークン" /> <XS ：要素名= "発生-ID" タイプ= "XS：トークン" /> <XS：要素名= "サービスURI" TYPE = "XS：anyURIの" /> <XS：complexTypeの名= "provideServicePermission"> <XS ：選択> <XS：要素名= "すべてのサービス"> <XS：complexTypeの/> </ XS：要素> <XS：シーケンスのminOccurs = "0" のmaxOccurs = "無制限"> <XS：選択> <XS：要素REF = "PR：サービスURI" /> <XS：要素REF = "PR：サービスURI-スキーム" /> <XS：要素REF = "PR：発生-ID" /> <XS：要素REF = "PR：クラス" /> <XS：任意の名前空間= "##他" のprocessContents = "緩い" /> </ XS：選択> </ XS：シーケンス> </ XS：選択> </ XS：complexTypeの> <XS：要素名= "-サービスを提供する" タイプ= "PR：provideServicePermission" /> <XS：要素名= "deviceIDの" タイプ= "XS：anyURIの" /> <XS：complexTypeの名= "provideDevicePermission"> <XS：選択> <XS：要素名= "オールデバイス "> <XS：complexTypeの/> </ XS：要素> <XS：シーケンスのminOccurs =" 0" のmaxOccurs = "無制限"> <XS：選択> <XS：要素REF = "PR：deviceIDの" /> <XS ：要素REF = "PR：発生-ID" /> <XS：要素REF = "PR：クラス" /> <XS：任意の名前空間= "##その他" のprocessContents = "緩い" /> </ XS：選択> </ XS：シーケンス>
</xs:choice> </xs:complexType> <xs:element name="provide-devices" type="pr:provideDevicePermission"/> <xs:complexType name="providePersonPermission"> <xs:choice> <xs:element name="all-persons"> <xs:complexType/> </xs:element> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:choice> <xs:element ref="pr:occurrence-id"/> <xs:element ref="pr:class"/> <xs:any namespace="##other" processContents="lax"/> </xs:choice> </xs:sequence> </xs:choice> </xs:complexType> <xs:element name="provide-persons" type="pr:providePersonPermission"/> <xs:element name="provide-activities" type="pr:booleanPermission"/> <xs:element name="provide-class" type="pr:booleanPermission"/> <xs:element name="provide-deviceID" type="pr:booleanPermission"/> <xs:element name="provide-mood" type="pr:booleanPermission"/> <xs:element name="provide-place-is" type="pr:booleanPermission"/> <xs:element name="provide-place-type" type="pr:booleanPermission"/> <xs:element name="provide-privacy" type="pr:booleanPermission"/> <xs:element name="provide-relationship" type="pr:booleanPermission"/> <xs:element name="provide-status-icon" type="pr:booleanPermission"/> <xs:element name="provide-sphere" type="pr:booleanPermission"/> <xs:element name="provide-time-offset" type="pr:booleanPermission"/> <xs:element name="provide-user-input"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="false"/> <xs:enumeration value="bare"/> <xs:enumeration value="thresholds"/>
</ XS：選択> </ XS：complexTypeの> <XS：要素名=タイプ= "-デバイスを提供" "PR：provideDevicePermission" /> <XS：complexTypeの名= "providePersonPermissionを"> <XS：選択> <XS：要素名= "すべての者"> <XS：complexTypeの/> </ XS：要素> <XS：シーケンスのminOccurs = "0" のmaxOccurs = "無制限"> <XS：選択> <XS：要素REF = "PR：発生-ID "/> <XS：要素REF =" PR：クラス "/> <XS：任意の名前空間=" ##他」のprocessContents = "緩い" /> </ XS：選択> </ XS：シーケンス> < / XS：選択> </ XS：complexTypeの> <XS：要素名= "を提供-人" タイプは、= "PR：providePersonPermission" /> <XS：要素名= "提供-活動" タイプ= "PR：booleanPermission" / > <XS：要素名= "提供クラス" TYPE = "PR：booleanPermission" /> <XS：要素名= "提供-のdeviceIDを" TYPE = "PR：booleanPermission" /> <XS：要素名= "provide-気分 "タイプ= "PR：booleanPermission"/> <XS：要素名= "提供-場所-である" タイプ= "PR：booleanPermissionを"/> <XS：要素名= "を提供するインプレース型の" タイプ=" PR ：booleanPermission "/> <XS：要素名=" を提供 - プライバシー」タイプ= "PR：booleanPermission" /> <XS：エルement名= "提供関係" タイプ= "PR：booleanPermission" /> <XS：要素名= "提供ステータスアイコン" タイプ= "PR：booleanPermission" /> <XS：要素名= "提供球"タイプ= "PR：booleanPermission" /> <XS：要素名= "提供時間オフセットを" TYPE = "PR：booleanPermission" /> <XS：要素名= "与えるユーザ入力"> <XS：simpleTypeの> <XS：制限ベース= "XS：文字列"> <XS：列挙値= "偽" /> <XS：列挙値= "裸の" /> <XS：列挙値= "しきい値" />
<xs:enumeration value="full"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="provide-note" type="pr:booleanPermission"/> <xs:element name="sub-handling"> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="block"/> <xs:enumeration value="confirm"/> <xs:enumeration value="polite-block"/> <xs:enumeration value="allow"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:complexType name="unknownBooleanPermission"> <xs:simpleContent> <xs:extension base="pr:booleanPermission"> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="ns" type="xs:string" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:element name="provide-unknown-attribute" type="pr:unknownBooleanPermission"/> <xs:element name="provide-all-attributes"> <xs:complexType/> </xs:element> </xs:schema>
<XS：列挙値= "フル" /> </ XS：制限> </ XS：単純> </ XS：要素> <XS：要素名= "提供ノートを" タイプ= "PR：booleanPermission" /> < XS：要素名= "サブハンドリング"> <XS：単純> <XS：制限ベース= "XS：トークン"> <XS：列挙値= "ブロック" /> <XS：列挙値= "確認" /> <XS：列挙値= "丁寧ブロック" /> <XS：列挙値= "許可" /> </ XS：制限> </ XS：単純> </ XS：要素> <XS：complexTypeの名= "unknownBooleanPermission "> <XS：simpleContentを> <XS：拡張ベース=" PR：booleanPermission "> <XS：属性名=" 名前 "タイプ= "XS：文字列" 使用= "必須"/> <XS：属性名=" NS "タイプ=" XS：文字列 "使用= "必要"/> </ XS：拡張> </ XS：simpleContentを> </ XS：complexTypeの> <XS：要素名= "を提供 - 未知の属性" タイプ=" PR ：unknownBooleanPermission "/> <XS：要素名=" を提供 - すべての属性 "> <XS：complexTypeの/> </ XS：要素> </ XS：スキーマ>
It is anticipated that future changes to this specification are accomplished through extensions that define new types of permissions. These extensions MUST exist within a different namespace. Furthermore, the schema defined above and the namespace for elements defined within it MUST NOT be altered by future specifications. Changes in the basic schema, or in the interpretation of elements within that schema, may result in violations of user privacy due to misinterpretation of documents.
この仕様書の将来の変更は、権限の新しいタイプを定義拡張子によって達成されることが予想されます。これらの拡張機能は、異なる名前空間に存在しなければなりません。さらに、上記で定義されたスキーマとその中に定義された要素の名前空間は、将来の仕様によって変更してはいけません。基本的なスキーマ内、またはそのスキーマ内の要素の解釈の変化は、原因文書の誤った解釈にユーザーのプライバシーの侵害になることがあります。
When extensions are made to the set of permissions, it becomes necessary for the agent constructing the permission document (typically a SIP user agent, though not necessarily) to know which permissions are supported by the server. This allows the agent to know how to build a document that results in the desired behavior, since unknown permissions would be ignored by the server. To handle this, when presence authorization documents are transported using
拡張機能はアクセス権のセットに行われた場合、それは権限がサーバによってサポートされているかを知るために（通常はSIPユーザーエージェント、必ずしもそうではないが）許可文書を構築するために、エージェントが必要になります。これは、エージェントが、未知の権限は、サーバによって無視されるので、目的の動作が発生した文書を構築する方法を知ることができます。これに対処するには、プレゼンス認可文書を使用して輸送されます
XCAP, the XCAP capabilities document stored at the server SHOULD contain the namespaces for the permissions supported by the presence server. This way, an agent can query for this list prior to constructing a document.
XCAPは、サーバーに格納されているXCAP機能の文書は、プレゼンスサーバでサポートされているアクセス権のための名前空間を含むべきです。この方法では、エージェントは、文書を作成する前にこのリストを照会することができます。
The following section defines the details necessary for clients to manipulate presence authorization documents from a server using XCAP.
次のセクションでは、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 "pres-rules" AUID within the IETF tree, via the IANA registration in Section 11.
XCAPは、IETFツリーまたはベンダーツリーのいずれかに固有のアプリケーションの使用ID（AUID）を定義するために、アプリケーション用法を必要とします。この仕様は、セクション11でIANA登録を介して、IETFツリー内の「PRES-ルール」AUIDを定義します。
XCAP requires application usages to define a schema for their documents. The schema for presence authorization documents is in Section 7.
XCAPは、その文書のスキーマを定義するために、アプリケーションの使用方法を必要とします。プレゼンス認可文書のスキーマは、セクション7です。
XCAP requires application usages to define the default namespace for their URIs. The default namespace is urn:ietf:params:xml:ns:pres-rules.
XCAPは、そのURIのデフォルトの名前空間を定義するために、アプリケーションの使用方法を必要とします。 IETF：：のparams：XML：NS：PRES-ルールのデフォルトの名前空間は、URNです。
XCAP requires application usages to define the MIME type for documents they carry. Presence authorization documents inherit the MIME type of common policy documents, application/auth-policy+xml.
XCAPは、彼らが運ぶ文書のMIMEタイプを定義するには、アプリケーション用法が必要です。プレゼンス認可文書は、共通の政策文書、アプリケーション/ AUTH-政策+ XMLのMIMEタイプを継承します。
There are no additional constraints defined by this specification.
この仕様で定義された追加の制約はありません。
Semantics of a presence authorization document are discussed in Section 3.
プレゼンス認可文書のセマンティクスは、第3節で議論されています。
When a presence agent receives a subscription for some user foo within a domain, it will look for all documents within http://[xcap root]/pres-rules/users/foo, and use all documents found beneath that point to guide authorization policy. If only a single document is used, it SHOULD be called "index".
プレゼンスエージェントは、ドメイン内の一部のユーザーfooのサブスクリプションを受け取ると、それは、http内のすべての文書を検索します：// [XCAPルート] / PRES-ルール/ユーザー/ fooの、および承認を導くために、そのポイントの下に見つかったすべての文書を使用しますポリシー。唯一の単一のドキュメントを使用する場合は、「インデックス」と呼ばれるべきです。
There are no additional resource interdependencies defined by this application usage.
このアプリケーション用法で定義された追加のリソース依存関係はありません。
This application usage does not modify the default XCAP authorization policy, which is that only a user can read, write, or modify their own documents. A server can allow privileged users to modify documents that they don't own, but the establishment and indication of such policies are outside the scope of this document.
このアプリケーションの使用状況は、ユーザーが、読み取り、書き込み、または自分のドキュメントを変更することができるということであるデフォルトのXCAPの認可ポリシーを変更したりすることはありません。サーバは、特権ユーザーが所有していない文書を変更できるようにすることができますが、そのような政策の確立と表示はこの文書の範囲外です。
Presence authorization policies contain very sensitive information. They indicate which other users are "liked" or "disliked" by a user. As such, when these documents are transported over a network, they SHOULD be encrypted.
プレゼンス認可ポリシーは、非常に機密性の高い情報が含まれています。彼らは、他のユーザーが「気に入った」または、ユーザが「嫌い」されているかを示します。このように、これらの文書は、ネットワークを介して輸送されるとき、それらは暗号化されるべきです。
Modification of these documents by an attacker can disrupt the service seen by a user, often in subtle ways. As a result, when these documents are transported, the transport SHOULD provide authenticity and message integrity.
攻撃者によるこれらの文書の変更は、しばしば微妙な方法で、利用者から見たサービスを中断することができます。その結果、これらの文書が搬送されたときに、トランスポートは、信頼性とメッセージの完全性を提供する必要があります。
In the case where XCAP is used to transfer the document, both clients and servers MUST implement HTTP over Transport Layer Security (TLS) and HTTP Digest authentication. Sites SHOULD authenticate clients using digest authentication over TLS, and sites SHOULD define the root services URI as an https URI.
XCAPは、文書を転送するために使用された場合には、クライアントとサーバの両方がトランスポート層セキュリティ（TLS）とHTTPダイジェスト認証over HTTPを実装しなければなりません。サイトでは、TLSを超えるダイジェスト認証を使用してクライアントを認証すべきである、とサイトがHTTPS URIとしてルートサービスURIを定義する必要があります。
Authorization documents themselves exist for the purposes of providing a security function - privacy. The SIP presence specifications [18] require the usage of an authorization function prior to the granting of presence information, and this specification meets that need. Presence authorization documents inherit the privacy properties of the common policy format on which they are based. This format has been designed to be privacy-safe, which means that failure of the presence server to obtain or understand an authorization document can never reveal more information than is desired about the user, only less. This is a consequence of the fact that all permissions are positive grants of information, and not negative grants.
認証文書自体は、セキュリティ機能を提供する目的のために存在する - プライバシーを。 SIPプレゼンス仕様[18]プレゼンス情報の付与に先立って認証機能の使用を必要とし、そして本明細書は、その必要性を満たします。プレゼンス認可文書は、それらの基になっている共通のポリシー形式のプライバシーのプロパティを継承します。このフォーマットは、許可書を取得したり、理解するためのプレゼンスサーバの障害が唯一の少ないユーザー、約希望されるよりも多くの情報を明らかにしたことがないことを意味し、プライバシ安全であるように設計されています。これは、すべてのアクセス権が正情報の助成金ではなく、負の補助金であるという事実の結果です。
A consequence of this design is that the results of combining several authorization documents can be non-obvious to end users. For example, if one authorization document grants permission for all users from the example.com domain to see their presence, and another document blocks joe@example.com, the combination of these will still provide presence to joe@example.com. Designers of user interfaces are encouraged to carefully pay attention to the results of combining multiple rules.
この設計の結果は、いくつかの認可文書を結合した結果は、エンドユーザーに非自明であるということです。 joe@example.comその存在を確認するためにexample.comドメインからのすべてのユーザーに対して1人の承認文書が許可を与えると、別の文書ブロックの場合たとえば、これらの組み合わせは、まだjoe@example.comに存在感を提供します。ユーザーインターフェースの設計者は、慎重に複数のルールを組み合わせた結果に注意を払うことをお勧めします。
Another concern is cases where a user sets their privacy preferences from one client, uploads their presence authorization document to a server, and then modifies them from a different client. If the clients support different subsets of the document format, users may be confused about what information is being revealed. Clients retrieving presence authorization documents from a server SHOULD render, to the users, information about rules that they do not understand, so that users can be certain what rules are in place.
もう一つの懸念は、ユーザーが、1つのクライアントから自分のプライバシー設定を設定し、サーバにその存在認可文書をアップロードし、別のクライアントからそれらを変更する例です。クライアントは、文書フォーマットの異なるサブセットをサポートしている場合、ユーザーは情報が明らかにされているかについて混乱することがあります。ユーザーはルールが整備されているものを特定することができるように、サーバーからのプレゼンス認可文書を検索するクライアントは、ユーザーに、彼らは理解していないルールに関する情報をレンダリングするべきです。
There are several IANA considerations associated with this specification.
この仕様に関連したいくつかのIANAの考慮事項があります。
This section registers an XCAP Application Usage ID (AUID) according to the IANA procedures defined in [2].
このセクションでは、[2]で定義されたIANA手順に従って（AUDIT）の蓋のアプリケーション使用状況を登録します。
Name of the AUID: pres-rules
AUIDの名前：PRES-ルール
Description: Presence rules are documents that describe the permissions that a presentity [17] has granted to users that seek to watch their presence.
説明：プレゼンスルールはプレゼン[17]がその存在を鑑賞しようとユーザーに付与したことの権限を記述した文書です。
This section registers a new XML namespace, per the guidelines in [11]
このセクションでは、[11]のガイドラインごとに、新しいXML名前空間を登録します
URI: The URI for this namespace is urn:ietf:params:xml:ns:pres-rules.
URI：IETF：：のparams：XML：NS：PRES-ルールこの名前空間のURIはURNです。
Registrant Contact: IETF, SIMPLE working group (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者連絡先：IETF、SIMPLEワーキンググループ（simple@ietf.org）、ジョナサン・ローゼンバーグ（jdrosen@jdrosen.net）。
XML:
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>Presence Rules Namespace</title> </head> <body> <h1>Namespace for Permission Statements</h1> <h2>urn:ietf:params:xml:ns:pres-rules</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc5025.txt"> RFC5025</a>.</p> </body> </html> END
！<？xmlのバージョン= "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> <メタHTTP-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset = ISO-8859許可書について-1" /> <タイトル>プレゼンスルール名前空間</ TITLE> </ HEAD> <BODY> <H1>名前空間</ H1> <H2> URN：IETF：のparams：XML：NS：PRES-ルール< / H2> <P> <a href="http://www.rfc-editor.org/rfc/rfc5025.txt"> RFC5025 </a>を参照してください。</ P> </ body> </ html>このEND
This section registers an XML schema per the procedures in [11].
このセクションでは、[11]の手順ごとにXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:pres-rules.
URI：URN：IETF：のparams：XML：スキーマ：PRES-ルール。
Registrant Contact: IETF, SIMPLE working group (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者連絡先：IETF、SIMPLEワーキンググループ（simple@ietf.org）、ジョナサン・ローゼンバーグ（jdrosen@jdrosen.net）。
The XML for this schema can be found as the sole content of Section 7.
このスキーマのためのXMLは、第7節の唯一の内容として求めることができます。
The author would like to thank Richard Barnes, Jari Urpalainen, Jon Peterson, and Martin Hynar for their comments.
作者は彼らのコメントのためにリチャード・バーンズ、ヤリUrpalainen、ジョンピーターソン、マーティンHynarに感謝したいと思います。
[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] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[4]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[6] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[6]ローゼンバーグ、J.、RFC 3857、2004年8月 "セッション開始プロトコル（SIP）のためのウォッチャー情報イベントテンプレート・パッケージ"。
[7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[7]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[8] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.
[8] Schulzrinneと、H.、Tschofenig、H.、モリス、J.、クエリャル、J.、ポーク、J.、およびJ.ローゼンバーグ、 "共通ポリシー：プライバシー設定を表現するためのドキュメントフォーマット"、RFC 4745、2月2007。
[9] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[9] Schulzrinneと、H.、Gurbani、V.、Kyzivat、P.、およびJ.ローゼンバーグが、 "RPID：リッチプレゼンス機能拡張プレゼンス情報データフォーマット（PIDF）に"、RFC 4480、2006年7月。
[10] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[10]ローゼンバーグ、J.、 "プレゼンスのためのデータモデル"、RFC 4479、2006年7月。
[11] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[11] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
[12] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[12] Schulzrinneと、H.、 "電話番号については、TEL URI"、RFC 3966、2004年12月。
[13] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[13] Duerst、M.およびM. Suignard、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
[14] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[14]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[15] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[15]ピーターソン、J.とC.ジェニングス、 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、RFC 4474、2006年8月。
[16] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[16]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[17] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[17]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[18] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[18]ローゼンバーグ、J.、 "セッション開始プロトコルのためのプレゼンスイベントパッケージ（SIP）"、RFC 3856、2004年8月。
Author's Address
著者のアドレス
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサン・ローゼンバーグシスコエジソン、NJ US
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電子メール：jdrosen@cisco.com URI：http://www.jdrosen.net
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に情報を記述してください。