idnits 2.17.1 draft-camarillo-sipping-pending-additions-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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 503. ** 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 == Line 466 has weird spacing: '... Change in XM...' == 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 (June 12, 2006) is 6526 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) ** Obsolete normative reference: RFC 3265 (ref. '3') (Obsoleted by RFC 6665) == Outdated reference: A later version (-05) exists of draft-ietf-sipping-consent-framework-04 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-consent-framework (ref. '5') == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-11 == Outdated reference: A later version (-14) exists of draft-ietf-simple-xcap-diff-03 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING G. Camarillo 2 Internet-Draft Ericsson 3 Expires: December 14, 2006 June 12, 2006 5 The Session Initiation Protocol (SIP) Pending Additions Event Package 6 draft-camarillo-sipping-pending-additions-00.txt 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 14, 2006. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 37 Abstract 39 This document defines the SIP Pending Additions event package. This 40 event package is used by relays to inform user agents about the 41 consent-related status of the entries to be added to a resource list. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 48 4. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 4 49 5. Pending Additions Event Package Definition . . . . . . . . . . 5 50 5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5 51 5.1.1. Event Package Parameters . . . . . . . . . . . . . . . 5 52 5.1.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . 5 53 5.1.3. Subscription Duration . . . . . . . . . . . . . . . . 5 54 5.1.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . 6 55 5.1.5. Notifier Processing of SUBSCRIBE Requests . . . . . . 6 56 5.1.6. Notifier Generation of NOTIFY Requests . . . . . . . . 6 57 5.1.7. Subscriber Processing of NOTIFY Requests . . . . . . . 6 58 5.1.8. Handling of Forked Requests . . . . . . . . . . . . . 6 59 5.1.9. Rate of Notifications . . . . . . . . . . . . . . . . 7 60 5.1.10. State Agents . . . . . . . . . . . . . . . . . . . . . 7 61 5.1.11. Example . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Usage of the Pending Additions Event Package with the XCAP 63 Diff Format . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 7.1. SIP Event Package Registration . . . . . . . . . . . . . . 9 66 7.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 9 67 7.3. XML Schema Registration . . . . . . . . . . . . . . . . . 10 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Intellectual Property and Copyright Statements . . . . . . . . . . 13 76 1. Introduction 78 The framework for consent-based communications in SIP [5] identifies 79 the need for users manipulating the translation logic at a relay 80 (e.g., adding a new recipient) to be informed about the consent- 81 related status of the recipients of a given translation. That is, 82 the user manipulating the translation logic needs to know which 83 recipients have given the relay permission to send them SIP requests. 85 This document defines a SIP event package whereby user agents can 86 subscribe to the consent-related state of the resources that are 87 being added to a resource list that defines a translation. 89 2. Terminology 91 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 92 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 93 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 94 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 95 compliant implementations. 97 Any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or 98 some hybrid, that receives a request, translates its Request-URI into 99 one or more next-hop URIs (i.e., recipient URIs), and delivers the 100 request to those URIs. 102 3. Overview of Operation 104 A user agent subscribes to a relay using the Pending Additions event 105 package. NOTIFY requests within this event package can carry an XML 106 document in the "application/resource-lists+xml" format [7] or in the 107 "application/xcap-diff+xml" format [8]. 109 A document in the "application/resource-lists+xml" format provides 110 the user agent with the whole list of resources being added to a 111 resource list along with the consent-related status of those 112 resources. 114 A document in the "application/xcap-diff+xml" format informs the user 115 agent that the document that describes the resources being added to 116 the resource list has changed. The user agent can then download the 117 document in the "application/resource-lists+xml" format from the 118 relay using XCAP [6]. 120 4. XML Schema Definition 122 This section defines the element, which provides 123 consent-related information about a resource to be added to a relay's 124 translation logic. 126 A consent-status document is an XML document that MUST be well-formed 127 and SHOULD be valid. Consent-status documents MUST be based on XML 128 1.0 and MUST be encoded using UTF-8. This specification makes use of 129 XML namespaces for identifying consent-status documents. The 130 namespace URI for elements defined for this purpose is a URN, using 131 the namespace identifier 'ietf'. This URN is: 133 urn:ietf:params:xml:ns:consent-status 135 136 141 142 143 144 145 146 147 148 149 150 151 152 154 The element can take on the following values: 156 Pending: the relay has received a request to add a resource to its 157 translation logic and will ask for permission to do so. 159 Waiting: the relay has requested permission to add the resource to 160 its translation logic but has not gotten any answer from the 161 resource yet. 163 Error: the relay has requested permission to add the resource to its 164 translation logic and has received an error response (e.g., a SIP 165 error response to the MESSAGE request send to request permission). 166 That is, the permission document requesting permission could not 167 be delivered to the resource. 169 Denied: the resource has denied the relay permission to add the 170 resource to the relay's translation logic. 172 Granted: the resource has granted the relay permission to add the 173 resource to the relay's translation logic. 175 5. Pending Additions Event Package Definition 177 This section provides the details for defining a SIP [2] event 178 notification package, as specified by RFC 3265 [3]. 180 5.1. Event Package Name 182 The name of this event package is "pending-additions". This package 183 name is carried in the Event and Allow-Events header, as defined in 184 RFC 3265 [3]. 186 5.1.1. Event Package Parameters 188 This package does not define any event package parameters. 190 5.1.2. SUBSCRIBE Bodies 192 A SUBSCRIBE for Pending Additions events MAY contain a body. This 193 body would serve the purpose of filtering the subscription. The 194 definition of such a body is outside the scope of this specification. 196 A SUBSCRIBE for the Pending Additions event package MAY be sent 197 without a body. This implies that the default session policy 198 filtering policy has been requested. The default policy is that 199 notifications are generated every time there is any change in the 200 state of a resource in the list. 202 5.1.3. Subscription Duration 204 The default expiration time for a subscription is one hour (3600 205 seconds). 207 5.1.4. NOTIFY Bodies 209 In this event package, the body of the notifications contains a 210 resource list document. This document describes the resources being 211 added as recipients to a translation operation. All subscribers and 212 notifiers MUST support the "application/resource-lists+xml" data 213 format [7] and its extension to carry consent-related state 214 information, which is specified in Section 4. The SUBSCRIBE request 215 MAY contain an Accept header field. If no such header field is 216 present, it has a default value of "application/resource-lists+xml". 217 If the header field is present, it MUST include "application/ 218 resource-lists+xml", and MAY include any other types capable of 219 representing consent-related state. 221 Additionally, all subscribers and notifiers SHOULD support the 222 "application/xcap-diff+xml" format [8]. Section 6 discusses the 223 usage of the Pending Additions event package with this format. 225 5.1.5. Notifier Processing of SUBSCRIBE Requests 227 The state of the resources to be added to a relay's translation logic 228 can reveal sensitive information. Therefore, all subscriptions 229 SHOULD be authenticated and then authorized before approval. 230 Authorization policy is at the discretion of the administrator. 232 5.1.6. Notifier Generation of NOTIFY Requests 234 A notifier for the Pending Additions event package SHOULD include the 235 element, which is defined in Section 4. The 236 element MUST be positioned as an instance of the 237 element within the element. 239 Notifications SHOULD be generated for the Pending Additions package 240 whenever there is a change in the consent-related state of a 241 resource. When a resource moves to the error, denied, or granted 242 states, and once a NOTIFY request is sent, the resource is removed 243 from further notifications. 245 5.1.7. Subscriber Processing of NOTIFY Requests 247 NOTIFY requests contain the full resource-list state. The subscriber 248 does not need to perform any type of information aggregation. 250 5.1.8. Handling of Forked Requests 252 The state of a given resource list is normally handled by a server 253 and stored in a repository. Therefore, there is usually a single 254 place where the resource-list state is resident. This implies that a 255 subscription for this information is readily handled by a single 256 element with access to this repository. There is, therefore, no 257 compelling need for a subscription to pending additions information 258 to fork. As a result, a subscriber MUST NOT create multiple dialogs 259 as a result of a single subscription request. The required 260 processing to guarantee that only a single dialog is established is 261 described in Section 4.4.9 of RFC 3265 [3]. 263 5.1.9. Rate of Notifications 265 For reasons of congestion control, it is important that the rate of 266 notifications not become excessive. As a result, it is RECOMMENDED 267 that the server does not generate notifications for a single 268 subscriber at a rate faster than once every 5 seconds. 270 5.1.10. State Agents 272 State agents have no role in the handling of this package. 274 5.1.11. Example 276 The following is an example of an "application/resource-lists+xml" 277 document that carries consent-related state information using 278 elements: 280 281 284 285 286 Bill Doe 287 pending 288 289 290 Joe Smith 291 pending 292 293 294 Nancy Gross 295 granted 296 297 298 300 6. Usage of the Pending Additions Event Package with the XCAP Diff 301 Format 303 As discussed in Section 5.1.4, if a client subscribing to the Pending 304 Additions event package generates an Accept header field that 305 includes the MIME type "application/xcap-diff+xml", the relay has the 306 option of returning documents in this format (instead of in the 307 'application/pending-additions+xml' format). 309 Upon initial subscription, the relay does not know which instance of 310 the resource list document for the user (where each instance is 311 identified by an etag) the client currently possesses, if any. 312 Indeed, upon startup, the client will not have any documents. 314 The initial NOTIFY request in this case MUST include a 315 element for the resource list. The "previous-etag" attribute MUST be 316 absent, and the "new-etag" attribute MUST be present and contain the 317 entity tag for the current version of the document. An XCAP diff 318 document structured this way is called a "reference" XCAP diff 319 document. It establishes the baseline etag and document URI for the 320 document covered by the subscription. 322 Upon receipt of this document, the client can determine whether its 323 local instance document, if any, matches the etag in the XCAP diff 324 document. If they do not match, the client SHOULD perform a 325 conditional GET for each document. The document URI is constructed 326 by appending the XCAP root in the "xcap-root" attribute of the element to the escape coded "doc-selector" from the 328 element. The request is made conditional by including an If-Match 329 header field, with the value of the etag from the element. 330 So long as the documents have not changed between the NOTIFY and the 331 GET, the client will obtain the reference version that the server 332 will use for subsequent notifications. 334 If the conditional GET should fail, the client SHOULD generate a 335 SUBSCRIBE refresh request to trigger a new NOTIFY. The server will 336 always generate a "reference" XML diff document on receipt of a 337 SUBSCRIBE refresh. This establishes a new baseline etag, and the 338 client can then attempt to do another fetch. 340 Once the client has obtained the version of the document identified 341 in the reference XML diff, it can process NOTIFY requests on that 342 subscription. To process the NOTIFY requests, it makes sure that its 343 current version matches the version in the "previous-etag" attribute 344 of the element. If not, the client can then fetch the 345 updated document from the server. If they do match, the client has 346 the most current version. 348 7. IANA Considerations 350 There are three IANA considerations associated with this 351 specification. 353 7.1. SIP Event Package Registration 355 This specification registers a SIP event package per the procedures 356 in [3]. 358 Package name: pending-additions 360 Type: package 362 Contact: Gonzalo Camarillo 364 Published Specification: RFC XXXX. (Note to the RFC Editor: Please 365 replace XXXX with the RFC Number of this specification.) 367 7.2. URN Sub-Namespace Registration 369 This section registers a new XML namespace per the procedures in [4]. 371 URI: The URI for this namespace is 372 urn:ietf:params:xml:ns:consent-status 374 Registrant Contact: IETF SIPPING working group, , 375 Gonzalo Camarillo 377 XML: 379 380 382 383 384 386 Pending Additions Extension Namespace 387 388 389

