idnits 2.17.1 draft-ietf-sipping-pending-additions-03.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, updated by RFC 4748 on line 502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 526. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 467 has weird spacing: '... Change in XM...' -- 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 (November 13, 2007) is 6009 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 (Obsoleted by RFC 6665) == Outdated reference: A later version (-14) exists of draft-ietf-simple-xcap-diff-05 == Outdated reference: A later version (-04) exists of draft-ietf-sip-consent-framework-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING G. Camarillo 3 Internet-Draft Ericsson 4 Intended status: Standards Track November 13, 2007 5 Expires: May 16, 2008 7 The Session Initiation Protocol (SIP) Pending Additions Event Package 8 draft-ietf-sipping-pending-additions-03.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 May 16, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document defines the SIP Pending Additions event package. This 42 event package is used by SIP relays to inform user agents about the 43 consent-related status of the entries to be added to a resource list. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 50 4. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 4 51 5. Pending Additions Event Package Definition . . . . . . . . . . 5 52 5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5 53 5.1.1. Event Package Parameters . . . . . . . . . . . . . . . 5 54 5.1.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . 5 55 5.1.3. Subscription Duration . . . . . . . . . . . . . . . . 5 56 5.1.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . 6 57 5.1.5. Notifier Processing of SUBSCRIBE Requests . . . . . . 6 58 5.1.6. Notifier Generation of NOTIFY Requests . . . . . . . . 6 59 5.1.7. Subscriber Processing of NOTIFY Requests . . . . . . . 6 60 5.1.8. Handling of Forked Requests . . . . . . . . . . . . . 6 61 5.1.9. Rate of Notifications . . . . . . . . . . . . . . . . 7 62 5.1.10. State Agents . . . . . . . . . . . . . . . . . . . . . 7 63 5.1.11. Example . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Usage of the Pending Additions Event Package with the XCAP 65 Diff Format . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 7.1. SIP Event Package Registration . . . . . . . . . . . . . . 9 68 7.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 9 69 7.3. XML Schema Registration . . . . . . . . . . . . . . . . . 10 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 72 10. Normative 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 79 [I-D.ietf-sip-consent-framework] identifies the need for users 80 manipulating the translation logic at a relay (e.g., adding a new 81 recipient) to be informed about the consent-related status of the 82 recipients of a given translation. That is, the user manipulating 83 the translation logic needs to know which recipients have given the 84 relay permission to send them SIP requests. 86 This document defines a SIP event package whereby user agents can 87 subscribe to the consent-related state of the resources that are 88 being added to a resource list that defines a translation. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 Relay: Any SIP server, be it a proxy, B2BUA (Back-to-Back User 97 Agent), or some hybrid, that receives a request, translates its 98 Request-URI into one or more next-hop URIs (i.e., recipient URIs), 99 and delivers the request to those URIs. 101 3. Overview of Operation 103 A user agent subscribes to a relay using the Pending Additions event 104 package. NOTIFY requests within this event package can carry an XML 105 document in the "application/resource-lists+xml" format [RFC4826] or 106 in the "application/xcap-diff+xml" format 107 [I-D.ietf-simple-xcap-diff]. 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 [RFC4825]. 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 [RFC3261] event 178 notification package, as specified by [RFC3265]. 180 5.1. Event Package Name 182 The name of this event package is "consent-pending-additions". This 183 package name is carried in the Event and Allow-Events header, as 184 defined in [RFC3265]. 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 [RFC4826] 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 [I-D.ietf-simple-xcap-diff]. 223 Section 6 discusses the usage of the Pending Additions event package 224 with this format. 226 5.1.5. Notifier Processing of SUBSCRIBE Requests 228 The state of the resources to be added to a relay's translation logic 229 can reveal sensitive information. Therefore, all subscriptions 230 SHOULD be authenticated and then authorized before approval. 231 Authorization policy is at the discretion of the administrator. 233 5.1.6. Notifier Generation of NOTIFY Requests 235 A notifier for the Pending Additions event package SHOULD include the 236 element, which is defined in Section 4. The 237 element MUST be positioned as an instance of the 238 element within the element. 240 Notifications SHOULD be generated for the Pending Additions package 241 whenever there is a change in the consent-related state of a 242 resource. When a resource moves to the error, denied, or granted 243 states, and once a NOTIFY request is sent, the resource is removed 244 from further notifications. 246 5.1.7. Subscriber Processing of NOTIFY Requests 248 NOTIFY requests contain full state. The subscriber does not need to 249 perform any type of information aggregation. 251 5.1.8. Handling of Forked Requests 253 The state of a given resource list is normally handled by a server 254 and stored in a repository. Therefore, there is usually a single 255 place where the resource-list state is resident. This implies that a 256 subscription for this information is readily handled by a single 257 element with access to this repository. There is, therefore, no 258 compelling need for a subscription to pending additions information 259 to fork. As a result, a subscriber MUST NOT create multiple dialogs 260 as a result of a single subscription request. The required 261 processing to guarantee that only a single dialog is established is 262 described in Section 4.4.9 of [RFC3265]. 264 5.1.9. Rate of Notifications 266 For reasons of congestion control, it is important that the rate of 267 notifications not become excessive. As a result, it is RECOMMENDED 268 that the server does not generate notifications for a single 269 subscriber at a rate faster than once every 5 seconds. 271 5.1.10. State Agents 273 State agents have no role in the handling of this package. 275 5.1.11. Example 277 The following is an example of an "application/resource-lists+xml" 278 document that carries consent-related state information using 279 elements: 281 282 285 286 287 Bill Doe 288 pending 289 290 291 Joe Smith 292 pending 293 294 295 Nancy Gross 296 granted 297 298 299 301 6. Usage of the Pending Additions Event Package with the XCAP Diff 302 Format 304 As discussed in Section 5.1.4, if a client subscribing to the Pending 305 Additions event package generates an Accept header field that 306 includes the MIME type "application/xcap-diff+xml", the relay has the 307 option of returning documents in this format (instead of in the 308 'application/resource-list+xml' format). 310 Upon initial subscription, the relay does not know which instance of 311 the resource list document for the user (where each instance is 312 identified by an etag) the client currently possesses, if any. 313 Indeed, upon startup, the client will not have any documents. 315 The initial NOTIFY request in this case MUST include a 316 element for the resource list. The "previous-etag" attribute MUST be 317 absent, and the "new-etag" attribute MUST be present and contain the 318 entity tag for the current version of the document. An XCAP diff 319 document structured this way is called a "reference" XCAP diff 320 document. It establishes the baseline etag and document URI for the 321 document covered by the subscription. 323 Upon receipt of this document, the client can determine whether its 324 local instance document, if any, matches the etag in the XCAP diff 325 document. If they do not match, the client SHOULD perform a 326 conditional GET for each document. The document URI is constructed 327 by appending the XCAP root in the "xcap-root" attribute of the element to the escape coded "doc-selector" from the 329 element. The request is made conditional by including an If-Match 330 header field, with the value of the etag from the element. 331 So long as the documents have not changed between the NOTIFY and the 332 GET, the client will obtain the reference version that the server 333 will use for subsequent notifications. 335 If the conditional GET should fail, the client SHOULD generate a 336 SUBSCRIBE refresh request to trigger a new NOTIFY. The server will 337 always generate a "reference" XML diff document on receipt of a 338 SUBSCRIBE refresh. This establishes a new baseline etag, and the 339 client can then attempt to do another fetch. 341 Once the client has obtained the version of the document identified 342 in the reference XML diff, it can process NOTIFY requests on that 343 subscription. To process the NOTIFY requests, it makes sure that its 344 current version matches the version in the "previous-etag" attribute 345 of the element. If not, the client can then fetch the 346 updated document from the server. If they do match, the client has 347 the most current version. 349 7. IANA Considerations 351 There are three IANA considerations associated with this 352 specification. 354 7.1. SIP Event Package Registration 356 This specification registers a SIP event package per the procedures 357 in [RFC3265]. 359 Package name: consent-pending-additions 361 Type: package 363 Contact: Gonzalo Camarillo 365 Published Specification: RFC XXXX. (Note to the RFC Editor: Please 366 replace XXXX with the RFC Number of this specification.) 368 7.2. URN Sub-Namespace Registration 370 This section registers a new XML namespace per the procedures in 371 [RFC3688]. 373 URI: The URI for this namespace is 374 urn:ietf:params:xml:ns:consent-status 376 Registrant Contact: IETF SIPPING working group, , 377 Gonzalo Camarillo 378 XML: 380 381 383 384 385 387 Pending Additions Extension Namespace 388 389 390

