[要約] RFC 5361は、同意を要求するためのドキュメント形式を定義しています。その目的は、ユーザーに対して明確で一貫性のある同意要求を提供することです。
Network Working Group G. Camarillo
Request for Comments: 5361 Ericsson
Category: Standards Track October 2008
A Document Format for Requesting Consent
同意を要求するためのドキュメント形式
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request a specific recipient permission to perform a particular routing translation.
このドキュメントでは、同意を要求するために使用される許可文書の拡張可能なマークアップ言語（XML）形式を定義します。この形式で記述された許可ドキュメントは、特定のルーティング翻訳を実行するために特定の受信者の許可を要求するためにリレーによって使用されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Terminology . . . . . . . . . . . . . . . . . 2
3. Permission Document Structure . . . . . . . . . . . . . . . . 3
3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Recipient Condition . . . . . . . . . . . . . . . . . 3
3.1.2. Identity Condition . . . . . . . . . . . . . . . . . . 4
3.1.3. Target Condition . . . . . . . . . . . . . . . . . . . 6
3.1.4. Validity Condition . . . . . . . . . . . . . . . . . . 7
3.1.5. Sphere Condition . . . . . . . . . . . . . . . . . . . 7
3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Translation Handling . . . . . . . . . . . . . . . . . 7
4. Example Document . . . . . . . . . . . . . . . . . . . . . . . 7
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. XML Namespace Registration . . . . . . . . . . . . . . . . 11
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
The framework for consent-based communications in the Session Initiation Protocol (SIP) [RFC5360] identifies the need for a format to create permission documents. Such permission documents are used by SIP [RFC3261] relays to request permission to perform translations. A relay is defined as any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some hybrid, which receives a request and translates the Request-URI into one or more next-hop URIs to which it then delivers a request.
セッション開始プロトコル（SIP）[RFC5360]の同意ベースのコミュニケーションのフレームワークは、許可ドキュメントを作成するフォーマットの必要性を特定します。このような許可文書は、SIP [RFC3261]リレーで使用され、翻訳を実行する許可を要求します。リレーは、プロキシ、B2BUA（連続したユーザーエージェント）、またはリクエストを受信してリクエスト-URIを1つ以上の次のホップURIに変換するハイブリッドなど、任意のSIPサーバーとして定義されます。次に、リクエストを配信します。
The format for permission documents specified in this document is based on Common Policy [RFC4745], an XML document format for expressing privacy preferences.
このドキュメントで指定されている許可文書の形式は、プライバシー設定を表現するためのXMLドキュメント形式であるCommon Policy [RFC4745]に基づいています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This document uses the terms defined in [RFC5360]. For completeness, these terms are repeated here. Figure 1 of [RFC5360] shows the relationship between target and recipient URIs in a translation operation.
このドキュメントでは、[RFC5360]で定義されている用語を使用します。完全に、これらの用語はここで繰り返されます。[RFC5360]の図1は、翻訳操作におけるターゲットと受信者のURIの関係を示しています。
Recipient URI:
受信者URI：
The Request-URI of an outgoing request sent by an entity (e.g., a user agent or a proxy). The sending of such request can have been the result of a translation operation.
エンティティから送信された発信要求のリクエスト-URI（例：ユーザーエージェントまたはプロキシ）。そのような要求の送信は、翻訳操作の結果である可能性があります。
Relay:
リレー：
Any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some hybrid, that receives a request, translates its Request-URI into one or more next-hop URIs (i.e., recipient URIs), and delivers the request to those URIs.
任意のSIPサーバーは、プロキシ、B2BUA（連続したユーザーエージェント）、またはリクエストを受け取るハイブリッドで、リクエスト-URIを1つまたは複数の次のHOP URI（つまり、受信者）に変換します。それらのウリスにリクエストを配信します。
Target URI:
ターゲットURI：
The Request-URI of an incoming request that arrives to a relay that will perform a translation operation.
翻訳操作を実行するリレーに到達する着信要求のリクエスト-uri。
Translation logic:
翻訳ロジック：
The logic that defines a translation operation at a relay. This logic includes the translation's target and recipient URIs.
リレーで翻訳操作を定義するロジック。このロジックには、翻訳のターゲットと受信者のURIが含まれます。
Translation operation:
翻訳操作：
Operation by which a relay translates the Request-URI of an incoming request (i.e., the target URI) into one or more URIs (i.e., recipient URIs) that are used as the Request-URIs of one or more outgoing requests.
リレーが、1つまたは複数の発信要求のリクエスト-urisとして使用される1つまたは複数のURI（つまり、受信者URI）に、着信要求（つまり、ターゲットURI）のリクエストURIを変換する操作。
A permission document is an XML document, formatted according to the schema defined in [RFC4745]. Permission documents inherit the MIME type of common policy documents, 'application/auth-policy+xml'. As described in [RFC4745], this type of document is composed of three parts: conditions, actions, and transformations.
許可文書は、[RFC4745]で定義されているスキーマに従ってフォーマットされたXMLドキュメントです。許可文書は、一般的なポリシードキュメントのMIMEタイプ「Application/Auth-Policy XML」を継承します。[RFC4745]で説明されているように、このタイプのドキュメントは、条件、アクション、変換の3つの部分で構成されています。
This section defines the new conditions and actions defined by this specification. This specification does not define any new transformation.
このセクションでは、この仕様で定義された新しい条件とアクションを定義します。この仕様は、新しい変換を定義しません。
The conditions in a permission document are a set of expressions, each of which evaluates to either TRUE or FALSE. Note that, as discussed in [RFC4745], a permission document applies to a translation if all the expressions in its conditions part evaluate to TRUE.
許可文書の条件は一連の式であり、それぞれがtrueまたはfalseのいずれかと評価されます。[RFC4745]で説明したように、その条件のすべての式がtrueと評価された場合、許可文書は翻訳に適用されることに注意してください。
The recipient condition is matched against the recipient URI of a translation. Recipient conditions can contain the same elements and attributes as identity conditions.
受信者の状態は、翻訳の受信者URIと一致します。受信者の条件には、ID条件と同じ要素と属性を含めることができます。
When performing a translation, a relay matches the recipient condition of the permission document that was used to request permission for that translation against the destination URI of the outgoing request. When receiving a request granting or denying permissions (e.g., a SIP PUBLISH request as described in [RFC5360]), the relay matches the recipient condition of the permission document that was used to request permission against the identity of the entity granting or denying permissions (i.e., the sender of the PUBLISH request). If there is a match, the recipient condition evaluates to TRUE. Otherwise, the recipient condition evaluates to FALSE.
翻訳を実行するとき、リレーは、発信要求の宛先URIに対するその翻訳の許可を要求するために使用された許可文書の受信者条件と一致します。[RFC5360]に記載されているように、許可の付与または拒否許可（たとえば、SIP公開要求）を受信した場合、リレーは、許可を付与または拒否するエンティティのIDに対して許可を要求するために使用された許可文書の受信者条件（許可文書の受信者条件）と一致します（許可を付与または拒否します（つまり、公開要求の送信者）。一致がある場合、受信者の状態はtrueに評価されます。それ以外の場合、受信者の状態はfalseに評価されます。
Since only authenticated identities can be matched, this section defines acceptable means of authentication, which are in line with those described in Section 5.6.1 of [RFC5360].
認証されたアイデンティティのみが一致する可能性があるため、このセクションでは、[RFC5360]のセクション5.6.1に記載されているものと一致する許容可能な認証手段を定義します。
The 'id' attribute in the elements <one> and <except> MUST contain a scheme when these elements appear in a permission document.
要素の「ID」属性は、<one>および<を除き<を除いて、これらの要素が許可ドキュメントに表示されるときにスキームを含める必要があります。
When used with SIP, a recipient granting or denying a relay permissions is considered authenticated if one of the following techniques is used:
SIPとともに使用する場合、受信者は、次の手法のいずれかが使用されている場合、リレーアクセス許可を付与または拒否していると見なされます。
SIP Identity [RFC4474], as described in Section 5.6.1.1 of [RFC5360]. For PUBLISH requests that are authenticated using the SIP Identity mechanism, the identity of the sender of the PUBLISH request is equal to the SIP URI in the From header field of the request, assuming that the signature in the Identity header field has been validated.
[RFC5360]のセクション5.6.1.1で説明されているように、SIP ID [RFC4474]。SIPアイデンティティメカニズムを使用して認証されたパブリッシュリクエストの場合、パブリッシュリクエストの送信者のIDは、アイデンティティヘッダーフィールドの署名が検証されていると仮定して、リクエストのヘッダーフィールドのSIP URIに等しくなります。
P-Asserted-Identity [RFC3325] (which can only be used in closed network environments) as described in Section 5.6.1.2 of [RFC5360]. For PUBLISH requests that are authenticated using the P-Asserted-Identity mechanism, the identity of the sender of the PUBLISH request is equal to the P-Asserted-Identity header field of the request.
[RFC5360]のセクション5.6.1.2に記載されているように、P-Asserted-Identity [RFC3325]（閉じたネットワーク環境でのみ使用できます）。p-asserted-Identityメカニズムを使用して認証されたパブリックリクエストの場合、パブリックリクエストの送信者のIDは、リクエストのp asserted-Identityヘッダーフィールドに等しくなります。
Return Routability Test, as described in Section 5.6.1.3 of [RFC5360]. It can be used for SIP PUBLISH and HTTP GET requests. No authentication is expected to be used with return routability tests and, therefore, no identity matching procedures are defined.
[RFC5360]のセクション5.6.1.3で説明されているように、ルーティング可能性テストを返します。SIPパブリッシュおよびHTTP Get Requestsに使用できます。返品ルー上のテストでは認証は使用されないため、IDの一致手順は定義されていません。
SIP digest, as described in Section 5.6.1.4 of [RFC5360]. The identity of the sender is set equal to the SIP Address of Record (AOR) for the user that has authenticated themselves.
[RFC5360]のセクション5.6.1.4で説明されているように、SIPダイジェスト。送信者の身元は、自分自身を認証したユーザーのSIPレコード（AOR）に等しく設定されます。
The identity condition, which is defined in [RFC4745], is matched against the URI of the sender of the request that is used as input for a translation.
[RFC4745]で定義されているID条件は、翻訳の入力として使用されるリクエストの送信者のURIと一致します。
When performing a translation, a relay matches the identity condition against the identity of the sender of the incoming request. If they match, the identity condition evaluates to TRUE. Otherwise, the identity condition evaluates to FALSE.
翻訳を実行するとき、リレーは、着信要求の送信者のIDと同一性条件と一致します。それらが一致する場合、アイデンティティ条件はtrueに評価されます。それ以外の場合、ID条件はfalseに評価されます。
Since only authenticated identities can be matched, the following subsections define acceptable means of authentication, the procedure for representing the identity of the sender as a URI, and the procedure for converting an identifier of the form user@domain, present in the 'id' attribute of the <one> and <except> elements, into a URI.
認証されたアイデンティティのみを一致させることができるため、次のサブセクションは、認証の許容可能な手段、送信者のIDをURIとして表す手順、および「ID」に存在するフォームuser@domainの識別子を変換する手順を定義します。<one>および<exceent>要素の属性、URIへ。
When used with SIP, a request sent by a sender is considered authenticated if one of the following techniques is used:
SIPで使用する場合、次の手法のいずれかが使用されている場合、送信者から送信されたリクエストが認証されていると見なされます。
SIP Digest: the relay authenticates the sender using SIP digest authentication [RFC2617]. However, if the anonymous authentication described on page 194 of [RFC3261] is used, the sender is not considered authenticated.
SIPダイジェスト：リレーは、SIPダイジェスト認証[RFC2617]を使用して送信者を認証します。ただし、[RFC3261]の194ページに記載されている匿名認証が使用されている場合、送信者は認証されているとは見なされません。
Asserted Identity: if a request contains a P-Asserted-ID header field [RFC3325] and the request is coming from a trusted element, the sender is considered authenticated.
主張されたID：リクエストにP-Asserted-IDヘッダーフィールド[RFC3325]が含まれており、リクエストが信頼できる要素からのものである場合、送信者は認証されていると見なされます。
Cryptographically Verified Identity: if a request contains an Identity header field as defined in [RFC4474], and it validates the From header field of the request, the request is considered to be authenticated. Note that this is true even if the request contained a From header field of the form sip:anonymous@example.com. As long as the signature verifies that the request legitimately came from this identity, it is considered authenticated.
暗号化された検証済みアイデンティティ：[RFC4474]で定義されているアイデンティティヘッダーフィールドが含まれている場合、リクエストのヘッダーフィールドを検証する場合、リクエストは認証されていると見なされます。リクエストにフォームSIP：anonymous@example.comのヘッダーフィールドが含まれていても、これは真実であることに注意してください。要求がこのアイデンティティから合法的に来たことを署名が確認している限り、それは認証されていると見なされます。
For requests that are authenticated using SIP Digest, the identity of the sender is set equal to the SIP Address of Record (AOR) for the user that has authenticated themselves. For example, consider the following "user record" in a database:
SIPダイジェストを使用して認証されているリクエストの場合、送信者の身元は、自分自身を認証したユーザーのSIPアドレス（AOR）に等しく設定されます。たとえば、データベースの次の「ユーザーレコード」を考慮してください。
SIP AOR: sip:alice@example.com
digest username: ali
digest password: f779ajvvh8a6s6
digest realm: example.com
If the relay receives a request and challenges it with the realm set to "example.com", and the subsequent request 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".
リレーがリクエストを受信し、「embly.com」に設定された領域でそれに挑戦し、その後のリクエストには、「Ali」のユーザー名とパスワード「F779AJVVH8A6S6」で生成されたダイジェスト応答を備えた認証ヘッダーフィールドが含まれています。マッチング操作で使用されるのは、「sip：alice@example.com」です。
For requests that are authenticated using [RFC3325], the identity of the sender is equal to the SIP URI in the P-Asserted-ID header field. If there are multiple values for the P-Asserted-ID header field (there can be one sip URI and one tel URI [RFC3966]), then each of them is used for the comparisons outlined in [RFC4745]; if either of them match a <one> or <except> element, it is considered a match.
[RFC3325]を使用して認証されているリクエストの場合、送信者の身元はP-Asserted-IDヘッダーフィールドのSIP URIに等しくなります。P-Asserted-IDヘッダーフィールドに複数の値がある場合（SIP URIと1つのTel URI [RFC3966] 1つのSIP URIがあります）、それぞれが[RFC4745]で概説されている比較に使用されます。どちらかがA <one>または<例外>要素に一致する場合、一致と見なされます。
For requests that are authenticated using the SIP Identity mechanism [RFC4474], identity of the sender is equal to the SIP URI in the From header field of the request, assuming that the signature in the Identity header field has been validated.
SIPアイデンティティメカニズム[RFC4474]を使用して認証されたリクエストの場合、送信者のIDは、IDヘッダーフィールドの署名が検証されていると仮定して、リクエストのヘッダーフィールドのSIP URIに等しくなります。
SIP also allows for anonymous requests. If a request is anonymous because the digest challenge/response used the "anonymous" username, the request is considered unauthenticated and will not match the <identity> condition. If a request is anonymous because it contains a Privacy header field [RFC3323], but still contains a P-Asserted-ID header field, the identity in the P-Asserted-ID header field is still used in the authorization computations; the fact that the request was anonymous has no impact on the identity processing. However, if the request had traversed a trust boundary and the P-Asserted-ID header field and the Privacy header field had been removed, the request will be considered unauthenticated when it arrives at the relay, and thus not match the <sender> condition. Finally, if a request contained an Identity header field that was validated, and the From header field contained a URI of the form sip:anonymous@example.com, then the sender is considered authenticated, and it will have an identity equal to sip:anonymous@example.com. Had such an identity been placed into a <one> or <except> element, there will be a match.
SIPも匿名のリクエストを許可します。ダイジェストチャレンジ/応答が「匿名」ユーザー名を使用したためにリクエストが匿名である場合、リクエストは認識されていないと見なされ、<idention>条件と一致しません。リクエストがプライバシーヘッダーフィールド[RFC3323]を含むため匿名であるが、P-Asserted-IDヘッダーフィールドがまだ含まれている場合、P-Asserted-IDヘッダーフィールドのIDが認証計算で使用されています。リクエストが匿名であるという事実は、ID処理に影響を与えません。ただし、リクエストが信頼の境界とP asserted-idヘッダーフィールドを通過し、プライバシーヘッダーフィールドが削除された場合、リレーはリレーに到達した場合、<sender>条件と一致しない場合、リクエストは認識されないと見なされます。。最後に、リクエストに検証されたアイデンティティヘッダーフィールドが含まれ、Fromヘッダーフィールドにsip：anonymous@example.comのURIが含まれている場合、送信者は認証されていると見なされ、SIPに等しいアイデンティティがあります。anonymous@example.com。そのようなアイデンティティが<one>または<を除く>要素に配置されていれば、一致があります。
If the <one> or <except> condition does not contain a scheme, conversion of the value in the 'id' attribute to a SIP URI is done trivially. If the characters in the 'id' attribute are valid characters for the user and hostpart components of the SIP URI, a 'sip:' is appended to the contents of the 'id' attribute, and the result is the SIP URI. If the characters in the 'id' attribute are not valid for the user and hostpart components of the SIP URI, conversion is not possible and, thus, the identity condition evaluates to FALSE. This happens, for example, when the user portion of the 'id' attribute contains UTF-8 characters.
<one>または<exceent>条件にスキームが含まれていない場合、sip URIへの「ID」属性の値の変換は簡単に行われます。「ID」属性の文字がSIP URIのユーザーおよびHostPARTコンポーネントの有効な文字である場合、「SIP：」が「ID」属性の内容に追加され、結果はSIP URIです。「ID」属性の文字がSIP URIのユーザーおよびHostPartコンポーネントに対して有効でない場合、変換は不可能であるため、ID条件はFALSEに評価されます。これは、たとえば、「ID」属性のユーザー部分にUTF-8文字が含まれている場合に発生します。
The target condition is matched against the target URI of a translation. The target condition can contain the same elements and attributes as identity conditions.
ターゲット条件は、翻訳のターゲットURIと一致します。ターゲット条件には、ID条件と同じ要素と属性を含めることができます。
When performing a translation, a relay matches the target condition against the destination of the incoming request, which is typically contained in the Request-URI. If they match, the target condition evaluates to TRUE. Otherwise, the target condition evaluates to FALSE.
翻訳を実行するとき、リレーは、通常、リクエスト-URIに含まれる着信要求の宛先とターゲット条件と一致します。それらが一致した場合、ターゲット条件はtrueに評価されます。それ以外の場合、ターゲット条件はfalseに評価されます。
The <validity> element is not applicable to this document. Each <permission> element has an infinite lifetime and can be revoked using an independent mechanism, as described in Section 5.8 of [RFC5360]. In any case, as discussed in Section 4.1 of [RFC5360], permissions are only valid as long as the context where they were granted is valid. If present, <validity> elements MUST be ignored.
<妥当性>要素は、このドキュメントには適用されません。各<許可>要素には無限の寿命があり、[RFC5360]のセクション5.8で説明されているように、独立したメカニズムを使用して取り消すことができます。いずれにせよ、[RFC5360]のセクション4.1で説明したように、許可は認められたコンテキストが有効である限り有効です。存在する場合、<妥当性>要素は無視する必要があります。
The <sphere> element is not applicable to this document and therefore is not used. If present, <sphere> elements MUST be ignored.
<sphere>要素はこのドキュメントには適用できないため、使用されません。存在する場合、<sphere>要素は無視する必要があります。
The actions in a permission document provide URIs to grant or deny permission to perform the translation described in the document.
許可文書のアクションは、URIがドキュメントに記載されている翻訳を実行する許可を許可または拒否することを提供します。
Note that the <trans-handling> element is not an action, as defined in Common Policy [RFC4745], but rather an informational element. Therefore, the conflict resolution mechanism does not apply to it.
<Trans-Handling>要素は、共通ポリシー[RFC4745]で定義されているように、アクションではなく、情報要素であることに注意してください。したがって、紛争解決メカニズムはそれには適用されません。
Each policy rule contains at least two <trans-handling> elements; one element with a URI to grant and another with a URI to deny permission.
各ポリシールールには、少なくとも2つの<トランスハンドリング>要素が含まれています。許可を与えるURIを備えた1つの要素と、許可を拒否するURIを持つもう1つの要素。
The <trans-handling> provides URIs for a recipient to grant or deny the relay permission to perform a translation. The defined values are:
<トランスハンドリング>は、受信者が翻訳を実行するためのリレーの許可を許可または拒否するためのURIを提供します。定義された値は次のとおりです。
deny: this action tells the relay not to perform the translation.
拒否：このアクションは、リレーに翻訳を実行しないように指示します。
grant: this action tells the server to perform the translation.
助成金：このアクションは、サーバーに翻訳を実行するように指示します。
The 'perm-uri' attribute in the <trans-handling> element provides a URI to grant or deny permission to perform a translation.
<Trans-Handling>要素の「Perm-uri」属性は、翻訳を実行する許可を付与または拒否するURIを提供します。
In the following example, a client adds 'sip:bob@example.org' to the translation whose target URI is 'sip:alices-friends@example.com'. The relay handling the translation generates the following permission document in order to ask for permission to relay requests sent to 'sip:alices-friends@example.com' to 'sip:bob@example.org'. The target URI is 'sip:alices-friends@example.com', and the recipient URI is 'sip:bob@example.org'. The sender's identity does not play a role in this example. Therefore, the permission document does not put any restriction on potential senders.
次の例では、クライアントはターゲットURIが「sip：alices-friends@example.com」である翻訳に「sip：bob@example.org」を追加します。翻訳のリレーの取り扱いは、「sip：alices-friends@example.com」に送信されるリクエストをリレーする許可を求めるために、次の許可文書を生成します。ターゲットURIは「sip：alices-friends@example.com」であり、受信者のuriは「sip：bob@example.org」です。送信者の身元は、この例では役割を果たしません。したがって、許可文書は、潜在的な送信者に制限を課しません。
+--------+ +--------------------------------+ Permission
| | | | Request
| Client | | Relay | with
| | | sip:alices-friends@example.com | Permission
+--------+ | | Document
| |+-------+ |-------------+
| ||Transl.| | |
|Manipulation ||Logic | | |
+------------>|+-------+ | |
Add +--------------------------------+ |
sip:bob@example.org V
+---------------------+
| |
| Recipient |
| sip:bob@example.org |
| |
+---------------------+
<?xml version="1.0" encoding="UTF-8"?>
<cp:ruleset
xmlns="urn:ietf:params:xml:ns:consent-rules"
xmlns:cp="urn:ietf:params:xml:ns:common-policy">
<cp:rule id="f1">
<cp:conditions>
<cp:identity>
<cp:many/>
</cp:identity>
<recipient>
<cp:one id="sip:bob@example.org"/>
</recipient>
<target>
<cp:one id="sip:alices-friends@example.com"/>
</target>
</cp:conditions>
<cp:actions>
<trans-handling
perm-uri="sips:grant-1awdch5Fasddfce34@example.com"
>grant</trans-handling>
<trans-handling
perm-uri="https://example.com/grant-1awdch5Fasddfce34"
>grant</trans-handling>
<trans-handling
perm-uri="sips:deny-23rCsdfgvdT5sdfgye@example.com"
>deny</trans-handling>
<trans-handling
perm-uri="https://example.com/deny-23rCsdfgvdT5sdfgye"
>deny</trans-handling>
</cp:actions>
<cp:transformations/>
</cp:rule>
</cp:ruleset>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:consent-rules"
xmlns:cr="urn:ietf:params:xml:ns:consent-rules"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- Conditions -->
<xs:element name="recipient" type="cp:identityType"/>
<xs:element name="target" type="cp:identityType"/>
<!-- Actions -->
<xs:simpleType name="trans-values">
<xs:restriction base="xs:string">
<xs:enumeration value="deny"/>
<xs:enumeration value="grant"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="trans-handling">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="trans-values">
<xs:attribute name="perm-uri" type="xs:anyURI"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
This specification defines elements that do not have extension points in the "urn:ietf:params:xml:ns:consent-rules" namespace. Instance documents that utilize these element definitions SHOULD be schema valid. Applications processing instance documents with content that is not understood by the application MUST ignore that content. IETF extension documents of this specification MAY reuse the "urn:ietf:params:xml:ns:consent-rules" namespace to define new elements.
この仕様では、「urn：ietf：params：xml：ns：consence-rules」名前空間に拡張ポイントがない要素を定義します。これらの要素定義を利用するインスタンスドキュメントは、スキーマ有効である必要があります。アプリケーションでは、アプリケーションが理解していないコンテンツを含むアプリケーション処理インスタンスインスタンスドキュメントは、そのコンテンツを無視する必要があります。この仕様のIETF拡張ドキュメントでは、「urn：ietf：params：xml：ns：consect-rules」名前空間を再利用する場合があります。新しい要素を定義します。
This section registers a new XML namespace and a new XML schema per the procedures in [RFC3688].
このセクションでは、[RFC3688]の手順ごとに、新しいXMLネームスペースと新しいXMLスキーマを登録します。
URI: urn:ietf:params:xml:ns:consent-rules
Registrant Contact: IETF SIPPING working group <sipping@ietf.org>,
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
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>Consent Rules Namespace</title>
</head>
<body>
<h1>Namespace for Permission Documents</h1>
<h2>urn:ietf:params:xml:ns:consent-rules</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5361.txt">RFC 5361
</a>.</p>
</body>
</html>
END
URI: urn:ietf:params:xml:schema:consent-rules
Registrant Contact: IETF SIPPING working group <sipping@ietf.org>,
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
XML: The XML schema to be registered is contained in Section 5.
XML：登録するXMLスキーマは、セクション5に含まれています。
RFC 5360 [RFC5360] discusses security-related issues, such as how to authenticate SIP and HTTP requests granting permissions and how to transport permission documents between relays and recipients, that are directly related to this specification.
RFC 5360 [RFC5360]は、SIPおよびHTTPリクエストの許可を認証する方法や、この仕様に直接関連するリレーと受信者の間で許可文書を輸送する方法など、セキュリティ関連の問題について説明します。
Jonathan Rosenberg provided useful ideas on this document. Hannes Tschofenig helped align this document with common policy. Ben Campbell and Mary Barnes performed a thorough review of this document. Lakshminath Dondeti provided useful comments.
Jonathan Rosenbergは、この文書に有用なアイデアを提供しました。Hannes Tschofenigは、このドキュメントを共通のポリシーに合わせるのを助けました。ベン・キャンベルとメアリー・バーンズは、この文書の徹底的なレビューを行いました。Lakshminath dondetiは有用なコメントを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2617] 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.
[RFC2617] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[RFC3261] 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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[RFC4745] 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.
[RFC4745] Schulzrinne、H.、Tschofenig、H.、Morris、J.、Cuellar、J.、Polk、J。、およびJ. Rosenberg、「共通政策：プライバシーの好みを表現するためのドキュメント形式」、RFC 4745、2月2007年。
[RFC5360] Rosenberg, J., Camarillo, G., and D. Willis, "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", RFC 5360, October 2008.
[RFC5360] Rosenberg、J.、Camarillo、G。、およびD. Willis、「セッション開始プロトコル（SIP）における同意ベースのコミュニケーションのフレームワーク」、RFC 5360、2008年10月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinne、H。、「電話番号のTel URI」、RFC 3966、2004年12月。
[RFC3325] 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.
[RFC3325] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内の主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
Author's Address
著者の連絡先
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。