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= 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]