SIP G. Camarillo
Internet-Draft Ericsson
Expires: August 29, 2006 February 25, 2006
The Session Initiation Protocol (SIP) CONSENT Method
draft-camarillo-sip-consent-method-00.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 August 29, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines the SIP CONSENT method. SIP relays use CONSENT
requests to ask the recipient of a particular translation for
permission to perform that translation. In addition, this document
defines the Permission-Upload and the Trigger-Consent header fields,
and the 470 (Consent Needed) status code.
Camarillo Expires August 29, 2006 [Page 1]
Internet-Draft The CONSENT Method February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Generating a CONSENT request . . . . . . . . . . . . . . . . . 3
3.1. Processing CONSENT Responses . . . . . . . . . . . . . . . 4
4. Processing CONSENT Requests . . . . . . . . . . . . . . . . . 4
5. Handling of OPTIONS Requests . . . . . . . . . . . . . . . . . 4
6. The Permission-Upload Header Field . . . . . . . . . . . . . . 5
7. Permission Upload . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Permission Revocation . . . . . . . . . . . . . . . . . . 5
8. The Trigger-Consent Header Field . . . . . . . . . . . . . . . 6
9. The 470 (Consent Needed) Status Code . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
13.1. Normative References . . . . . . . . . . . . . . . . . . . 8
13.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Camarillo Expires August 29, 2006 [Page 2]
Internet-Draft The CONSENT Method February 2006
1. Introduction
The framework for consent-based communications in SIP [4] identifies
the need for relays to ask the recipient of a particular translation
for permission to perform that translation. Relays request
permission from recipients by sending them CONSENT requests, which
are specified in this document.
CONSENT requests carry in their bodies permission documents, which
describe the translation for which permissions are needed.
Additionally, CONSENT requests carry Permission-Upload header fields,
which carry a URI where the recipient of the CONSENT request needs to
upload a permission document granting or denying permission to
perform a particular translation.
This document also defines the 470 (Consent Needed) status code.
This response is returned by relays that do not have permissions to
perform a particular translation.
The Trigger-Consent header field contains a URI where a user agent
can send a REFER that will trigger a CONSENT request, as described in
[4].
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
3. Generating a CONSENT request
A relay wishing to ask a recipient of a translation for permission to
perform that translation generates a CONSENT requests towards the
recipient. The relay SHOULD include in its CONSENT request a a body
with a permission document and a Permission-Upload header field.
The permission document describes the translation for which
permissions are being requested. Entities that support the CONSENT
method MUST support the format for permission documents defined in
[5] and MAY support other formats.
The Permission-Upload header field carries a URI that the recipient
of the CONSENT request will use to upload a permission document
granting or denying permission to perform a particular translation.
Camarillo Expires August 29, 2006 [Page 3]
Internet-Draft The CONSENT Method February 2006
That URI SHOULD remain valid as long as the translation exists at the
relay so that user agents can revoke permissions at a later point.
Entities that support the CONSENT method MUST support the Permission-
Upload header field.
Except as noted, the construction of the CONSENT request and the
behavior of clients sending a CONSENT request are identical to the
general UAC (User Agent Client) behavior described in Section 8.1 and
Section 17.1 of RFC 3261 [3].
A CONSENT request does not establish a dialog. A UAC MAY include a
Route header field in a CONSENT request based on a pre-existing route
set as described in Section 8.1 of RFC 3261 [3]. The Record-Route
header field has no meaning in CONSENT requests or responses, and is
ignored if present.
The CONSENT request MAY contain a Contact header field. A client MAY
send a CONSENT request within an existing dialog, but the fact that a
CONSENT request is received within a dialog does not have any special
meaning.
3.1. Processing CONSENT Responses
When processing responses to CONSENT requests, the steps in Section
8.1.2 of RFC 3261 [3] apply.
As indicated earlier, the UAC MUST NOT create a new route set based
on the presence or absence of a Record-Route header field in any
response to a CONSENT request.
4. Processing CONSENT Requests
When receiving a PUBLISH request, the ESC follows the steps defining
general UAS behavior in Section 8.2 of RFC 3261 [3]. As indicated
earlier, a UAS receiving a CONSENT request MUST NOT create a new
route set based on the presence or absence of a Record-Route header
field in the CONSENT request.
5. Handling of OPTIONS Requests
If necessary, clients may probe for the support of CONSENT using the
OPTIONS request defined in SIP [3]. The presence of 'CONSENT' in the
Allow header field in a response to an OPTIONS request indicates
support for the CONSENT method.
UAS (User Agent Servers) process OPTIONS requests as defined in
Camarillo Expires August 29, 2006 [Page 4]
Internet-Draft The CONSENT Method February 2006
Section 11.2 of RFC 3261 [3]. In the response to an OPTIONS request,
the UAS SHOULD include 'CONSENT' in the list of allowed methods in
the Allow header field.
6. The Permission-Upload Header Field
The following is the augmented Backus-Naur Form (BNF) [2] syntax of
the Permission-Upload header field. Some of its elements are defined
in RFC 3261 [3].
Permission-Upload = "Permission-Upload" HCOLON perm-up-spec
perm-up-spec = ( name-addr / addr-spec )
*( SEMI generic-param )
A Permission-Upload header field in a CONSENT request carries a URI
that the recipient of the CONSENT request will use to upload a
permission document granting or denying permission to perform a the
translation described by the permission document in the CONSENT
request.
7. Permission Upload
A user agent receiving a CONSENT request is requested to generate a
permission document that describes the same translation as the
permission document in the CONSENT request did and that allows or
denies its execution at the relay. The user agent is requested to
upload such a permission document to the URI received in the
Permission-Upload header field of the CONSENT request.
When the URI in the Permission-Upload header field is a SIP or a SIPS
URI, the user agent MUST send a PUBLISH request containing the
generated permission document to that URI.
The use of other types of URIs to upload permission documents is
for further study. However, note that any upload mechanism used
in this context needs to meet the authentication criteria
described in the framework for consent-based communications in SIP
[4].
7.1. Permission Revocation
A user agent that wants to revoke a permission that was given in the
past generates a permission document that describes the translation
for which permission was given and that denies its execution at the
relay. The user agent uploads the permission document to the same
Camarillo Expires August 29, 2006 [Page 5]
Internet-Draft The CONSENT Method February 2006
URI as the user agent uploaded the original permission document
granting the permission.
Consequently, user agents MAY store the URIs used to upload
permission documents in order to revoke permissions at a later point.
If the user agent loses the URI associated to a permission or a
PUBLISH request sent to that URI is rejected, the user agent can
obtain a new URI following the procedures discussed in [4].
8. The Trigger-Consent Header Field
The Trigger-Consent header field contains a URI where a user agent
can send a REFER that will trigger a CONSENT request, as described in
[4].
Relays performing a translation for which they previously obtained
permission MUST add a Trigger-Consent header field to the outgoing
request that is the result of the translation. The URI in this
header field can be used by recipients that want to revoke their
permission but lost the URI to do so. Sending a REFER request to the
URI in the Trigger-Consent header field will provide them with a new
CONSENT request that will carry a Permission-Upload header field.
The Permission-Upload header field will contain a URI the recipient
can use to revoke permissions.
Registrars that require consent before installing a translation MUST
include a Trigger-Consent header field in their responses to incoming
REGISTER requests, as described in [4].
Relays generating 470 (Consent Needed) responses MUST include a
Trigger-Consent header field in those responses, as described in [4].
The following is the augmented Backus-Naur Form (BNF) [2] syntax of
the Trigger-Consent header field. Some of its elements are defined
in RFC 3261 [3].
Trigger-Consent = "Trigger-Consent" HCOLON trigger-cons-spec
trigger-cons-spec = ( name-addr / addr-spec )
*( SEMI generic-param )
Trigger-Consent header fields MUST contain a URI with an escaped
(using the '?' mechanism) Refer-To header field. The URI in the
escaped Refer-To header field is the recipient URI of the
translation. This ensures that a REFER sent to the URI in the
Trigger-Consent header field will trigger a CONSENT towards the
recipient URI. The following is an example of a Trigger-Consent
Camarillo Expires August 29, 2006 [Page 6]
Internet-Draft The CONSENT Method February 2006
header field:
sip:relay@example.com?Refer-To=<sip:recipient%40example.net>
9. The 470 (Consent Needed) Status Code
This status code is returned by relays that do not have permissions
to perform a particular translation, as described in [4].
10. IANA Considerations
This document defines a new SIP method (CONSENT), two new SIP header
fields (Permission-Upload and Trigger-Consent), and new status code
(470).
The IANA is instructed to add the following new SIP method to the
Methods and Response Codes subregistry under the SIP Parameters
registry.
Method Name: CONSENT
Reference: [RFCxxxx]
Note to the RFC editor: substitute xxxx with the RFC number of this
document.
The IANA is instructed to add the following new SIP header field to
the Header Fields subregistry under the SIP Parameters registry.
Header Name: Permission-Upload
Compact Form: (none)
Reference: [RFCxxxx]
Note to the RFC editor: substitute xxxx with the RFC number of this
document.
The IANA is instructed to add the following new SIP header field to
the Header Fields subregistry under the SIP Parameters registry.
Header Name: Trigger-Consent
Compact Form: (none)
Reference: [RFCxxxx]
Camarillo Expires August 29, 2006 [Page 7]
Internet-Draft The CONSENT Method February 2006
Note to the RFC editor: substitute xxxx with the RFC number of this
document.
The IANA is instructed to add the following new response code to the
Methods and Response Codes subregistry under the SIP Parameters
registry.
Response Code Number: 470
Default Reason Phrase: Consent Needed
Reference: [RFCxxxx]
Note to the RFC editor: substitute xxxx with the RFC number of this
document.
11. Security Considerations
TBD.
12. Acknowledgements
TBD.
13. References
13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] 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.
[4] Rosenberg, J., "A Framework for Consent-Based Communications in
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-consent-framework-03 (work in progress),
October 2005.
[5] Camarillo, G., "A Document Format for Expressing Consent",
draft-camarillo-sipping-consent-format-00 (work in progress),
February 2006.
Camarillo Expires August 29, 2006 [Page 8]
Internet-Draft The CONSENT Method February 2006
13.2. Informative References
Camarillo Expires August 29, 2006 [Page 9]
Internet-Draft The CONSENT Method February 2006
Author's Address
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Camarillo Expires August 29, 2006 [Page 10]
Internet-Draft The CONSENT Method February 2006
Intellectual Property Statement
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.
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.
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.
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
Funding for the RFC Editor function is currently provided by the
Internet Society.
Camarillo Expires August 29, 2006 [Page 11]