Namespace for Consent-related Status Information Extension

391

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

392

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

395 396 398 7.3. XML Schema Registration 400 This section registers an XML schema per the procedures in [RFC3688]. 402 URI: urn:ietf:params:xml:schema:consent-status. 404 Registrant Contact: IETF SIPPING working group, , 405 Gonzalo Camarillo 407 The XML for this schema can be found in Section 4. 409 8. Security Considerations 411 The Framework for Consent-based Communications in the Session 412 Initiation Protocol (SIP) [I-D.ietf-sip-consent-framework] discusses 413 security-related issues that are related to this specification. 415 Subscriptions to the Pending Additions even package can reveal 416 sensitive information. For this reason, it is RECOMMENDED that 417 relays use strong means for authentication and information 418 confidentiality. Additionally, attackers may attempt to modify the 419 contents of the notifications sent by a relay to its clients. 420 Consequently, it is RECOMMENDED that relays use a strong means for 421 information integrity protection. 423 It is RECOMMENDED that relays authenticate subscribers using the 424 normal SIP authentication mechanisms, such as Digest, as defined in 426 [RFC3261]. 428 The mechanism used for conveying information to clients SHOULD ensure 429 the integrity and confidentially of the information. In order to 430 achieve these, an end-to-end SIP encryption mechanism, such as 431 S/MIME, as described in [RFC3261], SHOULD be used. 433 If strong end-to-end security means (such as above) is not available, 434 it is RECOMMENDED that hop-by-hop security based on TLS and SIPS 435 URIs, as described in [RFC3261], is used. 437 9. Acknowledgements 439 Jonathan Rosenberg provided useful ideas on this document. Ben 440 Campbell and Mary Barnes performed a thorough review of this 441 document. 443 10. Normative References 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, March 1997. 448 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 449 A., Peterson, J., Sparks, R., Handley, M., and E. 450 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 451 June 2002. 453 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 454 Event Notification", RFC 3265, June 2002. 456 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 457 January 2004. 459 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 460 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 462 [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats 463 for Representing Resource Lists", RFC 4826, May 2007. 465 [I-D.ietf-simple-xcap-diff] 466 Rosenberg, J., "An Extensible Markup Language (XML) 467 Document Format for Indicating A Change in XML 468 Configuration Access Protocol (XCAP) Resources", 469 draft-ietf-simple-xcap-diff-05 (work in progress), 470 March 2007. 472 [I-D.ietf-sip-consent-framework] 473 Rosenberg, J., "A Framework for Consent-Based 474 Communications in the Session Initiation Protocol (SIP)", 475 draft-ietf-sip-consent-framework-01 (work in progress), 476 November 2006. 478 Author's Address 480 Gonzalo Camarillo 481 Ericsson 482 Hirsalantie 11 483 Jorvas 02420 484 Finland 486 Email: Gonzalo.Camarillo@ericsson.com 488 Full Copyright Statement 490 Copyright (C) The IETF Trust (2007). 492 This document is subject to the rights, licenses and restrictions 493 contained in BCP 78, and except as set forth therein, the authors 494 retain all their rights. 496 This document and the information contained herein are provided on an 497 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 498 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 499 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 500 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 501 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 502 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 504 Intellectual Property 506 The IETF takes no position regarding the validity or scope of any 507 Intellectual Property Rights or other rights that might be claimed to 508 pertain to the implementation or use of the technology described in 509 this document or the extent to which any license under such rights 510 might or might not be available; nor does it represent that it has 511 made any independent effort to identify any such rights. Information 512 on the procedures with respect to rights in RFC documents can be 513 found in BCP 78 and BCP 79. 515 Copies of IPR disclosures made to the IETF Secretariat and any 516 assurances of licenses to be made available, or the result of an 517 attempt made to obtain a general license or permission for the use of 518 such proprietary rights by implementers or users of this 519 specification can be obtained from the IETF on-line IPR repository at 520 http://www.ietf.org/ipr. 522 The IETF invites any interested party to bring to its attention any 523 copyrights, patents or patent applications, or other proprietary 524 rights that may cover technology that may be required to implement 525 this standard. Please address the information to the IETF at 526 ietf-ipr@ietf.org. 528 Acknowledgment 530 Funding for the RFC Editor function is provided by the IETF 531 Administrative Support Activity (IASA).