idnits 2.17.1 draft-camarillo-sip-consent-method-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 372. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2006) is 6628 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFCxxxx' on line 303 ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) == Outdated reference: A later version (-05) exists of draft-ietf-sipping-consent-framework-03 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-consent-framework (ref. '4') == Outdated reference: A later version (-01) exists of draft-camarillo-sipping-consent-format-00 -- Possible downref: Normative reference to a draft: ref. '5' Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP G. Camarillo 3 Internet-Draft Ericsson 4 Expires: August 29, 2006 February 25, 2006 6 The Session Initiation Protocol (SIP) CONSENT Method 7 draft-camarillo-sip-consent-method-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 29, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document defines the SIP CONSENT method. SIP relays use CONSENT 41 requests to ask the recipient of a particular translation for 42 permission to perform that translation. In addition, this document 43 defines the Permission-Upload and the Trigger-Consent header fields, 44 and the 470 (Consent Needed) status code. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Generating a CONSENT request . . . . . . . . . . . . . . . . . 3 51 3.1. Processing CONSENT Responses . . . . . . . . . . . . . . . 4 52 4. Processing CONSENT Requests . . . . . . . . . . . . . . . . . 4 53 5. Handling of OPTIONS Requests . . . . . . . . . . . . . . . . . 4 54 6. The Permission-Upload Header Field . . . . . . . . . . . . . . 5 55 7. Permission Upload . . . . . . . . . . . . . . . . . . . . . . 5 56 7.1. Permission Revocation . . . . . . . . . . . . . . . . . . 5 57 8. The Trigger-Consent Header Field . . . . . . . . . . . . . . . 6 58 9. The 470 (Consent Needed) Status Code . . . . . . . . . . . . . 7 59 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 62 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 13.1. Normative References . . . . . . . . . . . . . . . . . . . 8 64 13.2. Informative References . . . . . . . . . . . . . . . . . . 9 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 Intellectual Property and Copyright Statements . . . . . . . . . . 11 68 1. Introduction 70 The framework for consent-based communications in SIP [4] identifies 71 the need for relays to ask the recipient of a particular translation 72 for permission to perform that translation. Relays request 73 permission from recipients by sending them CONSENT requests, which 74 are specified in this document. 76 CONSENT requests carry in their bodies permission documents, which 77 describe the translation for which permissions are needed. 78 Additionally, CONSENT requests carry Permission-Upload header fields, 79 which carry a URI where the recipient of the CONSENT request needs to 80 upload a permission document granting or denying permission to 81 perform a particular translation. 83 This document also defines the 470 (Consent Needed) status code. 84 This response is returned by relays that do not have permissions to 85 perform a particular translation. 87 The Trigger-Consent header field contains a URI where a user agent 88 can send a REFER that will trigger a CONSENT request, as described in 89 [4]. 91 2. Terminology 93 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 94 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 95 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 96 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 97 compliant implementations. 99 3. Generating a CONSENT request 101 A relay wishing to ask a recipient of a translation for permission to 102 perform that translation generates a CONSENT requests towards the 103 recipient. The relay SHOULD include in its CONSENT request a a body 104 with a permission document and a Permission-Upload header field. 106 The permission document describes the translation for which 107 permissions are being requested. Entities that support the CONSENT 108 method MUST support the format for permission documents defined in 109 [5] and MAY support other formats. 111 The Permission-Upload header field carries a URI that the recipient 112 of the CONSENT request will use to upload a permission document 113 granting or denying permission to perform a particular translation. 115 That URI SHOULD remain valid as long as the translation exists at the 116 relay so that user agents can revoke permissions at a later point. 117 Entities that support the CONSENT method MUST support the Permission- 118 Upload header field. 120 Except as noted, the construction of the CONSENT request and the 121 behavior of clients sending a CONSENT request are identical to the 122 general UAC (User Agent Client) behavior described in Section 8.1 and 123 Section 17.1 of RFC 3261 [3]. 125 A CONSENT request does not establish a dialog. A UAC MAY include a 126 Route header field in a CONSENT request based on a pre-existing route 127 set as described in Section 8.1 of RFC 3261 [3]. The Record-Route 128 header field has no meaning in CONSENT requests or responses, and is 129 ignored if present. 131 The CONSENT request MAY contain a Contact header field. A client MAY 132 send a CONSENT request within an existing dialog, but the fact that a 133 CONSENT request is received within a dialog does not have any special 134 meaning. 136 3.1. Processing CONSENT Responses 138 When processing responses to CONSENT requests, the steps in Section 139 8.1.2 of RFC 3261 [3] apply. 141 As indicated earlier, the UAC MUST NOT create a new route set based 142 on the presence or absence of a Record-Route header field in any 143 response to a CONSENT request. 145 4. Processing CONSENT Requests 147 When receiving a PUBLISH request, the ESC follows the steps defining 148 general UAS behavior in Section 8.2 of RFC 3261 [3]. As indicated 149 earlier, a UAS receiving a CONSENT request MUST NOT create a new 150 route set based on the presence or absence of a Record-Route header 151 field in the CONSENT request. 153 5. Handling of OPTIONS Requests 155 If necessary, clients may probe for the support of CONSENT using the 156 OPTIONS request defined in SIP [3]. The presence of 'CONSENT' in the 157 Allow header field in a response to an OPTIONS request indicates 158 support for the CONSENT method. 160 UAS (User Agent Servers) process OPTIONS requests as defined in 161 Section 11.2 of RFC 3261 [3]. In the response to an OPTIONS request, 162 the UAS SHOULD include 'CONSENT' in the list of allowed methods in 163 the Allow header field. 165 6. The Permission-Upload Header Field 167 The following is the augmented Backus-Naur Form (BNF) [2] syntax of 168 the Permission-Upload header field. Some of its elements are defined 169 in RFC 3261 [3]. 171 Permission-Upload = "Permission-Upload" HCOLON perm-up-spec 172 perm-up-spec = ( name-addr / addr-spec ) 173 *( SEMI generic-param ) 175 A Permission-Upload header field in a CONSENT request carries a URI 176 that the recipient of the CONSENT request will use to upload a 177 permission document granting or denying permission to perform a the 178 translation described by the permission document in the CONSENT 179 request. 181 7. Permission Upload 183 A user agent receiving a CONSENT request is requested to generate a 184 permission document that describes the same translation as the 185 permission document in the CONSENT request did and that allows or 186 denies its execution at the relay. The user agent is requested to 187 upload such a permission document to the URI received in the 188 Permission-Upload header field of the CONSENT request. 190 When the URI in the Permission-Upload header field is a SIP or a SIPS 191 URI, the user agent MUST send a PUBLISH request containing the 192 generated permission document to that URI. 194 The use of other types of URIs to upload permission documents is 195 for further study. However, note that any upload mechanism used 196 in this context needs to meet the authentication criteria 197 described in the framework for consent-based communications in SIP 198 [4]. 200 7.1. Permission Revocation 202 A user agent that wants to revoke a permission that was given in the 203 past generates a permission document that describes the translation 204 for which permission was given and that denies its execution at the 205 relay. The user agent uploads the permission document to the same 206 URI as the user agent uploaded the original permission document 207 granting the permission. 209 Consequently, user agents MAY store the URIs used to upload 210 permission documents in order to revoke permissions at a later point. 211 If the user agent loses the URI associated to a permission or a 212 PUBLISH request sent to that URI is rejected, the user agent can 213 obtain a new URI following the procedures discussed in [4]. 215 8. The Trigger-Consent Header Field 217 The Trigger-Consent header field contains a URI where a user agent 218 can send a REFER that will trigger a CONSENT request, as described in 219 [4]. 221 Relays performing a translation for which they previously obtained 222 permission MUST add a Trigger-Consent header field to the outgoing 223 request that is the result of the translation. The URI in this 224 header field can be used by recipients that want to revoke their 225 permission but lost the URI to do so. Sending a REFER request to the 226 URI in the Trigger-Consent header field will provide them with a new 227 CONSENT request that will carry a Permission-Upload header field. 228 The Permission-Upload header field will contain a URI the recipient 229 can use to revoke permissions. 231 Registrars that require consent before installing a translation MUST 232 include a Trigger-Consent header field in their responses to incoming 233 REGISTER requests, as described in [4]. 235 Relays generating 470 (Consent Needed) responses MUST include a 236 Trigger-Consent header field in those responses, as described in [4]. 238 The following is the augmented Backus-Naur Form (BNF) [2] syntax of 239 the Trigger-Consent header field. Some of its elements are defined 240 in RFC 3261 [3]. 242 Trigger-Consent = "Trigger-Consent" HCOLON trigger-cons-spec 243 trigger-cons-spec = ( name-addr / addr-spec ) 244 *( SEMI generic-param ) 246 Trigger-Consent header fields MUST contain a URI with an escaped 247 (using the '?' mechanism) Refer-To header field. The URI in the 248 escaped Refer-To header field is the recipient URI of the 249 translation. This ensures that a REFER sent to the URI in the 250 Trigger-Consent header field will trigger a CONSENT towards the 251 recipient URI. The following is an example of a Trigger-Consent 252 header field: 254 sip:relay@example.com?Refer-To= 256 9. The 470 (Consent Needed) Status Code 258 This status code is returned by relays that do not have permissions 259 to perform a particular translation, as described in [4]. 261 10. IANA Considerations 263 This document defines a new SIP method (CONSENT), two new SIP header 264 fields (Permission-Upload and Trigger-Consent), and new status code 265 (470). 267 The IANA is instructed to add the following new SIP method to the 268 Methods and Response Codes subregistry under the SIP Parameters 269 registry. 271 Method Name: CONSENT 272 Reference: [RFCxxxx] 274 Note to the RFC editor: substitute xxxx with the RFC number of this 275 document. 277 The IANA is instructed to add the following new SIP header field to 278 the Header Fields subregistry under the SIP Parameters registry. 280 Header Name: Permission-Upload 281 Compact Form: (none) 282 Reference: [RFCxxxx] 284 Note to the RFC editor: substitute xxxx with the RFC number of this 285 document. 287 The IANA is instructed to add the following new SIP header field to 288 the Header Fields subregistry under the SIP Parameters registry. 290 Header Name: Trigger-Consent 291 Compact Form: (none) 292 Reference: [RFCxxxx] 294 Note to the RFC editor: substitute xxxx with the RFC number of this 295 document. 297 The IANA is instructed to add the following new response code to the 298 Methods and Response Codes subregistry under the SIP Parameters 299 registry. 301 Response Code Number: 470 302 Default Reason Phrase: Consent Needed 303 Reference: [RFCxxxx] 305 Note to the RFC editor: substitute xxxx with the RFC number of this 306 document. 308 11. Security Considerations 310 TBD. 312 12. Acknowledgements 314 TBD. 316 13. References 318 13.1. Normative References 320 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 321 Levels", BCP 14, RFC 2119, March 1997. 323 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 324 Specifications: ABNF", RFC 2234, November 1997. 326 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 327 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 328 Session Initiation Protocol", RFC 3261, June 2002. 330 [4] Rosenberg, J., "A Framework for Consent-Based Communications in 331 the Session Initiation Protocol (SIP)", 332 draft-ietf-sipping-consent-framework-03 (work in progress), 333 October 2005. 335 [5] Camarillo, G., "A Document Format for Expressing Consent", 336 draft-camarillo-sipping-consent-format-00 (work in progress), 337 February 2006. 339 13.2. Informative References 340 Author's Address 342 Gonzalo Camarillo 343 Ericsson 344 Hirsalantie 11 345 Jorvas 02420 346 Finland 348 Email: Gonzalo.Camarillo@ericsson.com 350 Intellectual Property Statement 352 The IETF takes no position regarding the validity or scope of any 353 Intellectual Property Rights or other rights that might be claimed to 354 pertain to the implementation or use of the technology described in 355 this document or the extent to which any license under such rights 356 might or might not be available; nor does it represent that it has 357 made any independent effort to identify any such rights. Information 358 on the procedures with respect to rights in RFC documents can be 359 found in BCP 78 and BCP 79. 361 Copies of IPR disclosures made to the IETF Secretariat and any 362 assurances of licenses to be made available, or the result of an 363 attempt made to obtain a general license or permission for the use of 364 such proprietary rights by implementers or users of this 365 specification can be obtained from the IETF on-line IPR repository at 366 http://www.ietf.org/ipr. 368 The IETF invites any interested party to bring to its attention any 369 copyrights, patents or patent applications, or other proprietary 370 rights that may cover technology that may be required to implement 371 this standard. Please address the information to the IETF at 372 ietf-ipr@ietf.org. 374 Disclaimer of Validity 376 This document and the information contained herein are provided on an 377 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 378 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 379 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 380 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 381 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 382 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 384 Copyright Statement 386 Copyright (C) The Internet Society (2006). This document is subject 387 to the rights, licenses and restrictions contained in BCP 78, and 388 except as set forth therein, the authors retain all their rights. 390 Acknowledgment 392 Funding for the RFC Editor function is currently provided by the 393 Internet Society.