idnits 2.17.1 draft-hautakorpi-sipping-uri-list-handling-refused-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 367. ** 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 (May 30, 2006) is 6542 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 290 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-05 ** Obsolete normative reference: RFC 4234 (ref. '4') (Obsoleted by RFC 5234) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group J. Hautakorpi, Ed. 3 Internet-Draft G. Camarillo 4 Expires: December 1, 2006 Ericsson 5 May 30, 2006 7 A Method for URI-List Servers to Refuse the Handling of a URI-List 8 draft-hautakorpi-sipping-uri-list-handling-refused-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 1, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This documents defines a new response code, namely 495 (URI-List 42 Handling Refused), for the Session Initiation Protocol (SIP). This 43 new response code can used by URI-list servers that do not want to 44 handle an incoming URI-list (e.g., due to local policy). For 45 example, a URI-list server may not want to handle a URI-list when an 46 incoming SIP request carries a URI-list inside a URI-list. The URI- 47 list server may not want to handle that particular embedded URI-list. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Syntax of 495 URI-List Handling Refused . . . . . . . . . . . 4 54 4. Example Scenario . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 59 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 61 Intellectual Property and Copyright Statements . . . . . . . . . . 10 63 1. Introduction 65 This document defines a new response code for Session Initiation 66 Protocol (SIP) [2]. This new response code is 495 (URI-List Handling 67 Refused) and can be used by the servers providing SIP Uniform 68 Resource List (URI)-list services [3] that do not want to handle a 69 incoming request. For example, a URI-list server might not want to 70 handle an incoming SIP request carrying a URI-list inside a URI-list. 72 Responses using the 495 (URI-List Handling Refused) response code can 73 carry a URI-List-Entry header field, which is also specified in this 74 document. 76 +---------+ SIP request +----------+ 77 | |------------------------------>| | 78 | | [URI-list in a URI-list] | URI-list | 79 | UAC | | server | 80 | | 495 URI-List Handling Refused | | 81 | |<------------------------------| | 82 +---------+ +----------+ 84 Figure 1: General overview 86 Figure 1 illustrates the usage of the 495 (URI-List Handling Refused) 87 response code. When a URI-list server receives a SIP request (e.g., 88 INVITE), it can return a 495 (URI-List Handling Refused) response 89 back to the UA, if it does not want to fan out the received request. 90 The reason for not processing an incoming request might be, for 91 example, due to local policies. Proxies do not have to perform any 92 special processing for 495 responses, they just forward them to the 93 User Agent Client (UAC) as usual. When an UAC receives a 495 94 response, it knows that the URI-list server has not sent any outbound 95 request. 97 The 495 URI-List Handling Refused response code is useful in the Open 98 Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system [7]. 99 In a given PoC session, one of the PoC servers act as the controlling 100 PoC server while the rest act as participating PoC servers. The only 101 server allowed to handle URI-lists for the session is the controlling 102 PoC server. PoC servers can use the 495 response code to inform the 103 controlling PoC server that they cannot handle a particular URI-list. 105 2. Terminology 107 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 108 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 109 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 110 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 111 compliant implementations. 113 3. Syntax of 495 URI-List Handling Refused 115 Responses using the 495 (URI-List Handling Refused) response code 116 SHOULD contain one or more URI-List-Entry entries. The URI-List- 117 Entry header field contains one or more URIs, which map to URI-lists. 118 The URI-List-Entry header field has two purposes. The first purpose 119 is to inform the UAC which URIs are actually URI-lists that cannot be 120 handled. The second purpose is to optionally give information about 121 the members of the associated URI-list. The Augmented Backus-Naur 122 Form (ABNF) [4] syntax of URI-List-Entry header field is the 123 following: 125 URI-List-Entry = "URI-List-Entry" HCOLON uri-list-entry-parm 126 *(COMMA uri-list-entry-parm) 127 uri-list-entry-parm = ( name-addr / addr-spec ) [ SEMI "members" 128 EQUAL "<" cid-url ">" ] 129 [ *( SEMI generic-param ) ] 131 The HCOLON, SEMI, EQUAL, and generic-param are defined in [2]. The 132 cid-url is defined in [5]. 134 The 495 (URI-List Handling Refused) response MAY contain body parts 135 which have URI-lists. Those body parts are referenced from the URI- 136 List-Entry entries through their Content-IDs [5]. If there is a 137 Content-ID defined in the URI-List-Entry, then one of the body parts 138 MUST have an equivalent Content-ID. The syntax of a URI-list is 139 service specific. This kind of message structure enables UACs to 140 determine which SIP URI relates to which URI-list, if the URI-list 141 server is willing to disclose that information. 143 4. Example Scenario 145 In the following example scenario a UAC sends an INVITE request to a 146 URI-list server. The URI-list server refuses to process the INVITE 147 request and replies with 495 (URI-List Handling Refused). 149 Alice URI-list server 150 | | 151 | INVITE | 152 |-------------------------------->| 153 | | 154 | 495 URI-List Handling Refused | 155 |<--------------------------------| 156 | | 158 Figure 2: Example flow chart 160 Alice is trying to establish a conference with the INVITE request. 161 The content of INVITE request shown in Figure 2 is the following (Via 162 header fields are not shown for simplicity): 164 INVITE sip:urilist-a@example.com SIP/2.0 165 Max-Forwards: 70 166 From: Alice ;tag=4fxaed73sl 167 To: URI-list server A 168 Call-ID: 7xTn9vxNit65XU7p4@example.com 169 CSeq: 1 INVITE 170 Contact: 171 Require: recipient-list-invite 172 Content-Type: multipart/mixed;boundary="boundary1" 173 Content-Length: 538 175 --boundary1 176 Content-Type: application/sdp 178 (SDP not shown) 180 --boundary1 181 Content-Type: application/resource-lists+xml 182 Content-Disposition: recipient-list 184 185 186 187 188 189 190 191 192 --boundary1-- 194 The sip:friends-list@example.com and sip:colleagues-list@example.com 195 in the above example SIP request are actually references to URI-lists 196 on the URI-list server. In this example message the URI-lists are in 197 XML resource list format [6]. 199 The content of 495 reply in Figure 2 is the following (Via header 200 fields are not shown for simplicity): 202 SIP/2.0 495 URI-List Handling Refused 203 From: Alice ;tag=4fxaed73sl 204 To: URI-list server A ;tag=814254 205 Call-ID: 7xTn9vxNit65XU7p4@example.com 206 CSeq: 1 INVITE 207 URI-List-Entry: sip:friends-list@example.com; 208 members= 209 URI-List-Entry: sip:colleagues-list@example.com; 210 members= 211 Conten-Type: multipart/mixed;boundary="boundary1" 212 Content-Length: 745 214 --boundary1 215 Content-Type: application/resource-lists+xml 216 Content-Disposition: uri-list 217 Content-ID: 219 220 221 222 223 224 225 226 228 --boundary1 229 Content-Type: application/resource-lists+xml 230 Content-Disposition: uri-list 231 Content-ID: 233 234 235 236 237 238 239 240 --boundary1-- 242 From the above message an UAC can determine that 243 friend-list@example.com and colleagues-list@example.com are 244 references to URI-lists, and their members are enumerated in the 245 first and second body part respectively. 247 5. Security Considerations 249 Because 495 (URI-List Handling Refused) is just an additional 250 response code to SIP [2], all the general security consideration of 251 SIP also apply to it. Implementors and administrators should also be 252 aware of two special security consideration related to 495 (URI-List 253 Handling Refused): 254 495 response is eavesdropped: 495 response code may contain 255 information about the members of a given URI-list (e.g., 256 'buddylist'). Eavesdroppers can acquire this information if the 257 495 response is not encrypted. Therefore it is RECOMMENDED that 258 either hop-by-hop or end-to-end encryption is used. 259 URI-lists disclosed to rogue entity: A rogue entity may be able to 260 acquire information about the members of a given URI-list (e.g., 261 'buddylist'), if the URI-list server sends information about those 262 URI-lists also to unauthorized users. Therefore it is RECOMMENDED 263 that URI-list server discloses the content of URI-list only to 264 authorized UACs. 266 6. IANA Considerations 268 The IANA is requested to make three additions to the Session 269 Initiation Protocol (SIP) Parameters registry. The first addition is 270 to add the following header field to the already existing Header 271 Fields sub-registry 273 Header Name compact Reference 274 ----------------- ------- --------- 275 URI-List-Entry [RFCxxxx] 277 The second addition is to add the following header field parameter to 278 the already existing Header Field Parameters and Parameter Values 279 sub-registry. 281 Predefined 282 Header Field Parameter Name Values Reference 283 ---------------------------- --------------- --------- --------- 284 URI-List-Entry members No [RFCxxxx] 286 The third addition is to add the following response code to the 287 already existing Methods and Response-Codes sub-registry. 289 Request Failure 4xx 290 495 URI-List Handling Refused [RFCxxxx] 292 Note for the RFC Editor: The three occurrences of 'RFCxxxx' in the 293 above should be a reference to the coming RFC number of this draft. 295 7. References 297 7.1. Normative References 299 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 300 Levels", BCP 14, RFC 2119, March 1997. 302 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 303 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 304 Session Initiation Protocol", RFC 3261, June 2002. 306 [3] Camarillo, G. and A. Roach, "Framework and Security 307 Considerations for Session Initiation Protocol (SIP) Uniform 308 Resource Identifier (URI)-List Services", 309 draft-ietf-sipping-uri-services-05 (work in progress), 310 January 2006. 312 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 313 Specifications: ABNF", RFC 4234, October 2005. 315 [5] Levinson, E., "Content-ID and Message-ID Uniform Resource 316 Locators", RFC 2392, August 1998. 318 7.2. Informative References 320 [6] Rosenberg, J., "Extensible Markup Language (XML) Formats for 321 Representing Resource Lists", 322 draft-ietf-simple-xcap-list-usage-05 (work in progress), 323 February 2005. 325 [7] "OMA PoC System Description: Draft Versio 2.0", April 2006. 327 Authors' Addresses 329 Jani Hautakorpi (editor) 330 Ericsson 331 Hirsalantie 11 332 Jorvas 02420 333 Finland 335 Email: Jani.Hautakorpi@ericsson.com 337 Gonzalo Camarillo 338 Ericsson 339 Hirsalantie 11 340 Jorvas 02420 341 Finland 343 Email: Gonzalo.Camarillo@ericsson.com 345 Intellectual Property Statement 347 The IETF takes no position regarding the validity or scope of any 348 Intellectual Property Rights or other rights that might be claimed to 349 pertain to the implementation or use of the technology described in 350 this document or the extent to which any license under such rights 351 might or might not be available; nor does it represent that it has 352 made any independent effort to identify any such rights. Information 353 on the procedures with respect to rights in RFC documents can be 354 found in BCP 78 and BCP 79. 356 Copies of IPR disclosures made to the IETF Secretariat and any 357 assurances of licenses to be made available, or the result of an 358 attempt made to obtain a general license or permission for the use of 359 such proprietary rights by implementers or users of this 360 specification can be obtained from the IETF on-line IPR repository at 361 http://www.ietf.org/ipr. 363 The IETF invites any interested party to bring to its attention any 364 copyrights, patents or patent applications, or other proprietary 365 rights that may cover technology that may be required to implement 366 this standard. Please address the information to the IETF at 367 ietf-ipr@ietf.org. 369 Disclaimer of Validity 371 This document and the information contained herein are provided on an 372 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 373 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 374 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 375 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 376 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 377 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 379 Copyright Statement 381 Copyright (C) The Internet Society (2006). This document is subject 382 to the rights, licenses and restrictions contained in BCP 78, and 383 except as set forth therein, the authors retain all their rights. 385 Acknowledgment 387 Funding for the RFC Editor function is currently provided by the 388 Internet Society.