Namespace for Consent-related Status Information Extension

390

urn:ietf:params:xml:ns:consent-status

391

See RFCXXXX [[NOTE TO 392 RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of 393 this specification]].

394 395 397 7.3. XML Schema Registration 399 This section registers an XML schema per the procedures in [4]. 401 URI: urn:ietf:params:xml:schema:consent-status. 403 Registrant Contact: IETF SIPPING working group, , 404 Gonzalo Camarillo 406 The XML for this schema can be found in Section 4. 408 8. Security Considerations 410 Subscriptions to the Pending Additions even package can reveal 411 sensitive information. For this reason, it is RECOMMENDED that 412 relays use strong means for authentication and information 413 confidentiality. Additionally, attackers may attempt to modify the 414 contents of the notifications sent by a relay to its clients. 415 Consequently, it is RECOMMENDED that relays use a strong means for 416 information integrity protection. 418 It is RECOMMENDED that relays authenticate subscribers using the 419 normal SIP authentication mechanisms, such as Digest, as defined in 420 RFC 3261 [2]. 422 The mechanism used for conveying information to clients SHOULD ensure 423 the integrity and confidentially of the information. In order to 424 achieve these, an end-to-end SIP encryption mechanism, such as 425 S/MIME, as described in RFC 3261 [2], SHOULD be used. 427 If strong end-to-end security means (such as above) is not available, 428 it is RECOMMENDED that hop-by-hop security based on TLS and SIPS 429 URIs, as described in [2], is used. 431 9. Acknowledgements 433 Jonathan Rosenberg provided useful ideas on this document. 435 10. References 436 10.1. Normative References 438 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 439 Levels", BCP 14, RFC 2119, March 1997. 441 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 442 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 443 Session Initiation Protocol", RFC 3261, June 2002. 445 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 446 Notification", RFC 3265, June 2002. 448 [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 449 January 2004. 451 [5] Rosenberg, J., "A Framework for Consent-Based Communications in 452 the Session Initiation Protocol (SIP)", 453 draft-ietf-sipping-consent-framework-04 (work in progress), 454 March 2006. 456 [6] Rosenberg, J., "The Extensible Markup Language (XML) 457 Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-11 458 (work in progress), May 2006. 460 [7] Rosenberg, J., "Extensible Markup Language (XML) Formats for 461 Representing Resource Lists", 462 draft-ietf-simple-xcap-list-usage-05 (work in progress), 463 February 2005. 465 [8] Rosenberg, J., "An Extensible Markup Language (XML) Document 466 Format for Indicating A Change in XML Configuration Access 467 Protocol (XCAP) Resources", draft-ietf-simple-xcap-diff-03 (work 468 in progress), March 2006. 470 10.2. Informative References 471 Author's Address 473 Gonzalo Camarillo 474 Ericsson 475 Hirsalantie 11 476 Jorvas 02420 477 Finland 479 Email: Gonzalo.Camarillo@ericsson.com 481 Intellectual Property Statement 483 The IETF takes no position regarding the validity or scope of any 484 Intellectual Property Rights or other rights that might be claimed to 485 pertain to the implementation or use of the technology described in 486 this document or the extent to which any license under such rights 487 might or might not be available; nor does it represent that it has 488 made any independent effort to identify any such rights. Information 489 on the procedures with respect to rights in RFC documents can be 490 found in BCP 78 and BCP 79. 492 Copies of IPR disclosures made to the IETF Secretariat and any 493 assurances of licenses to be made available, or the result of an 494 attempt made to obtain a general license or permission for the use of 495 such proprietary rights by implementers or users of this 496 specification can be obtained from the IETF on-line IPR repository at 497 http://www.ietf.org/ipr. 499 The IETF invites any interested party to bring to its attention any 500 copyrights, patents or patent applications, or other proprietary 501 rights that may cover technology that may be required to implement 502 this standard. Please address the information to the IETF at 503 ietf-ipr@ietf.org. 505 Disclaimer of Validity 507 This document and the information contained herein are provided on an 508 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 509 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 510 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 511 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 512 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 513 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 515 Copyright Statement 517 Copyright (C) The Internet Society (2006). This document is subject 518 to the rights, licenses and restrictions contained in BCP 78, and 519 except as set forth therein, the authors retain all their rights. 521 Acknowledgment 523 Funding for the RFC Editor function is currently provided by the 524 Internet Society.