Network Working Group Xiao. Wang Internet-Draft Huawei Technologies Expires: August 17, 2006 February 13, 2006 A method to Batch Subscriptions Refreshments draft-wang-sip-brs-00 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 17, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for refreshing batch subscriptions by a message. Subscriber send a message to refresh many subscriptions, and these subscriptions may be in a dialog or in several different dialogs. Wang Expires August 17, 2006 [Page 1] Internet-Draft A method to bsr February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview of BSR . . . . . . . . . . . . . . . . . . . . . . . 6 4. Operation BSR . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Batch Subscriptions Refreshment Message . . . . . . . . . 7 4.2. Negotiation of Support for BSR . . . . . . . . . . . . . . 7 4.3. BSRM Body . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Subscriber Processing of BSR . . . . . . . . . . . . . . . 8 4.5. Notifier Processing of BSR . . . . . . . . . . . . . . . . 9 4.6. Processing of Expires Header . . . . . . . . . . . . . . . 9 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. XML Schema for BSR . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8.1. New SIP Option Tag: batchrefresh . . . . . . . . . . . . . 16 8.2. New MIME type for BRMS Body . . . . . . . . . . . . . . . 16 8.3. URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . 16 9. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Wang Expires August 17, 2006 [Page 2] Internet-Draft A method to bsr February 2006 1. Introduction The SIP-specific event notification mechanism [1] allows a user (the subscriber) to request to be notified of changes in the state of a particular resource. This is accomplished by having the subscriber generate a SUBSCRIBE request for the resource, which is processed by a notifier that represents the resource. SUBSCRIBE request creates subscription between subscriber and notifier, if SUBSCRIBE request send in a dialog then the subscription associated with the dialog, otherwise SUBSCRIBE request will create a new dialog. Subscription is installed using a soft-state mechanism, in order to keep subscription effective during subscription, subscriber needs to send a SUBSCRIBE request to notifier refresh the timer on subscription. A SUBSCRIBE request MAY include an "id" parameter in its "Event" header to allow differentiation between multiple subscriptions in the same dialog. There are two methods to get resource, one is RFC3265 SAID that subscribe single resource by SUBSCRIBE request, the other is event list mechanism [2] In many cases, a subscriber often has a list of resources they are interested in. If using the first method, this will require the subscriber to generate a SUBSCRIBE request for each resource about which they want information, and subscriber need to generate SUBSCRIBE refresh for each individual subscription. For environments in which bandwidth is limited, such as wireless networks, subscribing to each resource individually is problematic. To solve these problems, SIMPLE defines a extension to RFC3265 [1] that allows for requesting and conveying notifications for lists of resources. A resource list is identified by a URI and it represents a list of zero or more URIs. Each of these URIs is an identifier for an individual resource for which the subscriber wants to receive information. The resource list is not restricted to be inside the domain of the subscriber. RLS [2] will act as a subscriber to subscribe non-local resources specified by the list resource. RLS serve to a lot of subscribers, and subscribers may have part of non-local resources in the list resource, RLS will send SUBSCRIBE requests for each non-local resources, so RLS will have a lot of subscriptions with other notifier. For security reason etc., some resources inside domain will not allow to be subscribed directly by non-local domain users. The non-local domain SUBSCRIBE requests must be send a server which send new SUBSCRIBE requests to resource server. Therefore, the server will have a lot of subscriptions with resource server inside domain. Application Server serves to users need information of user register, such as welcome message when user register. Application Server can Wang Expires August 17, 2006 [Page 3] Internet-Draft A method to bsr February 2006 subscribe event package for registration of users, so Application Server will have a lot of subscriptions with registrar. As said, the scenario may be existent that between subscriber and notifier have a lot of subscriptions, especially between servers. In this case, subscriber individually refreshes each subscription is waste to bandwidth and processing capacity of server. This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for refreshing batch subscriptions through a message, called batch subscription refresh. Subscriptions which will be refreshed by a message may be in a same dialog or multiple different dialogs. Wang Expires August 17, 2006 [Page 4] Internet-Draft A method to bsr February 2006 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 and indicate requirement levels for compliant implementations. The following terms are used throughout the remainder of this document. BSR:Batch Subscriptions Refreshment. It is a mechanism provided to improve efficiency of many subscriptions between subscriber and notifier need be refreshed. BSRM:Batch Subscriptions Refreshment Message. It is used to refresh many subscriptions with in subscriber and notifier. BSRL:Batch Subscriptions Refreshment List. A logic construct with in a subscriber that represent subscriptions and subscriptions associate dialogs. For each Batch Subscriptions Refreshment List, its lifetime with in BSRM transaction and be associated with a BSRM. Wang Expires August 17, 2006 [Page 5] Internet-Draft A method to bsr February 2006 3. Overview of BSR This section provides an overview of the typical mode of operation of this extension. It is not normative. When subscriber wishes to use BSR, he need to create BSRM and fill the notifer's SIP URI to BSRM's Request-URI. BSRM body contains dialog's CALL-ID and subscription's id, refer to [5.3]. BSR accords with SIP-specific event notification mechanism [1]], and don't conflict to single subscription refresh. In other words, subscriber MAY use BSR to some subscriptions and use single subscription refresh to others subscriptions, subscriber MAY also use BSR to particular subscriptions first and later convert to use single subscription refresh, vice versa. Even subscriber uses BSR and single subscription refresh to same subscription at one time will not conflict. If a subscriber wishes to perform a subscription refresh with event filters [3] that need to be placed in the body of a request, the mechanism here cannot be used. Rather, the subscriber should perform a normal single subscription refresh using SUBSCRIBE. Wang Expires August 17, 2006 [Page 6] Internet-Draft A method to bsr February 2006 4. Operation BSR 4.1. Batch Subscriptions Refreshment Message BSRM MAY be SUBSCRIBE or a new defined message for BSR. RFC3265 [1] presents that notifier MUST send a NOTIFY message immediately after successfully accepting or refreshing a subscription. However the NOTIFY message to BSR is no significance, so RECOMMENDED notifier doesn't send NOTIFY for BSR. BSRM MAY be sent inside dialog or out of dialog. If BSRM is sent inside a subscription creating dialog, it MAY occur that in the notifier side the dialog has be freed. According RFC3261 [4] presents that notifier must return 481 response. It is no matter to single dialog, but to multiple dialogs that subscriber refreshes though BSRM is a matter. If subscriber receives a 481 response of BSRM and refreshing subscriptions inside multiple dialog, subscriber MUST send a new BSRM inside another subscription dialog or a new BSRM out of dialog. Subscriber sends BSRM out of dialog, fill the notifer's SIP URI to BSRM's Request-URI. The subscriber MUST NOT send a new BSRM request for the same Request- URI until it has received a final response from the notifier for the previous one or the previous BSRM request has timed out. 4.2. Negotiation of Support for BSR This specification uses the SIP option tag mechanism for negotiating support for the extension defined herein. Refer to RFC3261 [4] for the normative description of processing of the "Supported" and "Require" header fields and the 421 (Extension Required) response code. Including "batchrefresh" in a "Require" header field in a BSRM request. 4.3. BSRM Body A BSRM body contains refreshing subscriptions' id and associated dialogs' Call-ID. A BSRM body is an XML document [5] that MUST be well-formed and MUST be valid according to schemas, including extension schemas, available to the validater and applicable to the XML document. The BSRM body documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. The namespace identifier for elements defined by this specification is a URN [6], using the namespace identifier 'ietf' defined by [7] and extended by [8]. This urn is: urn:ietf:params:xml:ns:bsr. The MIME type for the BRMS Body document is "application/bsr+xml". Wang Expires August 17, 2006 [Page 7] Internet-Draft A method to bsr February 2006 The root element of the BSRM body is . The element contains the namespace definition mentioned above. The element contains one or more elements. The element is used to specify a particular dialog of refreshing subscriptions associated. The element has a "callid" attribute. The value of the "callid" attribute is CALL-ID header field's value that element presents dialog. The element contains zero or more elements. The value of the element is subscription's id in the Event header field of normal SUBSCRIBE message. The element has a optional "reason" attribute. The "reason" attribute only includes 200 response of BSRM, indicate the reason of refreshing subscription failure with element. The subscriptions that the elements match will be refreshed by BSRM request. If the element contains nothing in BSRM request, that all subscriptions inside the dialog that the element matches will be refreshed. If the element contains elements in BSRM successful response, that the notifier hasn't matched elements with local subscription or deal with matched subscription failure, so the subscriptions that the elements match in subscriber are invalided and need to free. Another elements that BSRM request contains and BSRM successful response not contains are valid id that SHOULD match subscriber local subscriptions and refresh. 4.4. Subscriber Processing of BSR When subscriber wishes to use BSR, he need create BSRM and fill the notifer's SIP URI to BSRM's Request-URI. We may get the notifer's SIP URI by configuring or other method. Including "batchrefresh" in Require header field in BSRM, and making Content-Type header field in BSRM contains "application/bsr+xml". Filling the dialog CALL-ID header field's value and subscription's id in BSRM body as presenting[5.2] that subscriber want to refresh. At the same time, create BSRL and fill the same content that just put in BSRM body in BSRL. Pay attention to, all subscriptions that will be refreshed together are base on same package type, such as "presence". When receiving 200 response of BSRM, subscriber parses 200 response body, and takes out elements and elements. Subscriber uses each elements that just take out to match the same elements in BSRL, if the BSRL has elements that aren't matched, free the associated local dialog. To matching Wang Expires August 17, 2006 [Page 8] Internet-Draft A method to bsr February 2006 elements, taking out the elements in the particular element in response, and match the elements to local subscriptions and free the matching subscriptions, delete the same ]]> elements in the particular in BSRL, and refreshing the remainder elements in BSRL matching subscriptions. 4.5. Notifier Processing of BSR Notifier checks Require header field in BSRM request, if the header contains "batchrefresh", but notifier doesn't support BSR, return 421 response. If supported, notifier construct 200 response message of BSRM, and take out elements and elements from BSRM body. Notifier uses each elements to match local dialog, put suited elements in 200 response body, and matching the elements in particular that matched to local subscriptions, refreshing the suited subscriptions, put the elements that unmatched and refreshing failing in 200 response body. 4.6. Processing of Expires Header In the BSRM, the value of Expires header field applies to all subscriptions that present in BSRM body. Notifier MUST deal with all subscriptions for this BSRM using the same value of Expires header field in BSRM according to RFC3265 [1]. if Expires header field value equal to 0, this meaning that the subscriber want to free subscriptions for this BSRM, the operation of this case according to RFC3265 [1]. Wang Expires August 17, 2006 [Page 9] Internet-Draft A method to bsr February 2006 5. Example This section gives an example BSR flow. It is not normative. If a conflict arises between this flow and the normative behavior described in this or any other document, the normative descriptions are to be followed. In this particular example, Local RLS act as subscriber to subscribe some of resources on the Other RLS, the resources are presence event package of Alice, Rocky and Wing. We assume that Local RLS and Other RLS have built three dialogs, and each dialog associates a subscription. We use SUBSCRIBE as BSRM. The Other RLS's address-of-record is "sip:other.rls.com", and Local RLS subscribe resources' address-of-record are "sip:Alice@other.rls.com", "sip:Rocky@other.rls.com", "sip:Wing@other.rls.com". Wang Expires August 17, 2006 [Page 10] Internet-Draft A method to bsr February 2006 Local RLS Other RLS (local.rls.com) (other.rls.com) | | | SUBSCRIBE | | sip: Alice@other.rls.com | | Call-ID: dB3hdgss@Alice | | Event: presence; id=gg78hs | |<================dialog1====================>| | | | SUBSCRIBE | | sip: Rocky@other.rls.com | | Call-ID: fG32iert8s@Rocky | | Event: presence; id=grti6yq | |<================dialog2====================>| | | | SUBSCRIBE | | sip: Wing@other.rls.com | | Call-ID: rttuW65ie@Wing | | Event: presence; id=5ty77eer | |<================dialog3====================>| | | | 1. SUBSCRIBE sip:other.rls.com | | Require: batchrefresh | | Event: presence | | Content-Type: application/bsr+xml | |-----------------SUBSCRIBE------------------>| | | | 2. 200 OK sip: local.rls.com | | Content-Type: application/bsr+xml | |<----------------200 OK----------------------| | | | | 1. Local RLS constructs a BSRM request to refresh three subscriptions on Other RLS. In the body, there have three elements and in each element has a element. Wang Expires August 17, 2006 [Page 11] Internet-Draft A method to bsr February 2006 SUBSCRIBE sip: other.rls.com SIP/2.0 Via: SIP/2.0/TCP local.rls.com;branch=z9hG4bKwYb6QREiCL Max-Forwards: 70 To: From: ;tag=ie4hbb8t Call-ID: cdB34qLToC CSeq: 322723822 SUBSCRIBE Contact: Event: presence Expires: 7200 Require: batchrefresh Accept: application/bsr+xml Content-Type: application/bsr+xml Content-Length: ... gg78hs grti6yq 5ty77eer 2.Other RLS take out the elements in BSRM request body, all the elements match dialog on Other RLS, so Other RLS put all the elements in 200 response body of BSRM. Because each the elements in can match subscription, so the elements in 200 response body of BSRM have no elements. Wang Expires August 17, 2006 [Page 12] Internet-Draft A method to bsr February 2006 SIP/2.0 200 OK Via: SIP/2.0/TCP other.rls.com;branch=z9hG4bKwYb6QREiCL To: ;tag=zpNctbZq From: ;tag=ie4hbb8t Call-ID: cdB34qLToC CSeq: 322723822 SUBSCRIBE` Contact: Expires: 7200 Content-Type: application/bsr+xml Content-Length: ... Wang Expires August 17, 2006 [Page 13] Internet-Draft A method to bsr February 2006 6. Security Considerations This specification relies on the Session Initiation Protocol (SIP)- Specific Event Notification mechanism [1]. There may be a vicious user or Server that forge or juggle BSRM, and making the value of Expires header field equal to 0, injecting BSRM body a lot of actual subscriptions. The notifier receive such BSRM may mistaken to think that subscriber want to free the subscriptions, so notitier free the subscriptions according to RFC3265 [1]. This will make a lot of subscriptions on notifier to be wrongfully freed. It is RECOMMENDED that TLS be used between subscriber to notifier hop by hop confidentially protection for BSR. Furthermore, S/MIME MAY be used for integrity and authenticity of BSRM requests. This is described in Section 23 of RFC 3261. The notifier should have the ability to selectively reject BSRM based on the subscriber identity (based on access control lists), using standard SIP authentication mechanisms. Wang Expires August 17, 2006 [Page 14] Internet-Draft A method to bsr February 2006 7. XML Schema for BSR XML Schema Definition for SIP Batch Subscriptions Refreshment. Wang Expires August 17, 2006 [Page 15] Internet-Draft A method to bsr February 2006 8. IANA Considerations 8.1. New SIP Option Tag: batchrefresh This section defines a new option tag for the registry established by section 27.1 of RFC3261 [4]. Option Tag Name: batchrefresh Description: Extension to allow refreshing many subscriptions by a message. Published specification: RFC xxxx [[Note to RFC editor: replace xxxx with the RFC number of this document when published]] 8.2. New MIME type for BRMS Body MIME Media Type Name: application MIME subtype name: bsr+xml Required parameters: None Optional parameters: charset See RFC3023 [9] for a discussion of the charset parameter on XML- derived MIME types. Since this MIME type is used exclusively in SIP, the use of UTF-8 encoding is strongly encouraged. Encoding considerations: 8-bit text Security considerations: Security considerations specific to uses of this this MIME type are discussed in RFC xxxx [[Note to RFC editor: replace xxxx with the RFC number of this document when published]]. RFC1874 [10] and RFC3023 [9] discuss security issues common to all uses of XML. 8.3. URN Sub-Namespace URI: urn:ietf:params:xml:ns:bsr Description: This is the XML namespace URI for XML elements defined by [RFCXXXX] to describe information about refreshing many subscriptions by a message. It is used in the application/bsr+xml body type. Registrant Contact: Wang Expires August 17, 2006 [Page 16] Internet-Draft A method to bsr February 2006 Name: Xiao Wang E-Mail: wangsmile@huawei.com XML: BEGIN Namespace for SIP Batch Subscriptions Refreshment

Namespace for SIP Batch Subscriptions Refreshment

application/bsr+xml

See RFCXXXX.

END 9. Normative References [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [2] Roach, A., Campbell, B., and J. Rosenberg et al., "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", Draft draft-ietf-simple-event-list-07, December 2004. [3] Khartabil, H., "An Extensible Markup Language (XML) Based Format for Event Notification Filtering", Draft draft-ietf-simple-filter-format-05, March 2005. [4] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [5] Bray, T., "Exensible Markup Language (XML) 1.0 (Second Edition)", W3C CR CR-xml11-20011006, October 2000. Wang Expires August 17, 2006 [Page 17] Internet-Draft A method to bsr February 2006 [6] Moats, R., "The URN Syntax", RFC 2141, May 1997. [7] Moats, R., "The URN Namespace for IETF Documents", RFC 2648, August 1999. [8] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [9] Murata, M., Laurent, St., and S. Kohn, "XML Media Types", RFC 3023, January 2001. [10] Levinson, E., "SGML Media Types", RFC 1874, December 1995. Wang Expires August 17, 2006 [Page 18] Internet-Draft A method to bsr February 2006 Author's Address Xiao Wang Huawei Technologies Bantian Shenzhen, Longgang 518129 China Phone: +86 755 28788996 Email: wangsmile@huawei.com Wang Expires August 17, 2006 [Page 19] Internet-Draft A method to bsr 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. Wang Expires August 17, 2006 [Page 20]