[要約] RFC 5025は、プレゼンスの認証ルールに関する標準仕様であり、プレゼンス情報の共有とアクセス制御を管理するためのガイドラインを提供します。その目的は、プレゼンス情報のセキュリティとプライバシーを確保し、適切なアクセス制御を実施することです。
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）により、ウォッチャーと呼ばれるユーザーが、プレゼンテーション[17]と呼ばれる別のユーザーに登録して、存在情報[18]を学習することができます。このサブスクリプションは、プレゼンスエージェントによって処理されます。ただし、存在情報は敏感であり、プレゼンスエージェントは、プレゼンス情報を配る前にプレゼンテーションから承認を必要とします。そのため、プレゼンス認証文書形式が必要です。この仕様では、Presence Authorization Documentと呼ばれるこのようなドキュメントの形式を定義します。
[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.
プレゼンス認証文書は、いくつかの手段を使用してクライアントが操作できます。そのようなメカニズムの1つは、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.
このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "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ドキュメントです。存在認証文書は、一般的なポリシー文書のMIMEタイプ、Application/Auth-Policy XMLを継承します。[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:
<idention>要素は[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 WR（Watcher/Requestor）のIDをURIまたは国際化されたリソース識別子（IRI）として表す手順を定義します[13]。
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. このアサーションには、攻撃当事者が監視者の身元を決定するために（上記で定義したように）形式の暗号化認証を使用したという主張が含まれています。
2. the server trusts that assertion, and
2. サーバーは、そのアサーションを信頼しています
3. the assertion provides an identity in the form of a URI.
3. このアサーションは、URIの形でアイデンティティを提供します。
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]、Digest Authentication [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 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.
ただし、RFC 3261 [5]の194ページに記載されている匿名認証は、ウォッチャーのアイデンティティを生成しないため、認証の有効なメカニズムとは見なされません。ただし、RFC 4474 [15]と組み合わせて使用される場合、ヘッダーフィールドからの匿名は、認証の許容可能なメカニズムと見なされます。これは、ASSERTINGノードがウォッチャーのアイデンティティを生成する認証を実行したことを暗示するためです。
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.
アイデンティティのアサーションが利用されている場合、主張されたアイデンティティ自体（これは、容認できる形式のアイデンティティアサーションのためのURIの形式です）がURIとして利用されます。アイデンティティアサーションメカニズムがウォッチャーに対して複数のURIを主張する場合、それらのそれぞれが[8]で概説されている比較に使用され、それらのいずれかがA <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
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".
プレゼンスサーバーがサブスクライブリクエストを受信した場合、「Example.com」に設定されたレルムで挑戦し、その後のサブスクライブには、「Ali」のユーザー名とパスワード「F79AJVVH8A6S6」で生成されたダイジェスト応答を備えた認証ヘッダーフィールドが含まれています。一致操作で使用されるアイデンティティは、「sip：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があります。この仕様に関しては、これらのエイリアスの間に関係はありません。それぞれが異なるユーザーのように見えます。これは、ウォッチャーがプレゼンテーションとは異なるドメインにあるシステムの結果となります。ただし、ウォッチャーとプレゼンテーションが同じドメインにある場合でも、Watcherのエイリアスがあることを存在する場合、これらのエイリアスは互いにマッピングされていないか、何らかの方法で使用されていません。
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も匿名のリクエストを許可します。ウォッチャーがプレゼンスサーバーにIDを提供しない認証メカニズム（SIPダイジェスト「匿名」ユーザー名など）を使用したため、リクエストが匿名である場合、リクエストは認証されていないと見なされ（上記のように）、空のみに一致します<identity>要素。リクエストがプライバシーヘッダーフィールド[14]を含むため匿名であるが、上記の基準を満たす主張されたIDが含まれている場合、そのアイデンティティが利用され、リクエストが匿名であるという事実は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である<one>および<を除いて<を除く<を除く<を除く<を除く<を除いて<を除く<を除いて<を除く<を除いたりしません。同じことが逆に言えます。WR IDがテルURIである場合、これはユーザーパーツが電話番号である<one>または<を除く<を除いて<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.
<sphere>要素は[8]で定義されています。ただし、一般的なポリシー仕様を使用する各アプリケーションは、条件の評価で使用される<Sphere>の値をどのように計算するかを決定する必要があります。
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.
<Sphere>の値を計算するために、プレゼンスエージェントは、公開されたすべてのプレゼンスドキュメントを提示について調べます。そのうちの少なくとも1つが個人データコンポーネント[10]の一部として<Sphere>要素[9]を含み、要素を含むすべてのものがそれに対して同じ値を持っている場合、これは<sphere>に使用される値です。存在するポリシー処理。ただし、公開されているドキュメントのいずれにも<sphere>要素が存在しないか、存在していたが一貫性のない値があった場合、その値は存在ポリシー処理の観点から未定義と見なされます。
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.
サブスクリプション処理を決定するための条件として<sphere>を使用することに注意する必要があります。<sphere>の値は動的に変化するため、状態の変更により、サブスクリプションが突然終了する可能性があります。ウォッチャーは、投票を除いて、<Sphere>の変化の価値としてサブスクリプションが復活するときに知る方法がありません。このため、<sphere>は主に変換を定義するルールを一致させるのに役立ちます。
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 [6]の図1にサブスクリプション処理状態マシンを利用することで説明できます。
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.
<サブハンドリング>許可が値を「ブロック」に変更すると、影響を受けるすべてのサブスクリプションに対して「拒否された」イベントがサブスクリプション状態マシンに生成されます。これにより、状態マシンは「終了した」状態に移動し、値「終了」と「拒否された」[7]の理由でサブスクリプション状態のヘッダーフィールドを備えたウォッチャーに通知を送信します。彼らのサブスクリプション。新しいサブスクリプションが後で到着し、そのサブスクリプションに適用される<サブハンドリング>の値が「ブロック」である場合、サブスクリプション処理は「subscribe、ポリシー=「init」状態からの分岐、および403に続きます。サブスクライブへの応答が生成されます。
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]を「保留中」に更新します。Subscription-State Headerフィールドには理由がありません（このケースを処理するために定義されていません）。これ以上の文書はこのウォッチャーに送信されません。サブスクリプションが「保留中」、「待機」、または「終了」状態にある場合、状態に変更はありません。新しいサブスクリプションが後で到着し、そのサブスクリプションに適用される<サブハンドリング>の値が「確認」である場合、サブスクリプション処理は「subscribe、init」状態からの「ポリシーなし」ブランチ、および202の応答に続きます。サブスクライブに生成され、その後に「保留中」のサブスクリプション状態を備えた通知が続きます。その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.
<サブハンドリング>許可が「ブロックされた」または「確認」から「丁寧なブロック」または「許可」に値を変更すると、これにより、影響を受けるすべてのサブスクリプションに対して「承認された」イベントが状態マシンに生成されます。サブスクリプションが「保留中」状態にある場合、状態マシンは「アクティブ」状態に移動し、「アクティブ」のサブスクリプションヘッダーフィールドを使用して通知を送信し、存在ドキュメントを含めることができます。それは通知します。
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.
サブスクリプションが「待機」状態にある場合、「終了した」状態に移動します。新しいサブスクリプションが後で到着し、そのサブスクリプションに適用される<サブハンドリング>の値が「丁寧なブロック」または「許可」である場合、サブスクリプション処理は「サブスクライブ、ポリシー=受け入れ」ブランチに従います。「状態、およびサブスクライブに対する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).
<revish-devices>許可により、ウォッチャーは存在ドキュメントに存在する<device>情報を表示できます。設定された変数です。セットの各メンバーは、デバイスまたはデバイスのグループを識別する方法を提供します。この仕様では、セット内の3つのタイプの要素を定義します。これは、クラスごとにデバイスの発生を識別します。<deviceId>、デバイスIDによるデバイスの発生を識別します。および<Occurrence-Id>。これは、発生IDによるデバイスの発生を識別します。デバイスIDと発生IDは[10]で定義されています。セットの各メンバーは、そのタイプ（クラス、デバイスID、または発生ID）および値（クラスの値、デバイスIDの値、またはOCURRENCE-IDの値）によって識別されます。
For example, consider the following <provide-devices> element:
たとえば、以下の<Proves-Devices>要素を考慮してください。
<provide-devices> <deviceID>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</deviceID> <class>biz</class> </provide-devices> This set has two members. This is combined with a <provide-devices> element from a different rule:
<Proves-Devices> <DeviceId> urn：UUID：F81D4FAE-7DEC-11D0-A765-00A0C91E6BF6 </deviceId> <class> biz </class> </sultie-devices>このセットには2人のメンバーがいます。これは、別のルールからの<sultion-devices>要素と組み合わされます。
<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>
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.
<sultion-devices>要素は、存在するドキュメントに存在するすべてのデバイスが発生するための短いハンド表記です。
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.
セットのデバイス識別子の1つがそのデバイスの発生を識別する場合、特定のデバイスの発生を確認する許可が与えられます。ウォッチャーに<class>許可が与えられ、デバイスの発生の<class>がケースに敏感な平等に基づいて<class>許可の値と一致する場合、デバイスの発生は存在ドキュメントに含まれます。<deviceId>許可がウォッチャーに許可され、デバイスの発生の<deviceId>がURIの等価に基づいて<deviceId>許可の値と一致する場合、デバイスの発生は存在ドキュメントに含まれます。ウォッチャーに<Occurrence-Id>許可が許可され、デバイスの発生の<Occurrence-Id>がケースに敏感な平等に基づいて<Occurrence-ID>許可の値と一致する場合、デバイスの発生はプレゼンスドキュメント。さらに、<All-Devices>許可がWatcherに許可された場合、デバイスの発生が存在ドキュメントに含まれています。
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.
<surpite-persons>許可により、ウォッチャーは存在ドキュメントに存在する<パーソン>情報を見ることができます。設定された変数です。セットの各メンバーは、人の発生を識別する方法を提供します。この仕様は、セット内の2つのタイプの要素を定義します。これは、クラスごとに人の発生を識別し、<Occurence -Id>を識別します。セットの各メンバーは、そのタイプ（クラスまたは発生-ID）および値（OCURRENCE-IDのクラスまたは値の値）で識別されます。<Prover-Persons>要素は、存在するドキュメントに存在するすべての人の出来事の短い表記法である特別な値<All-Persons>を引き受けることもできます。設定された組み合わせは、<sultion-devices>要素と同じように行われます。
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.
セットの個人識別子の1人がその人の発生を識別した場合、特定の人の発生を確認する許可が与えられます。<class>許可がウォッチャーに付与され、人の発生の<class>がケースに敏感な平等に基づいて<class>許可の価値と一致する場合、人の発生は存在文書に含まれます。<Occurrence-Id>許可がウォッチャーに付与され、人の発生の<ocrence-id>がケースに敏感な平等に基づいて<Occurrence-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.
<surps-services>許可により、ウォッチャーは存在ドキュメントの<tuple>要素に存在するサービス情報を見ることができます。<Proves-Devices>のように、それは設定された変数です。セットの各メンバーは、サービスの発生を識別する方法を提供します。この仕様では、セット内の4つのタイプの要素を定義します。これは、クラスごとのサービスの発生を識別します。<Occurrence-ID>、OCURRENCE IDによってサービスを識別します。<Service-Uri>、サービスURIのサービスを識別します。<Service-Uri-Scheme>は、サービスURIスキームによってサービスを識別します。セットの各メンバーは、そのタイプ（クラス、発生-ID、サービス-URI、またはサービス-URI-Scheme）および値（クラスの値、出現-IDの価値、Service-URIの値、）によって識別されます。またはService-uri-schemeの値）。<surps-services>要素は、存在するドキュメントに存在するすべてのサービスが発生するために、特別な値<All-services>を引き受けることもできます。設定された組み合わせは、<Proves-Persons>要素に対して同じように行われます。
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.
セットのサービス識別子の1つがそのサービスの発生を識別する場合、特定のサービスの発生を確認する許可が与えられます。<class>許可がウォッチャーに付与され、サービスの発生の<class>がケースに敏感な平等に基づいて<class>許可の値と一致する場合、サービスの発生はプレゼンスドキュメントに含まれます。<service-uri>許可がウォッチャーに付与され、サービスの発生の<service-uri>がURIの等価に基づいて<service-uri>許可の値と一致する場合、サービスの発生は存在ドキュメントに含まれています。ウォッチャーに<Occurrence-Id>許可が付与され、サービスが発生する<ocurrence-id>がケースに敏感な平等に基づいて<ocurrence-id>許可の値と一致する場合、サービスの発生はプレゼンスドキュメント。<service-uri-scheme>許可がウォッチャーに許可され、サービスの発生に対するサービスURIのスキームがケースに敏感な平等に基づいて<service-uri-scheme>の値と一致する場合、サービスの発生は含まれます存在するドキュメント。さらに、<All-Services>許可がWatcherに付与された場合、サービスの発生がプレゼンスドキュメントに含まれています。
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.
個人、デバイス、またはサービス情報がドキュメントに含まれると、このセクションの許可は、そこにどの存在属性が報告されるかを定義します。特定の情報が常に報告されています。特に、すべての<tuple>要素の<contact>、<service-class> [9]、<basic>ステータス、<timestamp>要素は、存在する場合、ウォッチャーに提供されます。すべての<パーソン>要素の<タイムスタンプ>要素は、存在する場合、ウォッチャーに提供されます。すべての<device>要素の<タイムスタンプ>および<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]で定義されている<アクティビティ>要素へのアクセスを制御します。この許可を提供する要素の名前は<Pression-Activities>であり、ブールタイプです。その値が当てはまる場合、個人データ要素の<アクティビティ>要素がウォッチャーに報告されます。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>要素へのアクセスを制御します。この許可を提供する要素の名前は<Proves-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]で定義されているように、<tuple>要素の<deviceId>要素へのアクセスを制御します。この許可を提供する要素の名前は<sitred-deviceid>であり、ブールタイプです。その値が真である場合、サービスデータ要素の<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]で定義されている<Mood>要素へのアクセスを制御します。この許可を提供する要素の名前は<Prives-Mood>であり、ブールタイプです。その値が当てはまる場合、個人データ要素の<Mood>要素がウォッチャーに報告されます。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]で定義されている<Place-IS>要素へのアクセスを制御します。この許可を提供する要素の名前は<version-place-is>であり、ブールタイプです。その値が真である場合、人データ要素の<place-is>要素がウォッチャーに報告されます。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]で定義されている<place-type>要素へのアクセスを制御します。この許可を提供する要素の名前は<version-place-type>であり、ブール型です。その値が真である場合、人データ要素の<clace-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]で定義されている<プライバシー>要素へのアクセスを制御します。この許可を提供する要素の名前は<sultion-privacy>であり、ブールタイプです。その値が真である場合、個人またはサービスデータ要素の<プライバシー>要素がウォッチャーに報告されます。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]で定義されている<lationssion>要素へのアクセスを制御します。この許可を提供する要素の名前は<提供関係>であり、ブールタイプです。その値が真である場合、サービスデータ要素の<lationssion>要素はウォッチャーに報告されます。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]で定義されている<sphere>要素へのアクセスを制御します。この許可を提供する要素の名前は<version-sphere>であり、ブールタイプです。その値が真である場合、人データ要素の<Sphere>要素がウォッチャーに報告されます。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]で定義されている<Satution-Icon>要素へのアクセスを制御します。この許可を提供する要素の名前は<spriving-status-icon>であり、ブール型です。その値が当てはまる場合、人またはサービスデータ要素の<status-icon>要素がウォッチャーに報告されます。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]で定義されている<タイムオフセット>要素へのアクセスを制御します。この許可を提供する要素の名前は<version-time-or-or-offset>であり、ブールタイプです。その値が真である場合、人データ要素の<タイムオフセット>要素がウォッチャーに報告されます。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]で定義されている<ユーザーインプット>要素へのアクセスを制御します。この許可を提供する要素の名前は<version-user-input>であり、列挙された整数タイプです。その価値は、直接、デバイス、またはサービスデータ要素でウォッチャーに提供される情報を定義します。
false: This value indicates that the <user-input> element is removed from the document. It is assigned the numeric value of 0.
FALSE：この値は、<ユーザーインプット>要素がドキュメントから削除されたことを示しています。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.
BARE：この値は、<user-input>要素が保持されることを示しています。ただし、「アイドル式」と「」属性を削除する必要があります。この値には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.
しきい値：この値は、<user-input>要素が保持されることを示しています。ただし、「アイドル閾値」属性のみが保持されます。この値には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.
完全：この値は、<user-input>要素が属性を含む保持されることを示しています。この値には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.
この許可は、[3]で<Tuple>および[10]で定義されている<mote>要素へのアクセスを制御します。この許可を提供する要素の名前は<Prove-note>であり、ブールタイプです。その値が真である場合、人、サービス、またはデバイスのデータ要素の任意の要素がウォッチャーに報告されます。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.
この許可は、<アクティビティ>、<mood>、<clace-is>、<place-type>、<prace-type>、<lationss>、または<service-class>要素内に存在する<note>値に関係していません。これらの要素内のメモは、それぞれの要素の基本的に値であり、存在ドキュメントでそれぞれの要素が許可されている場合に存在します。たとえば、<アクティビティ>要素がプレゼンスドキュメントに存在し、<note>値がある場合、そのメモは、<surce-activities>許可が与えられた場合、ウォッチャーに送信されたドキュメントに存在します。<sulting-note>許可が与えられるかどうか。
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.
システムを専有または新しいプレゼンス情報を含めることを許可し、ユーザーがその情報の許可を設定できることが重要です。このため、<sult-unknown-aTtribute>許可が定義されています。この許可は、指定された名前と名前空間を持つ未知の存在属性（<revist-unknown-aTtribute>要素の必須属性として提供）をドキュメントに含める必要があることを示しています。そのタイプはブール値です。
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.
名前属性の値は、資格のない要素名（名前空間プレフィックスを含めてはならないことを意味します）でなければならず、NS属性の値は名前空間URIでなければなりません。2つは組み合わさって、適格な要素名を形成します。これは、同じ適格名を持つ存在情報データ形式（PIDF）<Tuple>、<device>、または<パーソン>要素のすべての未知の子要素に一致します。この文脈では、「不明」とは、その要素の承認ポリシーを定義するスキーマをプレゼンスサーバーが認識していないことを意味します。定義上、これにより、<reviding-unknown-aTtribute>ルールは、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.
この定義のもう1つの結果は、<revist-unknown-aTtribute>要素の解釈が存在サーバーをアップグレードした場合に変更できることです。たとえば、アップグレードの前に、ある属性にtrueの値を使用して<version-unknown-aTtribute>を使用した承認文書があるサーバーを考えてみましょう。この属性は、サーバーに知られていない名前空間とスキーマからのものであるため、属性がウォッチャーに提供されました。ただし、アップグレード後、サーバーは、FOO属性へのアクセスを付与する許可を得るために、新しい名前空間とスキーマを認識しています。これで、Foo属性の<viture-unknown-aTtribute>許可は無視され、ウォッチャーに送信された存在書類からこれらの要素が削除されます。システムはプライバシーの安全なままですが、行動は予想どおりではないかもしれません。クライアントがポリシーを設定できるようにするシステムの開発者は、新しい承認ドキュメントをアップロードする前に（セクション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.
この許可は、ドキュメントに存在するすべての人、デバイス、およびタプル要素のすべての存在属性へのアクセスを付与します（ドキュメントに存在するものは、<sultion-persons>、<sultion-devices>、および<によって決定されます。サービスを提供>許可を提供）。それは事実上、提供の活性性のセット、提供クラス、提供デバイス、提供、提供、提供、提供者、提供者、提供関係、供給範囲に拡大するマクロです。、提供-status-icon、提供時間オフセット、提供者ユーザー入力、提供ノート、およびドキュメント内の各存在属性が許可を与えるように、nknown-aTtributeを提供する権限を提供します。これは、個人、サービス、またはデバイスの発生が提供されている限り、サーバーに知られていないものや将来の存在ドキュメント拡張機能で定義されているものを含むすべての存在属性がウォッチャーに付与されることを意味します。
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）のプロパティが必要です。言い換えれば、プライバシーフィルタリング操作のさらなるアプリケーションでは、存在書類のさらなる変更が生じないため、フィルタリング操作のさらなるアプリケーションがNO-OPになります。これの結果は、すべての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.
クライアントは、この仕様で定義されているすべてのアクション、変換、および条件をサポートすることをお勧めします。クライアントがサブセットをサポートしている場合、ユーザーは別のクライアントから承認ルールを操作し、異なるサブセットをサポートし、それらの結果をサーバーに保存する可能性があります。ユーザーが最初のクライアントに戻ってそこに存在認証ルールを表示すると、クライアントがサポートされていない条件、アクション、または変換が含まれる可能性があるため、クライアントはサーバーから取得されたドキュメントを適切にレンダリングまたは操作できない場合があります。この規範的要件が必須ではない唯一の理由は、ユーザーが単一のクライアントから存在認証ルールを操作する有効な条件があることです。その場合、この問題は発生しません。
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スキームがSIPおよびMailtoであるすべてのサービスの存在データへのアクセスを許可されます。個人情報も提供されています。ただし、<Proves-Devices>がないため、Watcherにデバイス情報は提供されません。ウォッチャーに提供されるサービスと個人の情報内で、<ユーザーインプット>要素と同様に、<アクティビティ>要素が表示されます。ただし、<user-input>要素の「アイドル閾値」と「属性」属性は削除されます。最後に、存在属性<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" 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>
</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: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>
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 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.
許可のセットに拡張機能が行われると、エージェントが許可ドキュメント（通常はSIPユーザーエージェントではありますが、必ずしもSIPユーザーエージェントではありません）を構築することが、サーバーによってどの権限がサポートされているかを知る必要があります。これにより、エージェントは、未知の権限がサーバーによって無視されるため、目的の動作をもたらすドキュメントを構築する方法を知ることができます。これを処理するために、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-Rule」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のデフォルトの名前空間を定義するためのアプリケーション使用法が必要です。デフォルトの名前空間はurn：ietf：params：xml：ns：pres-rulesです。
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タイプを定義するためのアプリケーションの使用が必要です。存在認証文書は、一般的なポリシー文書のMIMEタイプ、Application/Auth-Policy XMLを継承します。
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 root]/pres-rules/users/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ダイジェスト認証を介してHTTPを実装する必要があります。サイトは、TLSを介した消化認証を使用してクライアントを認証する必要があり、サイトはルートサービスURIをHTTPS 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.
この設計の結果、いくつかの承認文書を組み合わせた結果は、エンドユーザーにとっては非自明である可能性があります。たとえば、1つの承認文書がExample.comドメインのすべてのユーザーにその存在を確認する許可を与え、別のドキュメントがjoe@example.comをブロックする場合、これらの組み合わせは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つの懸念は、ユーザーが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手順に従って、XCAPアプリケーション使用ID（AUID）を登録します。
Name of the AUID: pres-rules
AUIDの名前：Pres-Rule
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：この名前空間のURIはurn：ietf：params：xml：ns：pres-rulesです。
Registrant Contact: IETF, SIMPLE working group (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group（simple@ietf.org）、Jonathan Rosenberg（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
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：schema：pres-rules。
Registrant Contact: IETF, SIMPLE working group (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group（simple@ietf.org）、Jonathan Rosenberg（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.
著者は、リチャード・バーンズ、ジャリ・ウルパラネン、ジョン・ピーターソン、マーティン・ヒナーのコメントに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[2] Rosenberg、J。、「拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）」、RFC 4825、2007年5月。
[3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[3] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年8月。
[4] 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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[6] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[6] Rosenberg、J。、「セッション開始プロトコル（SIP）のウォッチャー情報イベントテンプレートパッケージ」、RFC 3857、2004年8月。
[7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[7] Roach、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.、Morris、J.、Cuellar、J.、Polk、J。、およびJ. Rosenberg、「共通政策：プライバシーの好みを表現するためのドキュメント形式」、RFC 4745、2007年2月。
[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. Rosenberg、「rpid：Rich Expention拡張情報データ形式（PIDF）」、RFC 4480、2006年7月。
[10] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[10] Rosenberg、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。and M. Suignard、「Internationalized Resource Identiers（IRIS）」、RFC 3987、2005年1月。
[14] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[14] ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[15] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[15] Peterson、J。and C. Jennings、「セッション開始プロトコル（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] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内の主張されたアイデンティティのセッション開始プロトコル（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] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[18] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[18] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
Author's Address
著者の連絡先
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサンローゼンバーグシスコエジソン、ニュージャージー州
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。