SIPPING                                                     G. Camarillo
Internet-Draft                                                  Ericsson
Intended status: Standards Track                       November 13, 2007                       February 15, 2008
Expires: May 16, August 18, 2008

 The Session Initiation Protocol (SIP) Pending Additions Event Package
              draft-ietf-sipping-pending-additions-03.txt
              draft-ietf-sipping-pending-additions-04.txt

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 May 16, August 18, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007). (2008).

Abstract

   This document defines the SIP Pending Additions event package.  This
   event package is used by SIP relays to inform user agents about the
   consent-related status of the entries to be added to a resource list.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  3
   4.  XML Schema Definition  . . . . . . . . . . . . . . . . . . . .  4  3
   5.  Pending Additions Event Package Definition . . . . . . . . . .  5
     5.1.  Event Package Name . . . . . . . . . . . . . . . . . . . .  5
       5.1.1.  Event Package Parameters . . . . . . . . . . . . . . .  5
       5.1.2.  SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . .  5
       5.1.3.  Subscription Duration  . . . . . . . . . . . . . . . .  5
       5.1.4.  NOTIFY Bodies  . . . . . . . . . . . . . . . . . . . .  6  5
       5.1.5.  Notifier Processing of SUBSCRIBE Requests  . . . . . .  6
       5.1.6.  Notifier Generation of NOTIFY Requests . . . . . . . .  6
       5.1.7.  Subscriber Processing of NOTIFY Requests . . . . . . .  6
       5.1.8.  Handling of Forked Requests  . . . . . . . . . . . . .  6
       5.1.9.  Rate of Notifications  . . . . . . . . . . . . . . . .  7
       5.1.10. State Agents . . . . . . . . . . . . . . . . . . . . .  7
       5.1.11. Example  . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Usage of the Pending Additions Event Package with the XCAP
       Diff Format  Partial Notifications  . . . . . . . . . . . . . . . . . . . .  7
     6.1.  Generation of Partial Notifications  . . . . . . . . . . .  8
     6.2.  Processing of Partial Notifications  . . . . . . . . . . .  9
     6.3.  XML Schema for Partial Notifications . . . . . . . . . . .  9
     6.4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9 11
     7.1.  SIP Event Package Registration . . . . . . . . . . . . . .  9 12
     7.2.  URN Sub-Namespace Registration Registration: consent-status . . . . . . 12
     7.3.  XML Schema Registration: consent-status  . . . . . . . .  9
     7.3. . 13
     7.4.  XML Schema Registration Registration: resource-lists  . . . . . . . . . 13
     7.5.  MIME type Registration:
           application/resource-lists-diff+xml  . . . . . . . . . 10 . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10 14
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 15
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 11 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 13 17

1.  Introduction

   The framework for consent-based communications in SIP
   [I-D.ietf-sip-consent-framework] identifies the need for users
   manipulating the translation logic at a relay (e.g., adding a new
   recipient) to be informed about the consent-related status of the
   recipients of a given translation.  That is, the user manipulating
   the translation logic needs to know which recipients have given the
   relay permission to send them SIP requests.

   This document defines a SIP event package whereby user agents can
   subscribe to the consent-related state of the resources that are
   being added to a resource list that defines a translation.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Relay:  Any SIP server, be it a proxy, B2BUA (Back-to-Back User
      Agent), or some hybrid, that receives a request, translates its
      Request-URI into one or more next-hop URIs (i.e., recipient URIs),
      and delivers the request to those URIs.

3.  Overview of Operation

   A user agent subscribes to a relay using the Pending Additions event
   package.  NOTIFY requests within this event package can carry an XML
   document in the "application/resource-lists+xml" format [RFC4826] or
   in the "application/xcap-diff+xml" format
   [I-D.ietf-simple-xcap-diff]. "application/resource-lists-diff+xml" format, which is based
   on XML patch operations [I-D.ietf-simple-xml-patch-ops].

   A document in the "application/resource-lists+xml" format provides
   the user agent with the whole list of resources being added to a
   resource list along with the consent-related status of those
   resources.  A document in the "application/xcap-diff+xml" "application/resource-lists-diff+xml"
   format informs provides the user agent that with the document that describes changes the list of resources
   being added to
   the resource list has changed.  The user agent can then download the
   document in experimented since the "application/resource-lists+xml" format from last notification sent to the
   relay using XCAP [RFC4825].
   user agent.

