Internet DRAFT - draft-wang-sip-brs

draft-wang-sip-brs



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 <bsr>.  The <bsr> element
   contains the namespace definition mentioned above.  The <bsr> element
   contains one or more <dialog> elements.

   The <dialog> element is used to specify a particular dialog of
   refreshing subscriptions associated.  The <dialog> element has a
   "callid" attribute.  The value of the "callid" attribute is CALL-ID
   header field's value that <dialog> element presents dialog.

   The <dialog> element contains zero or more <id> elements.  The value
   of the <id> element is subscription's id in the Event header field of
   normal SUBSCRIBE message.  The <id> element has a optional "reason"
   attribute.  The "reason" attribute only includes 200 response of
   BSRM, indicate the reason of refreshing subscription failure with
   <id> element.

   The subscriptions that the <id> elements match will be refreshed by
   BSRM request.  If the <dialog> element contains nothing in BSRM
   request, that all subscriptions inside the dialog that the <dialog>
   element matches will be refreshed.

   If the <dialog> element contains <id> elements in BSRM successful
   response, that the notifier hasn't matched <id> elements with local
   subscription or deal with matched subscription failure, so the
   subscriptions that the <id> elements match in subscriber are
   invalided and need to free.  Another <id> 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 <dialog> elements and <id> elements.  Subscriber
   uses each <dialog> elements that just take out to match the same
   elements in BSRL, if the BSRL has <dialog> elements that aren't
   matched, free the <dialog> associated local dialog.  To matching



Wang                     Expires August 17, 2006                [Page 8]

Internet-Draft               A method to bsr               February 2006


   <dialog> elements, taking out the <id> elements in the particular
   <dialog> element in response, and match the <id> elements to local
   subscriptions and free the matching subscriptions, delete the same
   <id>]]> elements in the particular <dialog> in BSRL, and refreshing
   the remainder <id> 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 <dialog> elements and <id> elements from BSRM
   body.  Notifier uses each <dialog> elements to match local dialog,
   put suited <dialog> elements in 200 response body, and matching the
   <id> elements in particular <dialog> that matched to local
   subscriptions, refreshing the suited subscriptions, put the <id>
   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 <dialog>
   elements and in each <dialog> element has a <id> 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: <sip: other.rls.com>
      From: <sip: local.rls.com>;tag=ie4hbb8t
      Call-ID: cdB34qLToC
      CSeq: 322723822 SUBSCRIBE
      Contact: <sip: local.rls.com>
      Event: presence
      Expires: 7200
      Require: batchrefresh
      Accept: application/bsr+xml
      Content-Type: application/bsr+xml
      Content-Length: ...

      <?xml version="1.0" encoding="UTF-8"?>
      <bsr xmlns="urn:ietf:params:xml:ns:bsr"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
           <dialog callid="dB3hdgss@Alice">
               <id>gg78hs</id>
           </dialog>
           <dialog callid="fG32iert8s@Rocky">
               <id>grti6yq</id>
           </dialog>
           <dialog callid="rttuW65ie@Wing">
               <id>5ty77eer</id>
           </dialog>
       </bsr>


   2.Other RLS take out the <dialog> elements in BSRM request body, all
   the <dialog> elements match dialog on Other RLS, so Other RLS put all
   the <dialog> elements in 200 response body of BSRM.  Because each the
   <id> elements in <dialog> can match subscription, so the <dialog>
   elements in 200 response body of BSRM have no <id> 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: <sip: local.rls.com>;tag=zpNctbZq
      From: <sip: other.rls.com>;tag=ie4hbb8t
      Call-ID: cdB34qLToC
      CSeq: 322723822 SUBSCRIBE`
      Contact: <sip: other.rls.com>
      Expires: 7200
      Content-Type: application/bsr+xml
      Content-Length: ...

      <?xml version="1.0" encoding="UTF-8"?>
      <bsr xmlns="urn:ietf:params:xml:ns:bsr"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
           <dialog callid="dB3hdgss@Alice"/>
           <dialog callid="fG32iert8s@Rocky"/>
           <dialog callid="rttuW65ie@Wing"/>
      </bsr>

































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 version="1.0" encoding="UTF-8"?>
         <xs:schema targetNamespace="urn:ietf:params:xml:ns:bsr"
                xmlns="urn:ietf:params:xml:ns:bsr"
                xmlns:xs="http://www.w3.org/2001/XMLSchema"
                elementFormDefault="qualified">

           <xs:import namespace="http://www.w3.org/XML/1998/namespace"
                            schemaLocation="http://www.w3.org/2001/xml.xsd"/>

           <xs:annotation>
             <xs:documentation xml:lang="en">
               XML Schema Definition for SIP Batch Subscriptions Refreshment.
             </xs:documentation>
           </xs:annotation>

           <xs:element name="bsr" type="BSRType"/>

           <xs:complexType name="BSRType">
             <xs:sequence>
               <xs:element name="dialog" type="DialogType"
                           minOccurs="1"  maxOccurs="unbounded"/>
               </xs:sequence>
           </xs:complexType>

           <xs:complexType name="DialogType">
             <xs:sequence>
               <xs:element name="id" type="IdType"
                           minOccurs="0" maxOccurs="unbounded"/>
               <xs:any namespace="##other" processContents="lax"
                             minOccurs="0" maxOccurs="unbounded"/>
             </xs:sequence>
             <xs:attribute name="callid"  type="xs:string" use="required"/>
             <xs:anyAttribute namespace="##other" processContents="lax"/>
           </xs:complexType>

           <xs:complexType name="IdType">
             <xs:simpleContent>
               <xs:extension base="xs:string">
                 <xs:attribute name="reason" type="xs:string"
                                     use="optional"/>
                 <xs:anyAttribute namespace="##other" processContents="lax"/>
               </xs:extension>
             </xs:simpleContent>
           </xs:complexType>
      </xs:schema>



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
          <?xml version="1.0"?>
          <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
              "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
          <html xmlns="http://www.w3.org/1999/xhtml">
          <head>
            <meta http-equiv="content-type"
               content="text/html;charset=utf-8"/>
            <title>Namespace for SIP Batch Subscriptions Refreshment</title>
          </head>
          <body>
            <h1>Namespace for SIP Batch Subscriptions Refreshment</h1>
            <h2>application/bsr+xml</h2>
            <p>See <a href="[[[URL of published RFC]]]">
               RFCXXXX</a>.</p>
          </body>
          </html>
      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]