draft-ietf-sipping-consent-format-01.txt   draft-ietf-sipping-consent-format-02.txt 
SIPPING G. Camarillo SIPPING G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: May 29, 2007 November 25, 2006 Intended status: Standards Track April 2, 2007
Expires: October 4, 2007
A Document Format for Requesting Consent A Document Format for Requesting Consent
draft-ietf-sipping-consent-format-01.txt draft-ietf-sipping-consent-format-02.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 32 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 May 29, 2007. This Internet-Draft will expire on October 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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 the permission, written in this format is used by a relay to request a specific
of a specific recipient, 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 . . . . . . . . . . . . . . . . 3
3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Identity Condition . . . . . . . . . . . . . . . . . . 4 3.1.1. Identity Condition . . . . . . . . . . . . . . . . . . 4
3.1.2. Sender Condition . . . . . . . . . . . . . . . . . . . 5 3.1.2. Sender Condition . . . . . . . . . . . . . . . . . . . 5
3.1.3. Target Condition . . . . . . . . . . . . . . . . . . . 7 3.1.3. Target Condition . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 2, line 26 skipping to change at page 2, line 26
4. Example Document . . . . . . . . . . . . . . . . . . . . . . . 7 4. Example Document . . . . . . . . . . . . . . . . . . . . . . . 7
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. XML Namespace Registration . . . . . . . . . . . . . . . . 9 6.1. XML Namespace Registration . . . . . . . . . . . . . . . . 9
6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 10 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 13
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) [9] identifies the need for a format to
create permission documents. Such permission documents are used by create permission documents. Such permission documents are used by
SIP [3] relays to request permission to perform translations. A SIP [3] relays to request permission to perform translations. A
relay is defined as any SIP server, be it a proxy, B2BUA (Back-to- 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 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 translates the request URI into one or more next hop URIs to which it
then delivers a request. 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 the XML document format for expressing Privacy Preferences
[8]. [8].
2. Definitions and Terminology 2. Definitions and Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as document are to be interpreted as described in RFC 2119 [1].
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
Relay: Any SIP server, be it a proxy, B2BUA (Back-to-Back User Relay: Any SIP server, be it a proxy, B2BUA (Back-to-Back User
Agent), or some hybrid, that receives a request, translates its Agent), or some hybrid, that receives a request, translates its
Request-URI into one or more next-hop URIs (i.e., recipient URIs), Request-URI into one or more next-hop URIs (i.e., recipient URIs),
and delivers the request to those URIs. and delivers the request to those URIs.
Recipient URI: The Request-URI of an outgoing request sent by an Recipient URI: The Request-URI of an outgoing request sent by an
entity (e.g., a user agent or a proxy). The sending of such entity (e.g., a user agent or a proxy). The sending of such
request may have been the result of a translation operation. request may have been the result of a translation operation.
Target URI: The Request-URI of an incoming request that arrives to an Target URI: The Request-URI of an incoming request that arrives to
entity (e.g., a proxy) that will perform a translation operation. an entity (e.g., a proxy) that will perform a translation
operation.
Translation operation: Operation by which an entity (e.g., a proxy) Translation operation: Operation by which an entity (e.g., a proxy)
translates the request URI of an incoming request (i.e., the translates the request URI of an incoming request (i.e., the
target URI) into one or more URIs (i.e., recipient URIs) which are target URI) into one or more URIs (i.e., recipient URIs) which are
used as the request URIs of one or more outgoing requests. 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 [8]. Permission documents inherit the MIME type of
skipping to change at page 4, line 45 skipping to change at page 4, line 44
are protocol and usage specific. In particular, this section defines are protocol and usage specific. In particular, this section defines
acceptable means of authentication. 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 are SIP Identity [7], as described in [9]. For PUBLISH requests that
authenticated using the SIP Identity mechanism, the identity of are authenticated using the SIP Identity mechanism, the identity
the sender of the PUBLISH request is equal to the SIP URI in the of the sender of the PUBLISH request is equal to the SIP URI in
From header field of the request, assuming that the signature in the From header field of the request, assuming that the signature
the Identity header field has been validated. in the Identity header field has been validated.
P-Asserted-Identity [5], as described in [9]. For PUBLISH requests P-Asserted-Identity [5], as described in [9]. For PUBLISH requests
that are authenticated using the P-Asserted-Identity mechanism, that are authenticated using the P-Asserted-Identity mechanism,
the identity of the sender of the PUBLISH request is equal to the 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 [9].
SIP digest, as described in [9]. SIP digest, as described in [9].
skipping to change at page 5, line 39 skipping to change at page 5, line 39
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 [2]. However, if the anonymous authentication
described on page 194 of RFC 3261 [3] is used, the sender is not described on page 194 of RFC 3261 [3] is used, the sender is not
considered authenticated. considered authenticated.
Asserted Identity: if a request contains a P-Asserted-ID header field Asserted Identity: if a request contains a P-Asserted-ID header
[5] and the request is coming from a trusted element, the sender field [5] and the request is coming from a trusted element, the
is considered authenticated. 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 [7], and it validates the From
header field of the request, the request is considered to be header field of the request, the request is considered to be
authenticated. Note that this is true even if the request 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.
skipping to change at page 11, line 44 skipping to change at page 11, line 44
to the Session Initiation Protocol (SIP) for Asserted Identity to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002. within Trusted Networks", RFC 3325, November 2002.
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[7] Peterson, J. and C. Jennings, "Enhancements for Authenticated [7] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006. RFC 4474, August 2006.
[8] Schulzrinne, H., "Common Policy: A Document Format for [8] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
Expressing Privacy Preferences", J., and J. Rosenberg, "Common Policy: A Document Format for
draft-ietf-geopriv-common-policy-11 (work in progress), Expressing Privacy Preferences", RFC 4745, February 2007.
August 2006.
[9] Rosenberg, J., Camarillo, G., and D. Willis, "A Framework for [9] Rosenberg, J., "A Framework for Consent-Based Communications in
Consent-Based Communications in the Session Initiation Protocol the Session Initiation Protocol (SIP)",
(SIP)", draft-ietf-sip-consent-framework-00 (work in progress), draft-ietf-sip-consent-framework-01 (work in progress),
September 2006. November 2006.
9.2. Informative References 9.2. Informative References
[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, [10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004. 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
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 14, line 29 skipping to change at page 13, line 45
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 16 change blocks. 
48 lines changed or deleted 48 lines changed or added

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