4.  XML Schema Definition

   This section defines the <consent-status> element, which provides
   consent-related information about a resource to be added to a relay's
   translation logic.

   A consent-status document is an XML document that MUST be well-formed
   and SHOULD be valid.  Consent-status documents MUST be based on XML
   1.0 and MUST be encoded using UTF-8.  This specification makes use of
   XML namespaces for identifying consent-status documents.  The
   namespace URI for elements defined for this purpose is a URN, using
   the namespace identifier 'ietf'.  This URN is:

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

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:consent-status"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:tns="urn:ietf:params:xml:ns:consent-status">
      <xs:element name="consent-status">
         <xs:simpleType>
           <xs:restriction base="xs:string">
             <xs:enumeration value="pending"/>
             <xs:enumeration value="waiting"/>
             <xs:enumeration value="error"/>
             <xs:enumeration value="denied"/>
             <xs:enumeration value="granted"/>
           </xs:restriction>
         </xs:simpleType>
      </xs:element>
   </xs:schema>

   The <consent-status> element can take on the following values:

   Pending:  the relay has received a request to add a resource to its
      translation logic and will ask for permission to do so.

   Waiting:  the relay has requested permission to add the resource to
      its translation logic but has not gotten any answer from the
      resource yet.

   Error:  the relay has requested permission to add the resource to its
      translation logic and has received an error response (e.g., a SIP
      error response to the MESSAGE request send to request permission).
      That is, the permission document requesting permission could not
      be delivered to the resource.

   Denied:  the resource has denied the relay permission to add the
      resource to the relay's translation logic.

   Granted:  the resource has granted the relay permission to add the
      resource to the relay's translation logic.

   Section 5.1.11 contains an example of an "application/
   resource-lists+xml" document that carries consent-related state
   information using <consent-status> elements.

5.  Pending Additions Event Package Definition

   This section provides the details for defining a SIP [RFC3261] event
   notification package, as specified by [RFC3265].

5.1.  Event Package Name

   The name of this event package is "consent-pending-additions".  This
   package name is carried in the Event and Allow-Events header, as
   defined in [RFC3265].

5.1.1.  Event Package Parameters

   This package does not define any event package parameters.

5.1.2.  SUBSCRIBE Bodies

   A SUBSCRIBE for Pending Additions events MAY contain a body.  This
   body would serve the purpose of filtering the subscription.  The
   definition of such a body is outside the scope of this specification.

   A SUBSCRIBE for the Pending Additions event package MAY be sent
   without a body.  This implies that the default session policy
   filtering policy has been requested.  The default policy is that
   notifications are generated every time there is any change in the
   state of a resource in the list.

5.1.3.  Subscription Duration

   The default expiration time for a subscription is one hour (3600
   seconds).

5.1.4.  NOTIFY Bodies

   In this event package, the body of the notifications contains a
   resource list document.  This document describes the resources being
   added as recipients to a translation operation.  All subscribers and
   notifiers MUST support the "application/resource-lists+xml" data
   format [RFC4826] and its extension to carry consent-related state
   information, which is specified in Section 4.  The SUBSCRIBE request
   MAY contain an Accept header field.  If no such header field is
   present, it has a default value of "application/resource-lists+xml".
   If the header field is present, it MUST include "application/
   resource-lists+xml", and MAY include any other types capable of
   representing consent-related state.

   Additionally, all subscribers and notifiers SHOULD support the
   "application/xcap-diff+xml" format [I-D.ietf-simple-xcap-diff].
   "application/resource-lists-diff+xml" format.  Section 6 discusses
   the usage of the Pending Additions event package with this format.

5.1.5.  Notifier Processing of SUBSCRIBE Requests

   The state of the resources to be added to a relay's translation logic
   can reveal sensitive information.  Therefore, all subscriptions
   SHOULD be authenticated and then authorized before approval.
   Authorization policy is at the discretion of the administrator.

