RFC5025 日本語訳
5025 Presence Authorization Rules. J. Rosenberg. December 2007. (Format: TXT=65880 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Rosenberg Request for Comments: 5025 Cisco Category: Standards Track December 2007
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 5025年のコクチマスカテゴリ: 標準化過程2007年12月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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 Configuration Accessプロトコル(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
1. 序論…2 2. 用語…3 3. 存在承認ドキュメントの構造…3 3.1. 状態…4 3.1.1. アイデンティティ…4 3.1.1.1. 許容形式の認証…4 3.1.1.2. ウォッチャーのためにURIを計算します…5 3.1.2. 球…6 3.2. 動作…7 3.2.1. 購読取り扱い…7 3.3. 変換…9 3.3.1. データ構成要素Elementsへのアクセスを提供します…9 3.3.1.1. デバイス情報…9 3.3.1.2. 人の情報…10 3.3.1.3. 情報を修理してください…11 3.3.2. 存在属性へのアクセスを提供します…12 3.3.2.1. 活動を提供してください…12 3.3.2.2. クラスを提供してください…12 3.3.2.3. DeviceIDを提供してください…13 3.3.2.4. ムードを提供してください…13 3.3.2.5. 提供、場所存在、…13
Rosenberg Standards Track [Page 1] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[1ページ]。
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
3.3.2.6. 場所タイプは提供します…13 3.3.2.7. プライバシーを提供してください…13 3.3.2.8. 関係を提供してください…14 3.3.2.9. 球を備えてください…14 3.3.2.10. 状態アイコンを提供してください…14 3.3.2.11. 時間オフセットを提供してください…14 3.3.2.12. ユーザ入力を提供してください…14 3.3.2.13. 注意を提供してください…15 3.3.2.14. 未知の属性を提供してください…15 3.3.2.15. すべての属性を提供してください…16 4. いつ、承認方針を適用するために…17 5. 実装要件…17 6. 例のドキュメント…18 7. XML図式…19 8. 図式伸展性…21 9. XCAP用法…22 9.1. アプリケーションのユニークなID…22 9.2. XML図式…22 9.3. デフォルト名前空間…22 9.4. MIMEの種類…22 9.5. 合法化規制…22 9.6. データ意味論…22 9.7. コンベンションを命名します…23 9.8. リソース相互依存性…23 9.9. 承認方針…23 10. セキュリティ問題…23 11. IANA問題…24 11.1. XCAPアプリケーションUsage ID…24 11.2. つぼのサブ名前空間登録…25 11.3. XML図式登録証明書…25 12. 承認…26 13. 参照…26 13.1. 標準の参照…26 13.2. 有益な参照…27
1. Introduction
1. 序論
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.
presentity[17]は、ウォッチャーと呼ばれるユーザがInstant MessagingのためのSession Initiationプロトコル(SIP)とPresence(SIMPLE)仕様で別のユーザに加入できると呼びました、それらの存在情報[18]を学ぶために。 この購読は存在エージェントによって扱われます。 しかしながら、存在情報は機密です、そして、存在情報を与える前に、存在エージェントはpresentityから認可を要します。 そういうものとして、存在承認ドキュメント・フォーマットが必要です。 この仕様は存在承認ドキュメントと呼ばれるそのようなドキュメントのために書式を定義します。
Rosenberg Standards Track [Page 2] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[2ページ]。
[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]は承認方針を表すのにフレームワークを指定して、geo-位置や存在などのシステムに適切です。 このフレームワークは存在承認ドキュメントの基礎として使用されます。 フレームワークでは、承認方針は1セットの規則です。 各規則は状態、動作、および変換を含んでいます。 状態は、規則がどんな条件のもとで存在サーバ処理に適用されるかことであると指定します。 動作要素は、どんな行動を取ったらよいかをサーバに言います。 変換要素はそのウォッチャーと、そのようなものとして提示されるのがプライバシー濾過手術を定義する前に操られる存在データがことである方法を示します。 [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 Configuration Accessプロトコル(XCAP)[2]です。 この仕様は存在承認ドキュメントを管理するのにXCAPを使用するのに必要な詳細を定義します。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[1]について説明して、対応する実装のために要件レベルを示すとき解釈されることであるべきですか?
3. Structure of Presence Authorization Documents
3. 存在承認ドキュメントの構造
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の種類、アプリケーション/auth-方針+xmlを引き継ぎます。 [8]で説明されるように、このドキュメントは3つの部品を含む規則で構成されます--状態、動作、および変換。 各動作か変換(また、許可と呼ばれる)が情報の積極的な交付金である特性をウォッチャーに持っています。 その結果、いくつかのソースから得られた動作と変換を結合するための明確なメカニズムがあります。 このメカニズムはプライバシー金庫です、どんな動作や変換の不足もウォッチャーに提示されるより少ない情報をもたらすことができるだけであるので。
This section defines the new conditions, actions, and transformations defined by this specification.
このセクションはこの仕様で定義された新しい状態、動作、および変換を定義します。
Rosenberg Standards Track [Page 3] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[3ページ]。
3.1. Conditions
3.1. 状態
3.1.1. Identity
3.1.1. アイデンティティ
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かInternationalized Resource Identifier(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の存在と将来の認証機構に適用されるように。
3.1.1.1. Acceptable Forms of Authentication
3.1.1.1. 許容形式の認証
When used with SIP, a request is considered authenticated if one of the following is true:
SIPと共に使用されると、以下の1つが本当であるなら、要求は認証されていると考えられます:
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.
ウォッチャーは共有秘密キーか証明書に基づく認証を含む暗号の認証のフォームを通してサーバへのアイデンティティを立証します、そして、その認証はウォッチャーのためのアイデンティティをもたらします。
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]、ダイジェスト認証[4]、暗号で確かめられたアイデンティティ主張を含んでいる、(RFC4474[15])、(RFC3325[16])。
However, the anonymous authentication described on page 194 of RFC 3261 [5] is not considered a valid mechanism for authentication
しかしながら、194RFC3261[5]ページで説明された匿名の認証は認証のための有効なメカニズムであると考えられません。
Rosenberg Standards Track [Page 4] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[4ページ]。
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.
ウォッチャーのためにアイデンティティを生産しないので。 しかしながら、RFC4474[15]に関連して使用されると、匿名のFromヘッダーフィールドは認証のための許容できるメカニズムであると考えられます、断言ノードがウォッチャーのアイデンティティを生産した認証を実行したのをまだ含意しているので。
3.1.1.2. Computing a URI for the Watcher
3.1.1.2. ウォッチャーのためにURIを計算します。
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]に概説された比較に使用されます、そして、>要素を除いて、彼らのどれかが<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 Digest認証の場合では、認証過程は分野の中で見られたユーザ名を作り出します。 そのユーザ名と分野はRecordのAddressに縛られて、食糧を供給すること、および結果として起こるAORを通した(AOR)がウォッチャーURIとして使用されるということです。 データベースで以下の「ユーザ記録」を考えてください:
SIP AOR: sip:alice@example.com digest username: ali digest password: f779ajvvh8a6s6 digest realm: example.com
AORをちびちび飲んでください: 一口: alice@example.com ダイジェストユーザ名: aliダイジェストパスワード: 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".
存在サーバが登録を受ける、要求、分野セットで"example.com"、およびその後にそれに挑戦する、登録、"ali"とダイジェスト応答に関するユーザ名が「f779ajvvh8a6s6"、合っている操作に使用されるアイデンティティは「: alice@example.com をちびちび飲む」ことです」というパスワードで生成されているAuthorizationヘッダーフィールドを含んでいます。
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
SIPシステムでは、ユーザには別名があるのは、可能です--すなわち、シングルユーザーに「割り当てられた」複数のSIP AORsがあります。 この仕様で、それらの別名の間には、関係が全くありません。 それぞれが異なったユーザに似ているでしょう。 これはウォッチャーがpresentityと異なったドメインにいるシステムのために結果になるでしょう。 しかしながら、中にウォッチャーとpresentityがあります。
Rosenberg Standards Track [Page 5] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[5ページ]。
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 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ダイジェスト」ユーザ名などの)にアイデンティティを提供しない認証機構を利用したので要求が匿名であるなら、要求は、非認証されていると(上で議論するように)考えられて、空の<アイデンティティ>要素だけに合うでしょう。 要求がPrivacyヘッダーフィールド[14]を含んでいるので匿名ですが、まだ評価基準が上で定義した断言されたアイデンティティミーティングを含んでいるなら、そのアイデンティティは利用されています、そして、要求が匿名であったという事実はアイデンティティ処理に影響力を全く持っていません。
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に使用される同じ形式で。 'イド'が同じ数があるtel URIである>状態以外に、電話番号があるSIP URIであるWRのアイデンティティは<1>と<に合わないでしょう。 同じくらいは逆で本当です。 WRのアイデンティティがtel URIであるなら、ユーザ部分が電話番号である>状態以外に、これは<1>か<でSIP URIに合わないでしょう。 異なった体系のURIは決して同等ではありません。
3.1.2. Sphere
3.1.2. 球
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.
<球の>の値を計算するために、存在エージェントはpresentityがないかどうかすべての発行された存在ドキュメントを調べます。 少なくとも彼らのひとりが人のデータ構成要素[10]の一部として<球の>要素[9]を含んでいて、要素を含むものがすべて、それのための同じ値を持っているなら、どれが値であるかは<球に存在方針処理に>を使用しました。 しかしながら、<球の>要素が公表された文書のいずれにも存在していなかったか、存在していましたが、矛盾した値を持っていたなら、値は存在方針処理で未定義であると考えられます。
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>
購読取り扱いを決定するのに状態として<球の>を使用することで注意を中に入れなければなりません。 <球の>の値がダイナミックに変化するので、州の変化で、突然購読を終えることができます。 ウォッチャーには、世論調査は別として彼らの購読がいつ<球の>の値として復職するかを知る方法が全くありません。
Rosenberg Standards Track [Page 6] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[6ページ]。
changes. For this reason, <sphere> is primarily useful for matching on rules that define transformations.
変化。 この理由で、<球の>は主として変換を定義する規則で合っていることの役に立ちます。
3.2. Actions
3.2. 動作
3.2.1. Subscription Handling
3.2.1. 購読取り扱い
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]で議論するように、相関関係が許容の間に存在しているなら組み合わせアルゴリズムが独自に各許可に立候補するので、ただ一つの変数にそれらを合併しなければなりません。 それはここで行われることです。 <のサブ取り扱っている>要素は列挙されたIntegerタイプです。 定義された値は以下の通りです。
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.
確認します: この動作は、続く方法を決定するためにpresentityから「未定」の状態に購読を置いて、入力を待つようにサーバに言います。 それには、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.
礼儀正しいブロック: この動作は「アクティブな」状態に購読を置いて、presentityが入手できないのを示す存在ドキュメントを製作するようにサーバに言います。 妥当なドキュメントは、デバイスと人の情報要素を除いて、基本的な状態が閉じられるのに[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]で定義した結合に基づいています。
Rosenberg Standards Track [Page 7] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[7ページ]。
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].
RFC3857[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]を「終えられた」状態、値が「終えられている」状態でSubscription-州のヘッダーフィールドでウォッチャーへのNOTIFYのトランスミッションをもたらして、および「拒絶されること」の理由に動かすでしょう。([7]は彼らの購読を終えます)。 購読処理がa新規申込みが後で到着して、その購読に適用される<サブ取り扱い>の値が「ブロック」であるのに「イニット」状態、および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.
<のサブ取り扱っている>許可が「確認する」値を変えるなら、処理は影響を受ける購読の州に頼っています。 残念ながら、RFC3857の州のマシンは「未定」の承認決定に対応するイベントを定義しません。 購読が「アクティブな」状態にあるなら、それは「未定」の状態に戻ります。 これで、Subscription-州の[7]を「未定に」アップデートして、NOTIFYを送ります。 理由は全くSubscription-州のヘッダーフィールドに含まれていません(なにも本件を扱うために定義されません)。 さらなるドキュメントを全くこのウォッチャーに送りません。 購読が「未定」の、または、「待っている」か、「終えられた」州にあるなら、変化が全く状態にありません。 購読処理がa新規申込みが後で到着して、その購読に適用される<サブ取り扱い>の値が「確認」であるのに「イニット」状態、および202応答からの「申し込んでください、方針がありません」というブランチに続く、登録、「未定」のSubscription-州と共に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-州のヘッダーフィールド、および存在ドキュメントの包含がそのNOTIFYにあるNOTIFYのトランスミッションをもたらして。
Rosenberg Standards Track [Page 8] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[8ページ]。
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.
購読が「待ち」状態にあったなら、それは「終えられた」状態に移行するでしょう。 購読処理がその購読に適用される<サブ取り扱い>の値が新規申込みが後で到着して、「礼儀正しいブロック」か「許容」であるなら、「イニット」状態、およびaからの「申し込んでください、と方針=は受け入れる」という200が応答を承認するブランチに続く、登録、存在ドキュメントで「アクティブ」のSubscription-状態がNOTIFYのボディーにある状態でNOTIFYによって続かれて、生成されます。
3.3. Transformations
3.3. 変換
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.
ここで定義された変換は、プライバシー濾過手術の振舞いを追い立てるのに使用されます。 各変換は存在ドキュメントの特定の部品とウォッチャーが与えられる目に見えることを定義します。 変換の1つのグループが人、デバイス、およびそれらの要素のための身元が分かる情報に基づくサービスデータ要素に目に見えることを与えます。 変換の別のグループは存在ドキュメントの特定のデータ要素へのアクセスを提供します。
3.3.1. Providing Access to Data Component Elements
3.3.1. データ構成要素Elementsへのアクセスを提供します。
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で定義された許容で制御されます。
3.3.1.1. Device Information
3.3.1.1. デバイス情報
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は[10]で定義されます。 そのタイプ(クラス、deviceID、または発生イド)と値(クラスの値、deviceIDの値、または発生イドの値)によってセットの各メンバーは特定されます。
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>つぼ:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</deviceID><クラス>ビジネスの</クラス><を提供しているか、またはデバイスを提供している<>。
Rosenberg Standards Track [Page 9] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[9ページ]。
This set has two members. This is combined with a <provide-devices> element from a different rule:
このセットに、2人のメンバーがいます。 これは異なった規則からデバイスを提供している<>要素に結合されます:
<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>つぼ: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.
セットにおけるデバイス識別子の1つがそのデバイス発生を特定するなら、特定のデバイス発生を見るために許可を与えます。 ウォッチャー、および<クラス>許可の値が大文字と小文字を区別する平等に基礎づけたデバイス発生マッチの<のクラス>に<クラス>許可を与えるなら、存在ドキュメントにデバイス発生を含んでいます。 ウォッチャー、および<deviceID>許可の値がURIの等価性に基礎づけたデバイス発生マッチの<deviceID>に<deviceID>許可を与えるなら、存在ドキュメントにデバイス発生を含んでいます。 <発生イドであるなら、>許可をウォッチャーに与えます、そして、デバイス発生の<発生イド>は>許可が大文字と小文字を区別する平等に基礎づけた<発生イドの値に合っています、そして、存在ドキュメントでデバイス発生を含めます。 さらに、<オールデバイス>許可をウォッチャーに与えたなら、存在ドキュメントにデバイス発生を含んでいます。
3.3.1.2. Person Information
3.3.1.2. 人の情報
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
許可が<人の>情報が存在しているのを見るのをウォッチャーを許容する人々>を存在ドキュメントに供給している<。 それはセット変数です。 セットの各メンバーは人の発生を特定する方法を提供します。 この仕様はセットで2つのタイプの要素を定義します--<のクラス>。(その>は発生IDで発生を特定するクラス、および<発生イド>による人の発生を特定します)。 そのタイプ(クラスか発生イド)と値(クラスの値か発生イドの値)によってセットの各メンバーは特定されます。 また、人々を提供している<>要素ははやり出すことができます。
Rosenberg Standards Track [Page 10] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[10ページ]。
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.
特別な値の<オール人々>。(その>は存在ドキュメントの現在のすべての人の発生のための速記記法です)。 同様にデバイスを提供している<>要素にセット組み合わせをします。
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つがその人の発生を特定するなら、特定の人の発生を見るために許可を与えます。 ウォッチャー、および<クラス>許可の値が大文字と小文字を区別する平等に基礎づけた人の発生マッチの<のクラス>に<クラス>許可を与えるなら、存在ドキュメントに人の発生を含んでいます。 <発生イドであるなら、>許可をウォッチャーに与えます、そして、人の発生の<発生イド>は>許可が大文字と小文字を区別する平等に基礎づけた<発生イドの値に合っています、そして、存在ドキュメントで人の発生を含めます。 さらに、<オール人々>許可をウォッチャーに与えたなら、存在ドキュメントに人の発生を含んでいます。
3.3.1.3. Service Information
3.3.1.3. サービス情報
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.
許可がサービス情報が存在しているのを見るのをウォッチャーを許容するサービス>を存在ドキュメントの<tuple>要素に供給している<。 デバイスを提供している<>のように、それはセット変数です。 セットの各メンバーはサービス発生を特定する方法を提供します。 この仕様はセットで4つのタイプの要素を定義します--<のクラス>。(その>はクラスによるサービス発生を特定します)。 <発生イド>(>は発生IDでサービスを特定します)。 uriを調整している<>(>はサービスURIでサービスを特定します)。 そして、<サービスuri-体系>。(その>はサービスURI体系でサービスを特定します)。 そのタイプ(クラス、発生イド、サービス-uri、またはサービスuri体系)と値(クラスの値、発生イドの値、サービス-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-
セットにおけるサービス識別子の1つがそのサービス発生を特定するなら、特定のサービス発生を見るために許可を与えます。 ウォッチャー、および<クラス>許可の値が大文字と小文字を区別する平等に基礎づけたサービス発生マッチの<のクラス>に<クラス>許可を与えるなら、存在ドキュメントにサービス発生を含んでいます。 uriを調整している<>許可をウォッチャーに与えて、サービス発生のuriを調整している<>が>許可がURIの等価性に基礎づけた<サービス-uriの値に合っているなら、サービス発生は存在ドキュメントに含まれています。 <発生イドであるなら、>許可をウォッチャーに与えます、そして、サービス発生の<発生イド>は>許可がケースに基礎づけた<発生イドの値に合っています。
Rosenberg Standards Track [Page 11] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[11ページ]。
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の体系に与えるなら、存在ドキュメントにサービス発生を含んでいます。 さらに、<オールサービス>許可をウォッチャーに与えたなら、存在ドキュメントにサービス発生を含んでいます。
3.3.2. Providing Access to Presence Attributes
3.3.2. 存在属性へのアクセスを提供します。
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>要素の<接触>、<サービスクラス>[9]、<の基本的な>状態、および<タイムスタンプ>要素をウォッチャーに提供します。 存在しているなら、すべての<人の>要素の<タイムスタンプ>要素をウォッチャーに提供します。 存在しているなら、すべての<デバイス>要素の<タイムスタンプ>と<deviceID>要素をすべてのウォッチャーに提供します。
3.3.2.1. Provide Activities
3.3.2.1. 活動を提供してください。
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であるなら、存在しているなら、この存在属性を取り除きます。
3.3.2.2. Provide Class
3.3.2.2. クラスを提供してください。
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]で定義された<クラス>要素へのアクセスを制御します。 この許可を提供する要素の名前はクラスを提供している<>です、そして、それはブールタイプです。 値がTRUEであるなら、人、サービス、またはデバイスデータ要素のどんな<クラス>要素もウォッチャーに報告されます。 FALSEであるなら、存在しているなら、この存在属性を取り除きます。
Rosenberg Standards Track [Page 12] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[12ページ]。
3.3.2.3. Provide DeviceID
3.3.2.3. DeviceIDを提供してください。
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>要素へのアクセスを制御します。 この許可を提供する要素の名前はdeviceIDを提供している<>です、そして、それはブールタイプです。 値がTRUEであるなら、サービスデータ要素の<deviceID>要素はウォッチャーに報告されます。 FALSEであるなら、存在しているなら、この存在属性を取り除きます。 この許可によって制御されないで、デバイスデータ要素の<deviceID>がいつも含まれていることに注意してください。
3.3.2.4. Provide Mood
3.3.2.4. ムードを提供してください。
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であるなら、存在しているなら、この存在属性を取り除きます。
3.3.2.5. Provide Place-is
3.3.2.5. 提供、場所存在
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であるなら、存在しているなら、この存在属性を取り除きます。
3.3.2.6. Provide Place-type
3.3.2.6. 場所タイプを提供してください。
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]で定義した<場所タイプへのアクセスを制御します。 この許可を提供する要素の名前は場所タイプを提供している<>です、そして、それはブールタイプです。 値がTRUEであるなら、人のデータ要素のタイプ>を置いている<要素はウォッチャーに報告されます。 FALSEであるなら、存在しているなら、この存在属性を取り除きます。
3.3.2.7. Provide Privacy
3.3.2.7. プライバシーを提供してください。
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であるなら、存在しているなら、この存在属性を取り除きます。
Rosenberg Standards Track [Page 13] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[13ページ]。
3.3.2.8. Provide Relationship
3.3.2.8. 関係を提供してください。
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であるなら、存在しているなら、この存在属性を取り除きます。
3.3.2.9. Provide Sphere
3.3.2.9. 球を備えてください。
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であるなら、存在しているなら、この存在属性を取り除きます。
3.3.2.10. Provide Status-Icon
3.3.2.10. 状態アイコンを提供してください。
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であるなら、存在しているなら、この存在属性を取り除きます。
3.3.2.11. Provide Time-Offset
3.3.2.11. 時間オフセットを提供してください。
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であるなら、存在しているなら、この存在属性を取り除きます。
3.3.2.12. Provide User-Input
3.3.2.12. ユーザ入力を提供してください。
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の数値はそれに割り当てられます。
Rosenberg Standards Track [Page 14] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[14ページ]。
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.
剥き出します: この値は、<ユーザによって入力された>要素が保有されることであることを示します。 しかしながら、どんな「活動していない敷居」と“since"属性も取り除くことです。 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の数値はこの値に割り当てられます。
3.3.2.13. Provide Note
3.3.2.13. 注意を提供してください。
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.
この許可は<tuple>のための[3]と<人の>と<デバイス>のための[10]で定義された<注意>要素へのアクセスを制御します。 この許可を提供する要素の名前は注意を提供している<>です、そして、それはブールタイプです。 値が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.
この許可でどんな<注意>値も圧迫しないのは<活動>、<ムード>の中に存在するようになって、<が場所であります。>、<のタイプ>、<プライバシー>、<関係>、または<サービスを置いているクラスの>要素。 これらの要素の中の注意は、それらのそれぞれの要素のための本質的には値であり、それぞれの要素が存在ドキュメントで受入れられるなら、存在しています。 例えば、<活動>要素が存在ドキュメントに存在していて、それのための<注意>価値があれば、その注意は<が提供されるかどうかにかかわらず許可が与えられている活動>を提供している<であるならウォッチャーに送られたドキュメントに許可が与えられている注意>を示します。
3.3.2.14. Provide Unknown Attribute
3.3.2.14. 未知の属性を提供してください。
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
属性という名前の値が資格のない要素名(名前空間接頭語を含んではいけないことを意味する)と、値でなければならない、ナノ秒が結果と考える、名前空間URIはそうであるに違いありません。 2は、適切な要素名を形成するために結合されます。(名はすべての未知に合わせられるでしょう)。
Rosenberg Standards Track [Page 15] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[15ページ]。
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.
同じ適切な名前があるPresence情報Data Format(PIDF)<tuple>、<デバイス>、または<人の>要素の子供要素。 このような関係においては、「未知」は、存在サーバがその要素のために承認方針を定義するどんなschemasも意識していないことを意味します。 定義上、これは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で説明されたメカニズムを使用する)の能力をチェックして、予想されるとして振舞いがあるのを確実にするようにアドバイスされます。
3.3.2.15. Provide All Attributes
3.3.2.15. すべての属性を提供してください。
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.
この許可はドキュメントに存在している人のすべてのすべての存在属性、デバイス、およびtuple要素へのアクセスを承諾します(ドキュメントでのものプレゼントが<で人々>を提供して決定しています、デバイスの>、および<を提供している<サービスを提供している>許容)。 事実上、それは活動を提供するセットに拡大するマクロです、クラスを提供します、deviceIDを提供します、ムードを提供する、提供、場所がそう、場所タイプを提供してください、プライバシーを提供して、関係(それのための球を備えていて、状態アイコンを提供していて、ドキュメントのそれぞれの存在属性が持っている時間によるオフセットの、そして、ユーザ入力を提供していて、注意を提供していて、未知の属性の許容を提供しているそのようなものを提供しているa許可)を提供してください。 これは、全体の人、サービス、またはデバイス発生を提供する限り、サーバに知られない、そして/または、将来の存在ドキュメント拡張子で定義されたものを含むあらゆる存在属性がウォッチャーに与えられるのを含意します。
Rosenberg Standards Track [Page 16] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[16ページ]。
4. When to Apply the Authorization Policies
4. When to Apply the Authorization Policies
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.
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.
The subscription processing aspects of the document get applied by the server when it decides to accept or reject the subscription.
The subscription processing aspects of the document get applied by the server when it decides to accept or reject the subscription.
5. Implementation Requirements
5. Implementation Requirements
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.
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.
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
This specification makes no normative recommendations on the mechanism used to transport presence authorization documents from
Rosenberg Standards Track [Page 17] RFC 5025 Presence Authorization December 2007
Rosenberg Standards Track [Page 17] RFC 5025 Presence Authorization December 2007
clients to their servers. Although Section 9 defines how to utilize XCAP, XCAP is not normatively required by this specification.
clients to their servers. Although Section 9 defines how to utilize XCAP, XCAP is not normatively required by this specification.
6. Example Document
6. Example Document
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.
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.
<?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"?> <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>
Rosenberg Standards Track [Page 18] RFC 5025 Presence Authorization December 2007
Rosenberg Standards Track [Page 18] RFC 5025 Presence Authorization December 2007
7. XML Schema
7. XML Schema
<?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" 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>
Rosenberg Standards Track [Page 19] RFC 5025 Presence Authorization December 2007
Rosenberg Standards Track [Page 19] RFC 5025 Presence Authorization December 2007
</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: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"/>
Rosenberg Standards Track [Page 20] RFC 5025 Presence Authorization December 2007
Rosenberg Standards Track [Page 20] RFC 5025 Presence Authorization December 2007
<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: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>
8. Schema Extensibility
8. Schema Extensibility
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.
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
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
Rosenberg Standards Track [Page 21] RFC 5025 Presence Authorization December 2007
Rosenberg Standards Track [Page 21] RFC 5025 Presence Authorization December 2007
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, 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.
9. XCAP Usage
9. XCAP Usage
The following section defines the details necessary for clients to manipulate presence authorization documents from a server using XCAP.
The following section defines the details necessary for clients to manipulate presence authorization documents from a server using XCAP.
9.1. Application Unique ID
9.1. Application Unique ID
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 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.
9.2. XML Schema
9.2. XML Schema
XCAP requires application usages to define a schema for their documents. The schema for presence authorization documents is in Section 7.
XCAP requires application usages to define a schema for their documents. The schema for presence authorization documents is in Section 7.
9.3. Default Namespace
9.3. Default Namespace
XCAP requires application usages to define the default namespace for their URIs. The default namespace is urn:ietf:params:xml:ns:pres- rules.
XCAP requires application usages to define the default namespace for their URIs. The default namespace is urn:ietf:params:xml:ns:pres- rules.
9.4. MIME Type
9.4. MIME Type
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 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.
9.5. Validation Constraints
9.5. Validation Constraints
There are no additional constraints defined by this specification.
There are no additional constraints defined by this specification.
9.6. Data Semantics
9.6. Data Semantics
Semantics of a presence authorization document are discussed in Section 3.
Semantics of a presence authorization document are discussed in Section 3.
Rosenberg Standards Track [Page 22] RFC 5025 Presence Authorization December 2007
Rosenberg Standards Track [Page 22] RFC 5025 Presence Authorization December 2007
9.7. Naming Conventions
9.7. Naming Conventions
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の中ですべてのドキュメントを探して、そのポイントの下ですべてのドキュメントが当たった使用を探すでしょう。 ただ一つのドキュメントが使用されていて、それがSHOULDでさえあれば、よかったでしょう。「インデックス」と呼ばれます。
9.8. Resource Interdependencies
9.8. リソース相互依存性
There are no additional resource interdependencies defined by this application usage.
このアプリケーション用法で定義されたどんな追加リソース相互依存性もありません。
9.9. Authorization Policies
9.9. 承認方針
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承認方針を変更しません。(それは、ユーザだけがそれら自身のドキュメントを読むか、書くか、または変更できるということです)。 特権ユーザはサーバで、それらが所有していないドキュメントを変更できますが、このドキュメントの範囲の外にそのような方針の設立としるしがあります。
10. Security Considerations
10. セキュリティ問題
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.
存在承認方針は非常に機密の情報を含んでいます。 彼らは、ユーザがどの他のユーザを「好きである」、または「嫌にさせるか」を示します。 そういうものとして、いつがネットワークの上で輸送されるか、そして、これらが、ドキュメントであるそれらはSHOULDです。暗号化されます。
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.
攻撃者によるこれらのドキュメントの変更はユーザによってしばしば微妙な方法で見られたサービスを中断できます。 これらのドキュメントが輸送されるとき、その結果、輸送SHOULDは信憑性とメッセージの保全を提供します。
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がドキュメントを移すのに使用される場合では、クライアントとサーバの両方がTransport Layer Security(TLS)とHTTP Digest認証の上でHTTPを実装しなければなりません。 サイトSHOULDはTLSの上のダイジェスト認証を使用することでクライアントを認証します、そして、サイトSHOULDは根のサービス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
承認ドキュメント自体はセキュリティ機能を提供する目的のために存在しています--プライバシー。 SIP存在仕様[18]は存在情報を与えることの前に承認機能の用法を必要とします、そして、この仕様はその需要を満たします。 存在承認ドキュメントは彼らが基づいている共通政策形式のプライバシーの特性を引き継ぎます。 この形式は、プライバシー安全になるように設計されています(存在サーバが承認ドキュメントを入手するか、または理解していない場合詳しい情報を決して明らかにすることができないことを意味します)。
Rosenberg Standards Track [Page 23] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[23ページ]。
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.
ユーザに関して望まれているだけではありません。 これはすべての許容が否定的交付金ではなく、情報の積極的な交付金であるという事実の結果です。
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人のクライアントから彼らのプライバシー好みを設定して、それらの存在承認ドキュメントをサーバにアップロードして、次に異なったクライアントからそれらを変更するケースです。 クライアントがドキュメント・フォーマットの異なった部分集合をサポートするなら、どんな情報が明らかにされるかに関してユーザは混乱するかもしれません。 SHOULDが表すサーバからユーザまで存在承認ドキュメントを検索するクライアント、彼らが分からないという規則の情報、ユーザが確信するように、統治されるものは適所にあります。
11. IANA Considerations
11. IANA問題
There are several IANA considerations associated with this specification.
この仕様に関連しているいくつかのIANA問題があります。
11.1. XCAP Application Usage ID
11.1. XCAPアプリケーションUsage ID
This section registers an XCAP Application Usage ID (AUID) according to the IANA procedures defined in [2].
[2]で定義されたIANA手順によると、このセクションはXCAP Application Usage ID(AUID)を登録します。
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.
記述: 存在規則はpresentity[17]が承諾した彼らの存在を見ようとするユーザの許容について説明するドキュメントです。
Rosenberg Standards Track [Page 24] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[24ページ]。
11.2. URN Sub-Namespace Registration
11.2. つぼのサブ名前空間登録
This section registers a new XML namespace, per the guidelines in [11]
このセクションは中に1ガイドラインあたり1つの新しいXML名前空間を登録します。[11]
URI: The URI for this namespace is
urn:ietf:params:xml:ns:pres-rules.
URI: この名前空間のためのURIはつぼ: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 )。
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インチ?」><!DOCTYPE html PUBLIC「-//W3C//DTD XHTML基礎1.0//アン」、「 http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd 、「><html xmlnsが「 http://www.w3.org/1999/xhtml 「><ヘッド><メタhttp-equiv=」content type」内容=と等しい、「テキスト/html;、charset=iso8859、1インチ、/><タイトル>存在は許可声明</h1><h2>つぼのために名前空間</タイトル></ヘッド><ボディー><h1>名前空間を統治します:、」; </h2><p>See<a href=がietf:params:xml:ナノ秒:pres統治する、「 http://www.rfc-editor.org/rfc/rfc5025.txt 「>RFC5025</a>。」; </p></ボディー></html>エンド
11.3. XML Schema Registrations
11.3. XML図式登録証明書
This section registers an XML schema per the procedures in [11].
このセクションは[11]に1手順あたり1つのXML図式を登録します。
URI: urn:ietf:params:xml:schema:pres-rules.
URI: つぼ: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.
セクション7の唯一の内容としてこの図式のためのXMLを見つけることができます。
Rosenberg Standards Track [Page 25] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[25ページ]。
12. Acknowledgements
12. 承認
The author would like to thank Richard Barnes, Jari Urpalainen, Jon Peterson, and Martin Hynar for their comments.
作者は彼らのコメントについてリチャード・バーンズ、ヤリUrpalainen、ジョン・ピーターソン、およびマーチンHynarに感謝したがっています。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[2] ローゼンバーグ(J.、「拡張マークアップ言語(XML)構成アクセス・プロトコル(XCAP)」RFC4825)は2007がそうするかもしれません。
[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.、Bateman、A.、カー、W.、およびJ.ピーターソン、「存在インフォメーション・データは(PIDF)をフォーマットします」、RFC3863、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認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[6] Rosenberg, J., "A Watcher Information Event Template-Package for
the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[6] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のためのウォッチャー情報イベントテンプレートパッケージ」、RFC3857、2004年8月。
[7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[7] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、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.ローゼンバーグ、「共通政策:」 「プライバシー好みを言い表すためのドキュメント・フォーマット」、RFC4745、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.ローゼンバーグ、「RPID:」 「存在情報データの形式(PIDF)への豊かな存在拡大」、RFC4480、2006年7月。
[10] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[10] ローゼンバーグ、J.、「存在のためのデータモデル」、RFC4479、2006年7月。
[11] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
[11] 食事、M.、「IETF XML登録」、BCP81、RFC3688、2004年1月。
[12] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[12]Schulzrinne、2004年12月のH.、「Telephone民数記のためのtel URI」RFC3966。
Rosenberg Standards Track [Page 26] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[26ページ]。
[13] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[13]DuerstとM.とM.Suignard、「国際化しているリソース識別子(虹彩)」、RFC3987、2005年1月。
[14] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[14] ピーターソン、J.、「セッション開始プロトコル(一口)のためのプライバシーメカニズム」、RFC3323、2002年11月。
13.2. Informative References
13.2. 有益な参照
[15] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[15] ピーターソン、J.、およびC.ジョニングス、「セッション開始における認証されたアイデンティティ管理のための増進は(一口)について議定書の中で述べます」、RFC4474、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.ワトソン、「セッション開始への個人的な拡大は断言されたアイデンティティのために信じられたネットワークの中で(一口)について議定書の中で述べます」、RFC3325、2002年11月。
[17] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
2000年2月の[17] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[18] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[18] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のための存在イベントパッケージ」、RFC3856、2004年8月。
Author's Address
作者のアドレス
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサンローゼンバーグシスコのニュージャージーエディソン(米国)
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
メール: jdrosen@cisco.com ユリ: http://www.jdrosen.net
Rosenberg Standards Track [Page 27] RFC 5025 Presence Authorization December 2007
ローゼンバーグStandardsは存在承認2007年12月にRFC5025を追跡します[27ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Rosenberg Standards Track [Page 28]
ローゼンバーグ標準化過程[28ページ]
一覧
スポンサーリンク
