draft-ietf-sipping-consent-format-08.txt   rfc5361.txt 
SIPPING G. Camarillo Network Working Group G. Camarillo
Internet-Draft Ericsson Request for Comments: 5361 Ericsson
Intended status: Standards Track August 1, 2008 Category: Standards Track October 2008
Expires: February 2, 2009
A Document Format for Requesting Consent A Document Format for Requesting Consent
draft-ietf-sipping-consent-format-08.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 2, 2009.
Copyright Notice Status of This Memo
Copyright (C) The IETF Trust (2008). 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.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 2
3. Permission Document Structure . . . . . . . . . . . . . . . . 4 3. Permission Document Structure . . . . . . . . . . . . . . . . 3
3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Recipient Condition . . . . . . . . . . . . . . . . . 4 3.1.1. Recipient Condition . . . . . . . . . . . . . . . . . 3
3.1.2. Identity Condition . . . . . . . . . . . . . . . . . . 5 3.1.2. Identity Condition . . . . . . . . . . . . . . . . . . 4
3.1.3. Target Condition . . . . . . . . . . . . . . . . . . . 8 3.1.3. Target Condition . . . . . . . . . . . . . . . . . . . 6
3.1.4. Validity Condition . . . . . . . . . . . . . . . . . . 8 3.1.4. Validity Condition . . . . . . . . . . . . . . . . . . 7
3.1.5. Sphere Condition . . . . . . . . . . . . . . . . . . . 8 3.1.5. Sphere Condition . . . . . . . . . . . . . . . . . . . 7
3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Translation Handling . . . . . . . . . . . . . . . . . 8 3.2.1. Translation Handling . . . . . . . . . . . . . . . . . 7
4. Example Document . . . . . . . . . . . . . . . . . . . . . . . 9 4. Example Document . . . . . . . . . . . . . . . . . . . . . . . 7
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. XML Namespace Registration . . . . . . . . . . . . . . . . 12 7.1. XML Namespace Registration . . . . . . . . . . . . . . . . 11
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
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) [I-D.ietf-sip-consent-framework] identifies Initiation Protocol (SIP) [RFC5360] identifies the need for a format
the need for a format to create permission documents. Such to create permission documents. Such permission documents are used
permission documents are used by SIP [RFC3261] relays to request by SIP [RFC3261] relays to request permission to perform
permission to perform translations. A relay is defined as any SIP translations. A relay is defined as any SIP server, be it a proxy,
server, be it a proxy, B2BUA (Back-to-Back User Agent), or some B2BUA (Back-to-Back User Agent), or some hybrid, which receives a
hybrid, which receives a request and translates the request URI into request and translates the Request-URI into one or more next-hop URIs
one or more next hop URIs to which it then delivers a request. 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 Common Policy [RFC4745], an XML document format for based on Common Policy [RFC4745], an XML document format for
expressing privacy preferences. 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 [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses the terms defined in This document uses the terms defined in [RFC5360]. For completeness,
[I-D.ietf-sip-consent-framework]. For completeness, these terms are these terms are repeated here. Figure 1 of [RFC5360] shows the
repeated here. Figure 1 of [I-D.ietf-sip-consent-framework] shows relationship between target and recipient URIs in a translation
the relationship between target and recipient URIs in a translation
operation. operation.
Recipient URI: Recipient URI:
The Request-URI of an outgoing request sent by an entity (e.g., a 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 user agent or a proxy). The sending of such request can have been
the result of a translation operation. the result of a translation operation.
Relay: Relay:
skipping to change at page 4, line 14 skipping to change at page 3, line 9
Translation logic: Translation logic:
The logic that defines a translation operation at a relay. This The logic that defines a translation operation at a relay. This
logic includes the translation's target and recipient URIs. logic includes the translation's target and recipient URIs.
Translation operation: Translation operation:
Operation by which a relay translates the Request-URI of an Operation by which a relay translates the Request-URI of an
incoming request (i.e., the target URI) into one or more URIs 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 (i.e., recipient URIs) that are used as the Request-URIs of one or
or more outgoing requests. 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 [RFC4745]. Permission documents inherit the MIME schema defined in [RFC4745]. Permission documents inherit the MIME
type of common policy documents, 'application/auth-policy+xml'. As type of common policy documents, 'application/auth-policy+xml'. As
described in [RFC4745], this type of document is composed of three described in [RFC4745], this type of document is composed of three
parts: conditions, actions, and transformations. parts: conditions, actions, and transformations.
This section defines the new conditions and actions defined by this This section defines the new conditions and actions defined by this
skipping to change at page 4, line 47 skipping to change at page 3, line 42
3.1.1. Recipient Condition 3.1.1. Recipient Condition
The recipient condition is matched against the recipient URI of a The recipient condition is matched against the recipient URI of a
translation. Recipient conditions can contain the same elements and translation. Recipient conditions can contain the same elements and
attributes as identity conditions. attributes as identity conditions.
When performing a translation, a relay matches the recipient When performing a translation, a 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 for that translation against the destination URI of the permission for that translation against the destination URI of the
outgoing request. When receiving a request granting or denying outgoing request. When receiving a request granting or denying
permissions (e.g., a SIP PUBLISH request as described in permissions (e.g., a SIP PUBLISH request as described in [RFC5360]),
[I-D.ietf-sip-consent-framework]), the relay matches the recipient the relay matches the recipient condition of the permission document
condition of the permission document that was used to request that was used to request permission against the identity of the
permission against the identity of the entity granting or denying entity granting or denying permissions (i.e., the sender of the
permissions (i.e., the sender of the PUBLISH request). If there is a PUBLISH request). If there is a match, the recipient condition
match, the recipient condition evaluates to TRUE. Otherwise, the evaluates to TRUE. Otherwise, the recipient condition evaluates to
recipient condition evaluates to FALSE. FALSE.
Since only authenticated identities can be matched, this section Since only authenticated identities can be matched, this section
defines acceptable means of authentication, which are in line with defines acceptable means of authentication, which are in line with
those described in Section 5.6.1 of [I-D.ietf-sip-consent-framework]. those described in Section 5.6.1 of [RFC5360].
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 [RFC4474], as described in Section 5.6.1.1 of SIP Identity [RFC4474], as described in Section 5.6.1.1 of
[I-D.ietf-sip-consent-framework]. For PUBLISH requests that are [RFC5360]. For PUBLISH requests that are authenticated using the
authenticated using the SIP Identity mechanism, the identity of SIP Identity mechanism, the identity of the sender of the PUBLISH
the sender of the PUBLISH request is equal to the SIP URI in the request is equal to the SIP URI in the From header field of the
From header field of the request, assuming that the signature in request, assuming that the signature in the Identity header field
the Identity header field has been validated. has been validated.
P-Asserted-Identity [RFC3325] (which can only be used in closed P-Asserted-Identity [RFC3325] (which can only be used in closed
network environments) as described in Section 5.6.1.2 of network environments) as described in Section 5.6.1.2 of
[I-D.ietf-sip-consent-framework]. For PUBLISH requests that are [RFC5360]. For PUBLISH requests that are authenticated using the
authenticated using the P-Asserted-Identity mechanism, the P-Asserted-Identity mechanism, the identity of the sender of the
identity of the sender of the PUBLISH request is equal to the PUBLISH request is equal to the P-Asserted-Identity header field
P-Asserted-Identity header field of the request. of the request.
Return Routability Test, as described in Section 5.6.1.3 of 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 [RFC5360]. It can be used for SIP PUBLISH and HTTP GET requests.
and HTTP GET requests. No authentication is expected to be used No authentication is expected to be used with return routability
with return routability tests and, therefore, no identity matching tests and, therefore, no identity matching procedures are defined.
procedures are defined.
SIP digest, as described in Section 5.6.1.4 of SIP digest, as described in Section 5.6.1.4 of [RFC5360]. The
[I-D.ietf-sip-consent-framework]. The identity of the sender is identity of the sender is set equal to the SIP Address of Record
set equal to the SIP Address of Record (AOR) for the user that has (AOR) for the user that has authenticated themselves.
authenticated themselves.
3.1.2. Identity Condition 3.1.2. Identity Condition
The identity condition, which is defined in [RFC4745], is matched The identity condition, which is defined in [RFC4745], is matched
against the URI of the sender of the request that is used as input against the URI of the sender of the request that is used as input
for a translation. for a translation.
When performing a translation, a relay matches the identity condition When performing a translation, a relay matches the identity condition
against the identity of the sender of the incoming request. If they against the identity of the sender of the incoming request. If they
match, the identity condition evaluates to TRUE. Otherwise, the match, the identity condition evaluates to TRUE. Otherwise, the
skipping to change at page 6, line 48 skipping to change at page 5, line 40
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
following "user record" in a database: following "user record" in a database:
SIP AOR: sip:alice@example.com SIP AOR: sip:alice@example.com
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 and challenges it with the realm set
"example.com", and the subsequent request contains an Authorization to "example.com", and the subsequent request contains an
header field with a username of "ali" and a digest response generated Authorization header field with a username of "ali" and a digest
with the password "f779ajvvh8a6s6", the identity used in matching response generated with the password "f779ajvvh8a6s6", the identity
operations is "sip:alice@example.com". used in matching operations is "sip:alice@example.com".
For requests that are authenticated using [RFC3325], the identity of 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. 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 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 (there can be one sip URI and one tel URI [RFC3966]), then each of
them is used for the comparisons outlined in [RFC4745], and if either them is used for the comparisons outlined in [RFC4745]; if either of
of them match a <one> or <except> element, it is considered a match. 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
[RFC4474], 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
<identity> condition. If a request is anonymous because it contains <identity> condition. If a request is anonymous because it contains
skipping to change at page 8, line 20 skipping to change at page 7, line 8
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. If they match, the target condition contained in the Request-URI. If they match, the target condition
evaluates to TRUE. Otherwise, the target condition evaluates to evaluates to TRUE. Otherwise, the target condition evaluates to
FALSE. FALSE.
3.1.4. Validity Condition 3.1.4. Validity Condition
The <validity> element is not applicable to this document. Each The <validity> element is not applicable to this document. Each
permission element has an infinite lifetime and can be revoked using <permission> element has an infinite lifetime and can be revoked
an independent mechanism, as described in Section 5.8 of using an independent mechanism, as described in Section 5.8 of
[I-D.ietf-sip-consent-framework]. In any case, as discussed in [RFC5360]. In any case, as discussed in Section 4.1 of [RFC5360],
Section 4.1 of [I-D.ietf-sip-consent-framework], permissions are only permissions are only valid as long as the context where they were
valid as long as the context where they were granted is valid. If granted is valid. If present, <validity> elements MUST be ignored.
present, <validity> elements MUST be ignored.
3.1.5. Sphere Condition 3.1.5. Sphere Condition
The <sphere> element is not applicable to this document and therefore The <sphere> element is not applicable to this document and therefore
is not used. If present, <sphere> elements MUST be ignored. is not used. If present, <sphere> elements MUST be ignored.
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.
skipping to change at page 9, line 15 skipping to change at page 7, line 49
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
In the following example, a client adds 'sip:bob@example.org' to the In the following example, a client adds 'sip:bob@example.org' to the
translation whose Target URI is 'sip:alices-friends@example.com'. translation whose target URI is 'sip:alices-friends@example.com'.
The relay handling the translation generates the following permission The relay handling the translation generates the following permission
document in order to ask for permission to relay requests sent to document in order to ask for permission to relay requests sent to
'sip:alices-friends@example.com' to 'sip:bob@example.org'. The 'sip:alices-friends@example.com' to 'sip:bob@example.org'. The
Target URI is 'sip:alices-friends@example.com', and the Recipient URI 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 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 in this example. Therefore, the permission document does not put any
restriction on potential senders. restriction on potential senders.
+--------+ +--------------------------------+ Permission +--------+ +--------------------------------+ Permission
| | | | Request | | | | Request
| Client | | Relay | with | Client | | Relay | with
| | | sip:alices-friends@example.com | Permission | | | sip:alices-friends@example.com | Permission
+--------+ | | Document +--------+ | | Document
| |+-------+ |-------------+ | |+-------+ |-------------+
skipping to change at page 10, line 7 skipping to change at page 9, line 7
sip:bob@example.org V sip:bob@example.org V
+---------------------+ +---------------------+
| | | |
| Recipient | | Recipient |
| sip:bob@example.org | | sip:bob@example.org |
| | | |
+---------------------+ +---------------------+
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cp:ruleset <cp: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">
<cp:rule id="f1"> <cp:rule id="f1">
<cp:conditions> <cp:conditions>
<cp:identity> <cp:identity>
<cp:many/> <cp:many/>
</cp:identity> </cp:identity>
<recipient> <recipient>
<cp:one id="sip:bob@example.org"/> <cp:one id="sip:bob@example.org"/>
</recipient> </recipient>
<target> <target>
<cp:one id="sip:alices-friends@example.com"/> <cp:one id="sip:alices-friends@example.com"/>
skipping to change at page 12, line 14 skipping to change at page 11, line 14
7. IANA Considerations 7. 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 [RFC3688]. the procedures in [RFC3688].
7.1. XML Namespace Registration 7.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>,
<sipping@ietf.org>, Gonzalo Camarillo Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
<Gonzalo.Camarillo@ericsson.com>
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>Consent Rules Namespace</title> <title>Consent Rules Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for Permission Documents</h1> <h1>Namespace for Permission Documents</h1>
<h2>urn:ietf:params:xml:ns:consent-rules</h2> <h2>urn:ietf:params:xml:ns:consent-rules</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc5361.txt">RFC 5361
[NOTE TO IANA/RFC-EDITOR: </a>.</p>
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body> </body>
</html> </html>
END END
7.2. XML Schema Registration 7.2. XML Schema Registration
URI: urn:ietf:params:xml:schema:consent-rules URI: urn:ietf:params:xml:schema:consent-rules
Registrant Contact: IETF SIPPING working group, Registrant Contact: IETF SIPPING working group <sipping@ietf.org>,
<sipping@ietf.org>, Gonzalo Camarillo Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
<Gonzalo.Camarillo@ericsson.com>
XML: The XML schema to be registered is contained in Section 5. XML: The XML schema to be registered is contained in Section 5.
8. Security Considerations 8. Security Considerations
The framework for consent-based communications in the Session RFC 5360 [RFC5360] discusses security-related issues, such as how to
Initiation Protocol (SIP) [I-D.ietf-sip-consent-framework] discusses authenticate SIP and HTTP requests granting permissions and how to
security-related issues, such as how to authenticate SIP and HTTP transport permission documents between relays and recipients, that
requests granting permissions and how to transport permission are directly related to this specification.
documents between relays and recipients, that are directly related to
this specification.
9. Acknowledgements 9. Acknowledgements
Jonathan Rosenberg provided useful ideas on this document. Hannes Jonathan Rosenberg provided useful ideas on this document. Hannes
Tschofenig helped align this document with common policy. Ben 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. Lakshminath Dondeti provided useful comments. document. Lakshminath Dondeti provided useful comments.
10. References 10. References
skipping to change at page 14, line 6 skipping to change at page 13, line 5
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
Polk, J., and J. Rosenberg, "Common Policy: A Document Polk, J., and J. Rosenberg, "Common Policy: A Document
Format for Expressing Privacy Preferences", RFC 4745, Format for Expressing Privacy Preferences", RFC 4745,
February 2007. February 2007.
[I-D.ietf-sip-consent-framework] [RFC5360] Rosenberg, J., Camarillo, G., and D. Willis, "A Framework
Rosenberg, J., Camarillo, G., and D. Willis, "A Framework for Consent-Based Communications in the Session Initiation
for Consent-based Communications in the Session Initiation Protocol (SIP)", RFC 5360, October 2008.
Protocol (SIP)", draft-ietf-sip-consent-framework-04 (work
in progress), January 2008.
10.2. Informative References 10.2. Informative References
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. November 2002.
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 15, line 44 skipping to change at line 592
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 28 change blocks. 
131 lines changed or deleted 94 lines changed or added

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