5.1.6.  Notifier Generation of NOTIFY Requests

   A notifier for the Pending Additions event package SHOULD include the
   <consent-status> element, which is defined in Section 4.  The
   <consent-status> element MUST be positioned as an instance of the
   <any> element within the <entry> element.

   Notifications SHOULD be generated for the Pending Additions package
   whenever there is a change in the consent-related state of a
   resource.  When a resource moves to the error, denied, or granted
   states, and once a NOTIFY request is sent, the resource is removed
   from further notifications.

5.1.7.  Subscriber Processing of NOTIFY Requests

   NOTIFY requests contain full state.  The subscriber does not need to
   perform any type of information aggregation.  Section 6 discusses the
   use of the Pending Additions event package with partial
   notifications.

5.1.8.  Handling of Forked Requests

   The state of a given resource list is normally handled by a server
   and stored in a repository.  Therefore, there is usually a single
   place where the resource-list state is resident.  This implies that a
   subscription for this information is readily handled by a single
   element with access to this repository.  There is, therefore, no
   compelling need for a subscription to pending additions information
   to fork.  As a result, a subscriber MUST NOT create multiple dialogs
   as a result of a single subscription request.  The required
   processing to guarantee that only a single dialog is established is
   described in Section 4.4.9 of [RFC3265].

5.1.9.  Rate of Notifications

   For reasons of congestion control, it is important that the rate of
   notifications not become excessive.  As a result, it is RECOMMENDED
   that the server does not generate notifications for a single
   subscriber at a rate faster than once every 5 seconds.

5.1.10.  State Agents

   State agents have no role in the handling of this package.

5.1.11.  Example

   The following is an example of an "application/resource-lists+xml"
   document that carries consent-related state information using
   <consent-status> elements:

      <?xml version="1.0" encoding="UTF-8"?>
      <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:cs="urn:ietf:params:xml:ns:consent-status">
       <list>
        <entry uri="sip:bill@example.com">
         <display-name>Bill Doe</display-name>
         <cs:consent-status>pending</cs:consent-status>
        </entry>
        <entry uri="sip:joe@example.com">
         <display-name>Joe Smith</display-name>
         <cs:consent-status>pending</cs:consent-status>
        </entry>
        <entry uri="sip:nancy@example.com">
         <display-name>Nancy Gross</display-name>
         <cs:consent-status>granted</cs:consent-status>
        </entry>
       </list>
      </resource-lists>

