draft-ietf-sipping-consent-format-03.txt   draft-ietf-sipping-consent-format-04.txt 
SIPPING G. Camarillo SIPPING G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track April 24, 2007 Intended status: Standards Track October 2, 2007
Expires: October 26, 2007 Expires: April 4, 2008
A Document Format for Requesting Consent A Document Format for Requesting Consent
draft-ietf-sipping-consent-format-03.txt draft-ietf-sipping-consent-format-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 26, 2007. This Internet-Draft will expire on April 4, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines an Extensible Markup Language (XML) format for This document defines an Extensible Markup Language (XML) format for
a permission document used to request consent. A permission document a permission document used to request consent. A permission document
written in this format is used by a relay to request a specific written in this format is used by a relay to request a specific
recipient permission to perform a particular routing translation. recipient permission to perform a particular routing translation.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
3. Permission Document Structure . . . . . . . . . . . . . . . . 3 3. Permission Document Structure . . . . . . . . . . . . . . . . 4
3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Identity Condition . . . . . . . . . . . . . . . . . . 4 3.1.1. Recipient Condition . . . . . . . . . . . . . . . . . 4
3.1.2. Sender Condition . . . . . . . . . . . . . . . . . . . 5 3.1.2. Identity Condition . . . . . . . . . . . . . . . . . . 5
3.1.3. Target Condition . . . . . . . . . . . . . . . . . . . 7 3.1.3. Target Condition . . . . . . . . . . . . . . . . . . . 7
3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.4. Validity Condition . . . . . . . . . . . . . . . . . . 8
3.2.1. Translation Handling . . . . . . . . . . . . . . . . . 7 3.1.5. Sphere Condition . . . . . . . . . . . . . . . . . . . 8
4. Example Document . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Translation Handling . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. Example Document . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. XML Namespace Registration . . . . . . . . . . . . . . . . 9 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6.1. XML Namespace Registration . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
The framework for consent-based communications in the Session The framework for consent-based communications in the Session
Initiation Protocol (SIP) [9] identifies the need for a format to Initiation Protocol (SIP) [I-D.ietf-sip-consent-framework] identifies
create permission documents. Such permission documents are used by the need for a format to create permission documents. Such
SIP [3] relays to request permission to perform translations. A permission documents are used by SIP [RFC3261] relays to request
relay is defined as any SIP server, be it a proxy, B2BUA (Back-to- permission to perform translations. A relay is defined as any SIP
Back User Agent), or some hybrid, which receives a request and server, be it a proxy, B2BUA (Back-to-Back User Agent), or some
translates the request URI into one or more next hop URIs to which it hybrid, which receives a request and translates the request URI into
then delivers a request. one or more next hop URIs to which it then delivers a request.
The format for permission documents specified in this document is The format for permission documents specified in this document is
based on the XML document format for expressing Privacy Preferences based on Common Policy [RFC4745], an XML document format for
[8]. expressing privacy preferences.
2. Definitions and Terminology 2. Definitions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [RFC2119].
Relay: Any SIP server, be it a proxy, B2BUA (Back-to-Back User This document uses the terms defined in
Agent), or some hybrid, that receives a request, translates its [I-D.ietf-sip-consent-framework]. For completeness, these terms are
Request-URI into one or more next-hop URIs (i.e., recipient URIs), repeated here. Figure 1 of [I-D.ietf-sip-consent-framework] shows
and delivers the request to those URIs. the relationship between target and recipient URIs in a translation
operation.
Recipient URI: The Request-URI of an outgoing request sent by an Recipient URI:
entity (e.g., a user agent or a proxy). The sending of such
request may have been the result of a translation operation.
Target URI: The Request-URI of an incoming request that arrives to The Request-URI of an outgoing request sent by an entity (e.g., a
an entity (e.g., a proxy) that will perform a translation user agent or a proxy). The sending of such request can have been
operation. the result of a translation operation.
Translation operation: Operation by which an entity (e.g., a proxy) Relay:
translates the request URI of an incoming request (i.e., the
target URI) into one or more URIs (i.e., recipient URIs) which are Any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or
used as the request URIs of one or more outgoing requests. 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.
Target URI:
The Request-URI of an incoming request that arrives to a relay
that will perform a translation operation.
Translation logic:
The logic that defines a translation operation at a relay. This
logic includes the translation's target and recipient URIs.
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) which are used as the Request- URIs of one
or more outgoing requests.
3. Permission Document Structure 3. Permission Document Structure
A permission document is an XML document, formatted according to the A permission document is an XML document, formatted according to the
schema defined in [8]. Permission documents inherit the MIME type of schema defined in [RFC4745]. Permission documents inherit the MIME
common policy documents, 'application/auth-policy+xml'. As described type of common policy documents, 'application/auth-policy+xml'. As
in [8], this type of document is composed of three parts: conditions, described in [RFC4745], this type of document is composed of three
actions, and transformations. However, even though permission parts: conditions, actions, and transformations.
documents need to have a transformation part to comply to the common
policy syntax, effectively, permission documents do not make any use
of transformations.
This section defines the new conditions and actions defined by this This section defines the new conditions and actions defined by this
specification. This specification does not define any new specification. This specification does not define any new
transformation. transformation.
3.1. Conditions 3.1. Conditions
Note that, as discussed in [8], a permission document applies to a Note that, as discussed in [RFC4745], a permission document applies
translation if all the expressions in its conditions part evaluate to to a translation if all the expressions in its conditions part
TRUE. evaluate to TRUE.
3.1.1. Identity Condition 3.1.1. Recipient Condition
The identity condition, defined in [8], is matched against the The recipient condition is matched against the recipient URI of a
recipient URI of a translation. translation. Recipient conditions can contain the same elements and
attributes as identity conditions.
When performing a translation, a relay matches the identity condition When performing a translation, a relay matches the recipient
of the permission document that was used to request permission for condition of the permission document that was used to request
that translation against the destination URI of the outgoing request. permission for that translation against the destination URI of the
When receiving a request granting or denying permissions (e.g., a SIP outgoing request. When receiving a request granting or denying
PUBLISH request as described in [9]), the relay matches the identity permissions (e.g., a SIP PUBLISH request as described in
[I-D.ietf-sip-consent-framework]), the relay matches the recipient
condition of the permission document that was used to request condition of the permission document that was used to request
permission against the identity of the entity granting or denying permission against the identity of the entity granting or denying
permissions (i.e., the sender of the PUBLISH request). permissions (i.e., the sender of the PUBLISH request).
The <identity> element is defined in [8], which indicates that the This section defines acceptable means of authentication, which are in
specific usages of the framework document need to define details that line with those described in Section 5.6.1 of
are protocol and usage specific. In particular, this section defines [I-D.ietf-sip-consent-framework].
acceptable means of authentication.
The 'id' attribute in the elements <one> and <except> MUST contain a The 'id' attribute in the elements <one> and <except> MUST contain a
scheme when these elements appear in a permission document. scheme when these elements appear in a permission document.
When used with SIP, a recipient granting or denying a relay When used with SIP, a recipient granting or denying a relay
permissions is considered authenticated if one of the following permissions is considered authenticated if one of the following
techniques is used: techniques is used:
SIP Identity [7], as described in [9]. For PUBLISH requests that SIP Identity [RFC4474], as described in Section 5.6.1.1 of
are authenticated using the SIP Identity mechanism, the identity [I-D.ietf-sip-consent-framework]. For PUBLISH requests that are
of the sender of the PUBLISH request is equal to the SIP URI in authenticated using the SIP Identity mechanism, the identity of
the From header field of the request, assuming that the signature the sender of the PUBLISH request is equal to the SIP URI in the
in the Identity header field has been validated. From header field of the request, assuming that the signature in
the Identity header field has been validated.
P-Asserted-Identity [5], as described in [9]. For PUBLISH requests P-Asserted-Identity [RFC3325], as described in Section 5.6.1.2 of
that are authenticated using the P-Asserted-Identity mechanism, [I-D.ietf-sip-consent-framework]. For PUBLISH requests that are
the identity of the sender of the PUBLISH request is equal to the 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. P-Asserted-Identity header field of the request.
Return Routability Test, as described in [9]. Return Routability Test, as described in Section 5.6.1.3 of
[I-D.ietf-sip-consent-framework]. 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.
SIP digest, as described in [9]. SIP digest, as described in Section 5.6.1.4 of
[I-D.ietf-sip-consent-framework]. The identity of the sender is
set equal to the SIP Address of Record (AOR) for the user that has
authenticated themselves.
3.1.2. Sender Condition 3.1.2. Identity Condition
The sender condition is matched against the URI of the sender of the The identity condition, which is defined in [RFC4745], is matched
request that is used as input for a translation. Sender conditions against the URI of the sender of the request that is used as input
can contain the same elements and attributes as identity conditions. for a translation.
When performing a translation, a relay matches the sender condition When performing a translation, a relay matches the identity condition
against the identity of the sender of the incoming request. against the identity of the sender of the incoming request.
The following subsections define acceptable means of authentication, The following subsections define acceptable means of authentication,
the procedure for representing the identity of the sender as a URI, the procedure for representing the identity of the sender as a URI,
and the procedure for converting an identifier of the form and the procedure for converting an identifier of the form
user@domain, present in the 'id' attribute of the <one> and <except> user@domain, present in the 'id' attribute of the <one> and <except>
elements, into a URI. elements, into a URI.
3.1.2.1. Acceptable Means of Authentication 3.1.2.1. Acceptable Means of Authentication
When used with SIP, a request sent by a sender is considered When used with SIP, a request sent by a sender is considered
authenticated if one of the following techniques is used: authenticated if one of the following techniques is used:
SIP Digest: the relay authenticates the sender using SIP digest SIP Digest: the relay authenticates the sender using SIP digest
authentication [2]. However, if the anonymous authentication authentication [RFC2617]. However, if the anonymous
described on page 194 of RFC 3261 [3] is used, the sender is not authentication described on page 194 of RFC 3261 [RFC3261] is
considered authenticated. used, the sender is not considered authenticated.
Asserted Identity: if a request contains a P-Asserted-ID header Asserted Identity: if a request contains a P-Asserted-ID header
field [5] and the request is coming from a trusted element, the field [RFC3325] and the request is coming from a trusted element,
sender is considered authenticated. the sender is considered authenticated.
Cryptographically Verified Identity: if a request contains an Cryptographically Verified Identity: if a request contains an
Identity header field as defined in [7], and it validates the From Identity header field as defined in [RFC4474], and it validates
header field of the request, the request is considered to be the From header field of the request, the request is considered to
authenticated. Note that this is true even if the request be authenticated. Note that this is true even if the request
contained a From header field of the form contained a From header field of the form
sip:anonymous@example.com. As long as the signature verifies that sip:anonymous@example.com. As long as the signature verifies that
the request legitimately came from this identity, it is considered the request legitimately came from this identity, it is considered
authenticated. authenticated.
3.1.2.2. Computing a URI for the Sender 3.1.2.2. Computing a URI for the Sender
For requests that are authenticated using SIP Digest, the identity of 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 the sender is set equal to the SIP Address of Record (AOR) for the
user that has authenticated themselves. For example, consider the user that has authenticated themselves. For example, consider the
skipping to change at page 6, line 23 skipping to change at page 6, line 46
digest username: ali digest username: ali
digest password: f779ajvvh8a6s6 digest password: f779ajvvh8a6s6
digest realm: example.com digest realm: example.com
If the relay receives a request, challenges it with the realm set to If the relay receives a request, challenges it with the realm set to
"example.com", and the subsequent request contains an Authorization "example.com", and the subsequent request contains an Authorization
header field with a username of "ali" and a digest response generated header field with a username of "ali" and a digest response generated
with the password "f779ajvvh8a6s6", the identity used in matching with the password "f779ajvvh8a6s6", the identity used in matching
operations is "sip:alice@example.com". operations is "sip:alice@example.com".
For requests that are authenticated using RFC 3325 [5], the identity For requests that are authenticated using RFC 3325 [RFC3325], the
of the sender is equal to the SIP URI in the P-Asserted-ID header identity of the sender is equal to the SIP URI in the P-Asserted-ID
field. If there are multiple values for the P-Asserted-ID header header field. If there are multiple values for the P-Asserted-ID
field (there can be one sip URI and one tel URI [10]), then each of header field (there can be one sip URI and one tel URI [RFC3966]),
them is used for the comparisons outlined in [8], and if either of then each of them is used for the comparisons outlined in [RFC4745],
them match a <one> or <except> element, it is considered a match. and if either of them match a <one> or <except> element, it is
considered a match.
For requests that are authenticated using the SIP Identity mechanism For requests that are authenticated using the SIP Identity mechanism
[7], identity of the sender is equal to the SIP URI in the From [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 header field of the request, assuming that the signature in the
Identity header field has been validated. Identity header field has been validated.
SIP also allows for anonymous requests. If a request is anonymous SIP also allows for anonymous requests. If a request is anonymous
because the digest challenge/response used the "anonymous" username, because the digest challenge/response used the "anonymous" username,
the request is considered unauthenticated and will not match the the request is considered unauthenticated and will not match the
<sender> condition. If a request is anonymous because it contains a <identity> condition. If a request is anonymous because it contains
Privacy header field [4], but still contains a P-Asserted-ID header a Privacy header field [RFC3323], but still contains a P-Asserted-ID
field, the identity in the P-Asserted-ID header field is still used header field, the identity in the P-Asserted-ID header field is still
in the authorization computations; the fact that the request was used in the authorization computations; the fact that the request was
anonymous has no impact on the identity processing. However, if the anonymous has no impact on the identity processing. However, if the
request had traversed a trust boundary and the P-Asserted-ID header request had traversed a trust boundary and the P-Asserted-ID header
field and the Privacy header field had been removed, the request will field and the Privacy header field had been removed, the request will
be considered unauthenticated when it arrives at the presence server, be considered unauthenticated when it arrives at the relay, and thus
and thus not match the <sender> condition. Finally, if a request not match the <sender> condition. Finally, if a request contained an
contained an Identity header field that was validated, and the From Identity header field that was validated, and the From header field
header field contained a URI of the form sip:anonymous@example.com, contained a URI of the form sip:anonymous@example.com, then the
then the watcher is considered authenticated, and it will have an watcher is considered authenticated, and it will have an identity
identity equal to sip:anonymous@example.com. Had such an identity equal to sip:anonymous@example.com. Had such an identity been placed
been placed into a <one> or <except> element, there will be a match. into a <one> or <except> element, there will be a match.
3.1.2.3. Computing a SIP URI from the id Attribute 3.1.2.3. Computing a SIP URI from the id Attribute
If the <one> or <except> condition does not contain a scheme, 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 conversion of the value in the 'id' attribute to a SIP URI is done
trivially. If the characters in the 'id' attribute are valid trivially. If the characters in the 'id' attribute are valid
characters for the user and hostpart components of the SIP URI, a characters for the user and hostpart components of the SIP URI, a
'sip:' is appended to the contents of the 'id' attribute, and the '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 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, not valid for the user and hostpart components of the SIP URI,
conversion is not possible. This happens, for example, when the user conversion is not possible. This happens, for example, when the user
portion of the 'id' attribute contain UTF-8 characters. portion of the 'id' attribute contain UTF-8 characters.
3.1.3. Target Condition 3.1.3. Target Condition
The target condition is matched against the target URI of a The target condition is matched against the target URI of a
translation. Target conditions can contain the same elements and translation. The target condition can contain the same elements and
attributes as identity conditions. attributes as identity conditions.
When performing a translation, a relay matches the target condition When performing a translation, a relay matches the target condition
against the destination of the incoming request, which is typically against the destination of the incoming request, which is typically
contained in the Request-URI. contained in the Request-URI.
3.1.4. Validity Condition
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
[I-D.ietf-sip-consent-framework].
3.1.5. Sphere Condition
The <sphere> element is not applicable to this document and therefore
is not used.
3.2. Actions 3.2. Actions
The actions in a permission document provide URIs to grant or deny The actions in a permission document provide URIs to grant or deny
permission to perform the translation described in the document. permission to perform the translation described in the document.
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.
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.
3.2.1. Translation Handling 3.2.1. Translation Handling
The <trans-handling> provides URIs for a recipient to grant or deny The <trans-handling> provides URIs for a recipient to grant or deny
the relay permission to perform a translation. The defined values the relay permission to perform a translation. The defined values
are: are:
deny: this action tells the relay not to perform the translation. deny: this action tells the relay not to perform the translation.
grant: this action tells the server 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 The 'perm-uri' attribute in the <trans-handling> element provides a
URI to grant or deny permission to perform a translation. URI to grant or deny permission to perform a translation.
4. Example Document 4. Example Document
The following permission document is generated by the relay handling In the following example, a client adds 'sip:bob@example.org' to the
'sip:alices-friends@example.com' in order to ask for permission to translation whose Target URI is 'sip:alices-friends@example.com'.
relay requests sent to that URI to 'sip:bob@example.org'. 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.
+--------+ +--------------------------------+ 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"?> <?xml version="1.0" encoding="UTF-8"?>
<cr:ruleset <cr:ruleset
xmlns="urn:ietf:params:xml:ns:consent-rules" xmlns="urn:ietf:params:xml:ns:consent-rules"
xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:consent-rules
consent-rules.xsd">
<cp:rule id="1"> <cp:rule id="1">
<cp:conditions> <cp:conditions>
<cp:identity> <cp:identity>
<cp:one id="sip:bob@example.org"/> <cp:any/>
</cp:identity> </cp:identity>
<recipient>
<cp:one id="sip:bob@example.org"/>
</recipient>
<target> <target>
<cp:one id="sip:alices-friends@example.com""/> <cp:one id="sip:alices-friends@example.com""/>
</target> </target>
<sender>
<cp:any/>
</sender>
</cp:conditions> </cp:conditions>
<cp:actions> <cp:actions>
<trans-handling <trans-handling
perm-uri="sip:foo@example.com">grant</trans-handling> perm-uri="sips:grant-1awdch5Fasddfce34@example.com">
grant</trans-handling>
<trans-handling <trans-handling
perm-uri="sip:bar@example.com">deny</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:actions>
<cp:transformations/> <cp:transformations/>
</cp:rule> </cp:rule>
</cp:ruleset> </cp:ruleset>
5. XML Schema 5. XML Schema
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:consent-rules" targetNamespace="urn:ietf:params:xml:ns:consent-rules"
xmlns:cr="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:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<!-- Conditions --> <!-- Conditions -->
<xs:element name="sender" type="cp:identityType"/> <xs:element name="recipient" type="cp:identityType"/>
<xs:element name="target" type="cp:identityType"/> <xs:element name="target" type="cp:identityType"/>
<!-- Actions --> <!-- Actions -->
<xs:simpleType name="trans-values"> <xs:simpleType name="trans-values">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="deny"/> <xs:enumeration value="deny"/>
<xs:enumeration value="grant"/> <xs:enumeration value="grant"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
skipping to change at page 9, line 41 skipping to change at page 11, line 41
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
6. IANA Considerations 6. IANA Considerations
This section registers a new XML namespace and a new XML schema per This section registers a new XML namespace and a new XML schema per
the procedures in [6]. the procedures in [RFC3688].
6.1. XML Namespace Registration 6.1. XML Namespace Registration
URI: urn:ietf:params:xml:ns:consent-rules URI: urn:ietf:params:xml:ns:consent-rules
Registrant Contact: IETF SIPPING working group, Registrant Contact: IETF SIPPING working group,
<sipping@ietf.org>, Gonzalo Camarillo <sipping@ietf.org>, Gonzalo Camarillo
<Gonzalo.Camarillo@ericsson.com> <Gonzalo.Camarillo@ericsson.com>
XML: XML:
skipping to change at page 10, line 49 skipping to change at page 12, line 49
Permission documents can reveal sensitive information. Additionally, Permission documents can reveal sensitive information. Additionally,
attackers may attempt to modify them in order to have clients grant attackers may attempt to modify them in order to have clients grant
or deny permissions different to the ones they think are granting or or deny permissions different to the ones they think are granting or
denying. For this reason, it is RECOMMENDED that relays use strong denying. For this reason, it is RECOMMENDED that relays use strong
means for information integrity protection and confidentiality when means for information integrity protection and confidentiality when
sending permission documents to clients. sending permission documents to clients.
The mechanism used for conveying information to clients SHOULD ensure The mechanism used for conveying information to clients SHOULD ensure
the integrity and confidentially of the information. In order to the integrity and confidentially of the information. In order to
achieve these, an end-to-end SIP encryption mechanism, such as achieve these, an end-to-end SIP encryption mechanism, such as
S/MIME, as described in RFC 3261 [3], SHOULD be used. S/MIME, as described in RFC 3261 [RFC3261], SHOULD be used.
If strong end-to-end security means (such as above) is not available, If strong end-to-end security means (such as above) is not available,
it is RECOMMENDED that hop-by-hop security based on TLS and SIPS it is RECOMMENDED that hop-by-hop security based on TLS and SIPS
URIs, as described in [3], is used. URIs, as described in [RFC3261], is used.
8. Acknowledgements 8. Acknowledgements
Jonathan Rosenberg provided useful ideas on this document. Ben 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 Campbell and Mary Barnes performed a thorough review of this
document. document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Leach, P., Luotonen, A., and L. Stewart, "HTTP
Basic and Digest Access Authentication", RFC 2617, June 1999. Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E.
Session Initiation Protocol", RFC 3261, June 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[4] Peterson, J., "A Privacy Mechanism for the Session Initiation [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Protocol (SIP)", RFC 3323, November 2002. Initiation Protocol (SIP)", RFC 3323, November 2002.
[5] Jennings, C., Peterson, J., and M. Watson, "Private Extensions [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
to the Session Initiation Protocol (SIP) for Asserted Identity Extensions to the Session Initiation Protocol (SIP) for
within Trusted Networks", RFC 3325, November 2002. Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[7] Peterson, J. and C. Jennings, "Enhancements for Authenticated [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Identity Management in the Session Initiation Protocol (SIP)", Authenticated Identity Management in the Session
RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[8] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
J., and J. Rosenberg, "Common Policy: A Document Format for Polk, J., and J. Rosenberg, "Common Policy: A Document
Expressing Privacy Preferences", RFC 4745, February 2007. Format for Expressing Privacy Preferences", RFC 4745,
February 2007.
[9] Rosenberg, J., "A Framework for Consent-Based Communications in [I-D.ietf-sip-consent-framework]
the Session Initiation Protocol (SIP)", Rosenberg, J., "A Framework for Consent-Based
Communications in the Session Initiation Protocol (SIP)",
draft-ietf-sip-consent-framework-01 (work in progress), draft-ietf-sip-consent-framework-01 (work in progress),
November 2006. November 2006.
9.2. Informative References 9.2. Informative References
[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
December 2004. RFC 3966, December 2004.
Author's Address Author's Address
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
 End of changes. 59 change blocks. 
149 lines changed or deleted 234 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/