Network Working Group G. Camarillo
Request for Comments: 5361 Ericsson
Category: Standards Track October 2008
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
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]中继使用此类许可文件请求执行翻译的许可。中继被定义为任何SIP服务器，无论是代理服务器、B2BUA（背对背用户代理）还是某种混合服务器，它接收请求并将请求URI转换为一个或多个下一跳URI，然后向其发送请求。
The format for permission documents specified in this document is based on Common Policy [RFC4745], an XML document format for expressing privacy preferences.
本文档中指定的权限文档格式基于公共策略[RFC4745]，这是一种用于表示隐私首选项的XML文档格式。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.
接收请求、将其请求URI转换为一个或多个下一跳URI（即接收方URI）并将请求传递给这些URI的任何SIP服务器，无论是代理服务器、B2BUA（背对背用户代理）还是某种混合服务器。
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和收件人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.
中继将传入请求的请求URI（即目标URI）转换为一个或多个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类型“应用程序/auth策略+xml”。如[RFC4745]所述，此类文档由三部分组成：条件、操作和转换。
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匹配。收件人条件可以包含与标识条件相同的元素和属性。
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发布请求）时，中继将用于请求权限的权限文档的收件人条件与授予或拒绝权限的实体（即发布请求的发件人）的身份相匹配。如果存在匹配项，则收件人条件的计算结果为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.
当这些元素出现在权限文档中时，元素<one>和<except>中的“id”属性必须包含一个方案。
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.
SIP标识[RFC4474]，如[RFC5360]第5.6.1.1节所述。对于使用SIP标识机制进行身份验证的发布请求，发布请求的发送方的标识等于请求的From头字段中的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机制进行身份验证的发布请求，发布请求的发送方的身份等于请求的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请求。返回可路由性测试预计不会使用身份验证，因此，没有定义身份匹配过程。
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.
SIP摘要，如[RFC5360]第5.6.1.4节所述。发送方的身份设置为等于已对自己进行身份验证的用户的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]中定义的标识条件与用作翻译输入的请求发送方的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.
在执行转换时，中继将标识条件与传入请求的发送方的标识相匹配。如果它们匹配，则标识条件的计算结果为TRUE。否则，标识条件的计算结果为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.
由于只能匹配经过身份验证的标识，以下小节定义了可接受的身份验证方式、将发送方标识表示为URI的过程以及转换表单标识符的过程user@domain，出现在<one>和<except>元素的“id”属性中，并转换为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.
断言标识：如果请求包含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]中定义的身份标头字段，并验证请求的From标头字段，则该请求被视为已验证。请注意，即使请求包含表单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
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".
如果中继接收到一个请求，并在域设置为“example.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和一个tel URI[RFC3966]），则每个值都用于[RFC4745]中概述的比较；如果其中任何一个匹配<one>或<except>元素，则将其视为匹配。
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]进行身份验证的请求，发送方的标识等于请求的From标头字段中的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还允许匿名请求。如果请求是匿名的，因为摘要质询/响应使用了“匿名”用户名，则该请求被视为未经身份验证，并且与<identity>条件不匹配。如果请求是匿名的，因为它包含隐私标头字段[RFC3323]，但仍然包含P-Asserted-ID标头字段，则P-Asserted-ID标头字段中的标识仍然用于授权计算；请求是匿名的这一事实对身份处理没有影响。但是，如果请求已穿越信任边界，并且P-Asserted-ID头字段和隐私头字段已被删除，则当请求到达中继时，该请求将被视为未经身份验证，因此与<sender>条件不匹配。最后，如果请求包含已验证的标识标头字段，并且From标头字段包含形式为sip的URI：anonymous@example.com，则认为发送方已通过身份验证，且其身份等于sip：anonymous@example.com. 如果将这样一个标识放入<one>或<except>元素中，就会有一个匹配项。
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>或<except>条件不包含方案，“id”属性中的值到SIP URI的转换非常简单。如果“id”属性中的字符是SIP URI的用户和hostpart组件的有效字符，则会在“id”属性的内容后附加一个“SIP:”，结果就是SIP URI。如果“id”属性中的字符对SIP URI的用户和hostpart组件无效，则无法进行转换，因此，标识条件的计算结果为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匹配。目标条件可以包含与标识条件相同的元素和属性。
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.
<validity>元素不适用于本文件。如[RFC5360]第5.8节所述，每个<permission>元素都有无限的生存期，可以使用独立的机制撤销。在任何情况下，如[RFC5360]第4.1节所述，仅当授予权限的上下文有效时，权限才有效。如果存在，<validity>元素必须被忽略。
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.
每个策略规则至少包含两个<trans handling>元素；一个元素具有要授予的URI，另一个元素具有要拒绝权限的URI。
The <trans-handling> provides URIs for a recipient to grant or deny the relay permission to perform a translation. The defined values are:
<trans handling>为收件人提供URI，以授予或拒绝中继权限以执行翻译。定义的值为：
deny: this action tells the relay not to perform the translation.
拒绝：此操作告诉继电器不要执行转换。
grant: this action tells the server to perform the translation.
grant：此操作告诉服务器执行翻译。
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
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，收件人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 |
| |
+---------------------+
+--------+ +--------------------------------+ 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"?>
<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">
<?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"/>
<!-- 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>
<!-- 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: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>
</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:approvement rules”命名空间中没有扩展点的元素。使用这些元素定义的实例文档应该是架构有效的。处理包含应用程序无法理解的内容的实例文档的应用程序必须忽略该内容。本规范的IETF扩展文档可以重用“urn:IETF:params:xml:ns:approvement 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
URI: urn:ietf:params:xml:ns:consent-rules
Registrant Contact: IETF SIPPING working group <sipping@ietf.org>,
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
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
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
URI: urn:ietf:params:xml:schema:consent-rules
Registrant Contact: IETF SIPPING working group <sipping@ietf.org>,
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
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.
乔纳森·罗森博格就这份文件提供了有用的想法。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.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年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：会话启动协议”，RFC 3261，2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，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.和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 47452007年2月。
[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.，“电话号码的电话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 33252002年11月。
Author's Address
作者地址
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.