6.  Usage  Partial Notifications

   The lists of resources reported by this event package may contain
   many resources.  When the Pending Additions Event Package with the XCAP Diff
    Format

   As discussed "application/resource-lists+xml" format is
   used and there is a change in Section 5.1.4, if the consent-related status of a client subscribing to
   resource, the Pending
   Additions event package server generates an Accept header field that
   includes the MIME type "application/xcap-diff+xml", a notification with the relay has whole list.
   Generating large notifications to report small changes does not meet
   the
   option efficiency requirements of returning documents some bandwidth-constrained
   environments.  The partial notifications mechanism specified in this format (instead of
   section is a more efficient way to report changes in the
   'application/resource-list+xml' format).

   Upon initial subscription, status of
   resources.

   Subscribers signal support for partial notifications by including the relay does not know which instance
   "application/resource-lists-diff+xml" format in the Accept header
   field of the resource list document for SUBSCRIBE requests they generate.  If a client
   subscribing to the user (where each instance is
   identified by Pending Additions event package generates an etag)
   Accept header field that includes the client currently possesses, if any.
   Indeed, upon startup, MIME type "application/
   resource-lists-diff+xml", the client will not have any documents.

   The initial NOTIFY request server has the option of returning
   documents in this case MUST include a <document>
   element for format (instead of in the resource list.  The "previous-etag" attribute MUST be
   absent, "application/
   resource-list+xml" format).

6.1.  Generation of Partial Notifications

   Once a subscription is accepted and installed, the "new-etag" attribute server MUST be present and contain
   deliver full state in its first notification.  To report full state,
   the server uses the
   entity tag regular format for resource lists.  Consequently,
   the current version of server MUST set the document.  An XCAP diff
   document structured this way is called Content-Type header field to the value
   'application/resource-lists+xml'.

   In order to deliver a "reference" XCAP diff
   document.  It establishes partial notification, the baseline etag and document URI for server MUST set the
   document covered by
   Content-Type header field to the subscription.

   Upon receipt of this document, value 'application/
   resource-lists-diff+xml'.  When the client can determine whether its
   local instance document, if any, matches server generates a partial
   notification, the etag in server SHOULD only include the XCAP diff
   document.  If they do not match, information that has
   changed compared to the client SHOULD perform a
   conditional GET for each document.  The document URI previous notification.  It is constructed
   by appending up to the XCAP root in
   server's local policy to determine what is considered as a change to
   the "xcap-root" attribute of previous state.

   The server MUST construct partial notifications according to the <xcap-
   diff> element
   following logic: all the information that has been added to the escape coded "doc-selector"
   document is listed inside <add> elements.  All information that has
   been removed from the <document>
   element. document is listed inside <remove> elements and
   all information that has been changed is listed under <replace>
   elements.

   The server MUST NOT send a new NOTIFY request is made conditional by including an If-Match
   header field, with a partial
   notification until it has received a final response from the value of
   subscriber for the etag from previous one or the <document> element.
   So long as previous NOTIFY request has
   timed out.

   When the documents have not changed between server receives a SUBSCRIBE request (refresh or termination)
   within the associated subscription, it SHOULD send a NOTIFY and request
   containing the
   GET, full document using the client will obtain 'application/
   resource-lists+xml' content type.

   If the reference version that server has used a content type other than 'application/
   resource-lists+xml' in notifications within the existing subscription
   and changes to deliver partial notifications, the server
   will use for subsequent notifications.

   If MUST deliver
   full state using the conditional GET should fail, 'application/resource-lists+xml' content type
   before generating its first partial notification.

6.2.  Processing of Partial Notifications

   When a subscriber receives the client SHOULD generate first notification containing full
   state in a
   SUBSCRIBE refresh request 'application/resource-lists+xml' MIME body, the subscriber
   MUST store the received full document as its local copy.

   When the subscriber receives a subsequent notification, the
   subscriber MUST modify its locally-stored information according to trigger
   the following logic:

   o  If the notification carries a new NOTIFY.  The server will
   always generate 'application/resource-lists+xml'
      document, the subscriber MUST replace its local copy of the
      document with the document received in notification.

   o  If the notification carries a "reference" XML diff 'application/
      resource-lists-diff+xml' document, the subscriber MUST apply the
      changes indicated in the received 'application/
      resource-lists-diff+xml' document on receipt to its local copy of the full
      document.

   If subscriber encounters a
   SUBSCRIBE refresh.  This establishes processing error while processing a new baseline etag, and
   'application/resource-lists-diff+xml' encoded document, the
   client
   subscriber SHOULD renew its subscription.  A subscriber can then attempt fall back
   to do another fetch.

   Once normal operations by not including the client has obtained "application/
   resource-list-diff+xml' format in a new SUBSCRIBE request.

   If the version of server changes the document identified content type used in notifications within
   the reference XML diff, it can process NOTIFY requests on that
   subscription.  To existing subscription, the subscriber MUST discard all the
   previously received information and process the NOTIFY requests, it makes sure new content as
   specified for that its
   current version matches content type.

6.3.  XML Schema for Partial Notifications

   This is the version in XML schema for the "previous-etag" attribute "application/resource-lists-diff+xml"
   data format.  The "urn:ietf:params:xml:schema:xml-patch-ops" schema
   is defined in [I-D.ietf-simple-xml-patch-ops].

   <?xml version="1.0" encoding="UTF-8"?>
     <xs:schema
            targetNamespace="urn:ietf:params:xml:ns:resource-lists"
            xmlns="urn:ietf:params:xml:ns:resource-lists"
            xmlns:xs="http://www.w3.org/2001/XMLSchema"
            elementFormDefault="qualified">

        <!-- include patch-ops type definitions -->
         <xs:include
              schemaLocation="urn:ietf:params:xml:schema:patch-ops"/>

        <!-- partial updates -->
      <xs:element name="resource-lists-diff">
       <xs:sequence minOccurs="0" maxOccurs="unbounded">
        <xs:choice>
         <xs:element name="add">
          <xs:complexType mixed="true">
           <xs:complexContent>
            <xs:extension base="add">
             <xs:anyAttribute processContents="lax"/>
            </xs:extension>
           </xs:complexContent>
          </xs:complexType>
         </xs:element>
         <xs:element name="remove">
          <xs:complexType>
           <xs:complexContent>
            <xs:extension base="remove">
             <xs:anyAttribute processContents="lax"/>
            </xs:extension>
           </xs:complexContent>
          </xs:complexType>
         </xs:element>
         <xs:element name="replace">
          <xs:complexType mixed="true">
           <xs:complexContent>
            <xs:extension base="replace">
             <xs:anyAttribute processContents="lax"/>
            </xs:extension>
           </xs:complexContent>
          </xs:complexType>
         </xs:element>
         <xs:any namespace="##other" processContents="lax"/>
        </xs:choice>
       </xs:sequence>
       <xs:anyAttribute processContents="lax"/>
      </xs:element>
     </xs:schema>

6.4.  Examples

   Section 5.1.11 contains and example of an 'application/
   resource-lists+xml' document, which carries full state.  The
   following is an 'application/resource-lists-diff+xml' partial update
   document:

   <?xml version="1.0" encoding="UTF-8"?>
   <resource-lists-diff xmlns="urn:ietf:params:xml:ns:resource-lists"
    xmlns:cs="urn:ietf:params:xml:ns:consent-status">

  <replace
sel="*/list/entry[@uri='sip:bill@example.com']/cs:consent-status/text()"
  >granted</replace>

   </resource-lists-diff>

   The following is the <document> element.  If not, the client can then fetch the
   updated resulting 'application/resource-lists+xml'
   document from the server.  If they do match, the client has after applying the most current version. partial update:

      <?xml version="1.0" encoding="UTF-8"?>
      <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
       xmlns:cs="urn:ietf:params:xml:ns:consent-status">
       <list>
        <entry uri="sip:bill@example.com">
         <display-name>Bill Doe</display-name>
         <cs:consent-status>granted</cs:consent-status>
        </entry>
        <entry uri="sip:joe@example.com">
         <display-name>Joe Smith</display-name>
         <cs:consent-status>pending</cs:consent-status>
        </entry>
        <entry uri="sip:nancy@example.com">
         <display-name>Nancy Gross</display-name>
         <cs:consent-status>granted</cs:consent-status>
        </entry>
       </list>
      </resource-lists>

7.  IANA Considerations

   There are three five IANA considerations associated with this
   specification.

7.1.  SIP Event Package Registration

   This specification registers a SIP event package per the procedures
   in [RFC3265].

   Package name: consent-pending-additions

   Type: package

   Contact: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>

   Published Specification: RFC XXXX.  (Note to the RFC Editor: Please
   replace XXXX with the RFC Number of this specification.)

7.2.  URN Sub-Namespace Registration Registration: consent-status

   This section registers a new XML namespace per the procedures in
   [RFC3688].

   URI: The URI for this namespace is
   urn:ietf:params:xml:ns:consent-status

   Registrant Contact: IETF SIPPING working group, <sipping@ietf.org>,
   Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>

   XML:

   <?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=iso-8859-1"/>
     <title>Pending Additions Extension Namespace</title>
   </head>
   <body>
     <h1>Namespace for Consent-related Status Information Extension</h1>
     <h2>urn:ietf:params:xml:ns:consent-status</h2>
     <p>See <a href="[URL of published RFC]">RFCXXXX [[NOTE TO
   RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of
   this specification]]</a>.</p>
    </body>
   </html>

7.3.  XML Schema Registration Registration: consent-status

   This section registers an XML schema per the procedures in [RFC3688].

   URI: urn:ietf:params:xml:schema:consent-status.

   Registrant Contact: IETF SIPPING working group, <sipping@ietf.org>,
   Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>

   The XML for this schema can be found in Section 4.

7.4.  XML Schema Registration: resource-lists

   This section registers an XML schema per the procedures in [RFC3688].
   This XML schema is an extension to the XML schema (whose ID is
   resource-list) defined in [RFC4826].  The IANA is requested to add a
   row in the XML schema registry with the following values:

       ID: resource-list-diff
       URI: urn:ietf:params:xml:schema:resource-lists-diff
       Filename: resource-lists-diff
       Reference [RFCxxxx]

   (Note to the RFC Editor: Please replace XXXX with the RFC Number of
   this specification.)

   Registrant Contact: IETF SIPPING working group, <sipping@ietf.org>,
   Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>

   The XML for this schema can be found in Section 6.3.

7.5.  MIME type Registration: application/resource-lists-diff+xml

   This section registers the 'application/resource-lists-diff+xml' MIME
   type.

   MIME media type name:  application
   MIME subtype name:  resource-lists-diff+xml
      Mandatory parameters: none
   Optional Parameters:  Same as charset parameter application/xml as
      specified in [RFC3023].
   Encoding considerations:  Same as encoding considerations of
      application/xml as specified in [RFC3023].
   Security considerations:  Security considerations: See Section 10 of
      [RFC3023] and Section 7 of [RFC4826].

   Interoperability considerations:  none
   Published specification:  RFC xxxx (Note to the RFC Editor: Please
      replace XXXX with the RFC Number of this specification.)
   Applications that use this media type:  This document type has been
      defined to support partial notifications in subscriptions to
      resource lists.

   Additional Information:

   Magic Number:  none
   File extension:  .rld
   Macintosh file type code:  "TEXT"
   Personal and email address for further information:  Gonzalo
      Camarillo <Gonzalo.Camarillo@ericsson.com>
   Intended usage:  COMMON
   Author/Change controller:  The IETF.

8.  Security Considerations

   The Framework for Consent-based Communications in the Session
   Initiation Protocol (SIP) [I-D.ietf-sip-consent-framework] discusses
   security-related issues that are related to this specification.

   Subscriptions to the Pending Additions even package can reveal
   sensitive information.  For this reason, it is RECOMMENDED that
   relays use strong means for authentication and information
   confidentiality.  Additionally, attackers may attempt to modify the
   contents of the notifications sent by a relay to its clients. subscribers.
   Consequently, it is RECOMMENDED that relays use a strong means for
   information integrity protection.

   It is RECOMMENDED that relays authenticate subscribers using the
   normal SIP authentication mechanisms, such as Digest, as defined in
   [RFC3261].

   The mechanism used for conveying information to clients subscribers SHOULD
   ensure the integrity and confidentially of the information.  In order
   to achieve these, an end-to-end SIP encryption mechanism, such as
   S/MIME, as described in [RFC3261], SHOULD be used.

   If strong end-to-end security means (such as above) is not available,
   it is RECOMMENDED that hop-by-hop security based on TLS and SIPS
   URIs, as described in [RFC3261], is used.

9.  Acknowledgements

   Jonathan Rosenberg provided useful ideas on this document.  Ben
   Campbell and Mary Barnes performed a thorough review of this
   document.  Jari Urpalainen helped improve the partial notifications
   mechanism.

10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
              Event Notification", RFC 3265, June 2002.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC4825]  Rosenberg, J., "The Extensible Markup Language (XML)
              Configuration Access Protocol (XCAP)", RFC 4825, May 2007.

   [RFC4826]  Rosenberg, J., "Extensible Markup Language (XML) Formats
              for Representing Resource Lists", RFC 4826, May 2007.

   [I-D.ietf-simple-xcap-diff]
              Rosenberg,

   [I-D.ietf-simple-xml-patch-ops]
              Urpalainen, J., "An Extensible Markup Language (XML)
              Document Format for Indicating A Change  in Patch
              Operations Framework Utilizing XML
              Configuration Access Protocol (XCAP) Resources",
              draft-ietf-simple-xcap-diff-05  Path Language (XPath)
              Selectors", draft-ietf-simple-xml-patch-ops-02 (work in
              progress), March 2007. 2006.

   [I-D.ietf-sip-consent-framework]
              Rosenberg, J., "A Framework for Consent-Based
              Communications in the Session Initiation  Protocol (SIP)",
              draft-ietf-sip-consent-framework-01 (work in progress),
              November 2006.

Author's Address

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007). (2008).

   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.

   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, THE IETF TRUST 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.

Intellectual Property

   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.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).