doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc5362.txt b/doc/rfc/rfc5362.txt
new file mode 100644
index 0000000..1742763
--- /dev/null
+++ b/doc/rfc/rfc5362.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                       G. Camarillo
+Request for Comments: 5362                                      Ericsson
+Category: Standards Track                                   October 2008
+
+
+ The Session Initiation Protocol (SIP) Pending Additions Event Package
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo                   Standards Track                     [Page 1]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................3
+   3. Overview of Operation ...........................................3
+   4. XML Schema Definition ...........................................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 .......................................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 .........................7
+           5.1.9. Rate of Notifications ...............................7
+           5.1.10. State Agents .......................................7
+           5.1.11. Example ............................................7
+   6. Partial Notifications ...........................................8
+      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 ............................................11
+      7.1. SIP Event Package Registration ............................11
+      7.2. URN Sub-Namespace Registration: consent-status ............12
+      7.3. XML Schema Registration: consent-status ...................12
+      7.4. XML Schema Registration: resource-lists ...................13
+      7.5. MIME Type Registration:
+           application/resource-lists-diff+xml .......................13
+   8. Security Considerations ........................................14
+   9. Acknowledgments ................................................14
+   10. Normative References ..........................................14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo                   Standards Track                     [Page 2]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+1.  Introduction
+
+   The framework for consent-based communications in SIP [RFC5360]
+   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/resource-lists-diff+xml" format, which is based
+   on XML patch operations [RFC5261].
+
+   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/resource-lists-diff+xml"
+   format provides the user agent with the changes the list of resources
+   being added has experimented with since the last notification sent to
+   the 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.
+
+
+
+
+
+Camarillo                   Standards Track                     [Page 3]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+   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 sent 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.
+
+
+
+Camarillo                   Standards Track                     [Page 4]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+   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].  Support for this
+   section (i.e., Section 5) is REQUIRED for implementations of this
+   specification.  Support for partial notifications is optional, but if
+   a subscriber signals support for partial notifications, Section 6
+   MUST be implemented.
+
+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.  Filter
+   documents are not specified in this document and, at the time of
+   writing, they are expected to be the subject of future
+   standardization activity.
+
+   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
+
+
+
+Camarillo                   Standards Track                     [Page 5]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+   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/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
+
+   As stated in Section 3, a document in the "application/resource-
+   lists+xml" format provides the subscriber with the whole list of
+   resources being added to a resource list along with the consent-
+   related status of those resources.  On receiving a NOTIFY request
+   with such a document, the subscriber SHOULD update its local
+   information about the resources being added to the resource list with
+   the information in the document.  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.
+
+
+
+
+
+
+
+Camarillo                   Standards Track                     [Page 6]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+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: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>
+
+
+
+Camarillo                   Standards Track                     [Page 7]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+6.  Partial Notifications
+
+   The lists of resources reported by this event package may contain
+   many resources.  When the "application/resource-lists+xml" format is
+   used and there is a change in the consent-related status of a
+   resource, the server generates a notification with the whole list.
+   Generating large notifications to report small changes does not meet
+   the efficiency requirements of some bandwidth-constrained
+   environments.  The partial notifications mechanism specified in this
+   section is a more efficient way to report changes in the status of
+   resources.
+
+   Subscribers signal support for partial notifications by including the
+   "application/resource-lists-diff+xml" format in the Accept header
+   field of the SUBSCRIBE requests they generate.  If a client
+   subscribing to the Pending Additions event package generates an
+   Accept header field that includes the MIME type
+   "application/resource-lists-diff+xml", the server has the option of
+   returning documents in this format (instead of in the
+   "application/resource-lists+xml" format).
+
+6.1.  Generation of Partial Notifications
+
+   Once a subscription is accepted and installed, the server MUST
+   deliver full state in its first notification.  To report full state,
+   the server uses the regular format for resource lists.  Consequently,
+   the server MUST set the Content-Type header field to the value
+   'application/resource-lists+xml'.
+
+   In order to deliver a partial notification, the server MUST set the
+   Content-Type header field to the value 'application/resource-lists-
+   diff+xml'.  When the server generates a partial notification, the
+   server SHOULD only include the information that has changed since the
+   previous notification.  It is up to the server's local policy to
+   determine what is considered as a change to the previous state.
+
+   The server MUST construct partial notifications according to the
+   following logic: all information that has been added to the document
+   is listed inside <add> elements, all information that has been
+   removed from the 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 with a partial
+   notification until it has received a final response from the
+   subscriber for the previous one or the previous NOTIFY request has
+   timed out.
+
+
+
+
+
+Camarillo                   Standards Track                     [Page 8]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+   When the server receives a SUBSCRIBE request (refresh or termination)
+   within the associated subscription, it SHOULD send a NOTIFY request
+   containing the full document using the 'application/resource-
+   lists+xml' content type.
+
+   If the 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
+   MUST deliver full state using the 'application/resource-lists+xml'
+   content type before generating its first partial notification.
+
+6.2.  Processing of Partial Notifications
+
+   When a subscriber receives the first notification containing full
+   state in a '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
+   the following logic:
+
+   o  If the notification carries an %'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 an 'application/resource-lists-
+      diff+xml' document, the subscriber MUST apply the changes
+      indicated in the received 'application/resource-lists-diff+xml'
+      document to its local copy of the full document.
+
+   If a subscriber encounters a processing error while processing an
+   'application/resource-lists-diff+xml' encoded document, the
+   subscriber SHOULD renew its subscription.  A subscriber can fall back
+   to normal operations by not including the 'application/resource-
+   lists-diff+xml' format in a new SUBSCRIBE request.
+
+   If the server changes the content type used in notifications within
+   the existing subscription, the subscriber MUST discard all the
+   previously received information and process the new content as
+   specified for that content type.
+
+6.3.  XML Schema for Partial Notifications
+
+   This is the XML schema for the "application/resource-lists-diff+xml"
+   data format.  The "urn:ietf:params:xml:schema:xml-patch-ops" schema
+   is defined in [RFC5261].
+
+
+
+
+
+Camarillo                   Standards Track                     [Page 9]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+   <?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>
+
+
+
+Camarillo                   Standards Track                    [Page 10]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+6.4.  Examples
+
+   Section 5.1.11 contains an 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 resulting 'application/resource-lists+xml'
+   document after applying the 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 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].
+
+
+
+
+Camarillo                   Standards Track                    [Page 11]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+   Package name: consent-pending-additions
+
+   Type: package
+
+   Contact: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
+
+   Published Specification: RFC 5362.
+
+7.2.  URN Sub-Namespace 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="http://www.rfc-editor.org/rfc/rfc5362.txt">RFC 5362
+       </a>.</p>
+    </body>
+   </html>
+
+7.3.  XML Schema 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.
+
+
+
+Camarillo                   Standards Track                    [Page 12]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+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 has added a row in the
+   XML schema registry with the following values:
+
+      ID: resource-lists-diff
+      URI: urn:ietf:params:xml:schema:resource-lists-diff
+      Filename: resource-lists-diff
+      Reference [RFC5362]
+
+   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: See Section 10 of [RFC3023] and Section 7 of
+      [RFC4826].
+
+   Interoperability considerations:  none
+   Published specification:  RFC 5362
+   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
+
+
+
+
+Camarillo                   Standards Track                    [Page 13]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+8.  Security Considerations
+
+   "A Framework for Consent-Based Communications in the Session
+   Initiation Protocol (SIP)" [RFC5360] discusses security-related
+   issues that are related to this specification.
+
+   Subscriptions to the Pending Additions event 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 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 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.  Acknowledgments
+
+   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.
+
+
+
+
+
+Camarillo                   Standards Track                    [Page 14]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+   [RFC3265]  Roach, A.B., "Session Initiation Protocol (SIP)-Specific
+              Event Notification", RFC 3265, June 2002.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              January 2004.
+
+   [RFC4826]  Rosenberg, J., "Extensible Markup Language (XML) Formats
+              for Representing Resource Lists", RFC 4826, May 2007.
+
+   [RFC5261]  Urpalainen, J., "An Extensible Markup Language (XML) Patch
+              Operations Framework Utilizing XML Path Language (XPath)
+              Selectors", RFC 5261, September 2008.
+
+   [RFC5360]  Rosenberg, J., Camarillo, G., and D. Willis, "A Framework
+              for Consent-Based Communications in the Session Initiation
+              Protocol (SIP)", RFC 5360, October 2008.
+
+Author's Address
+
+   Gonzalo Camarillo
+   Ericsson
+   Hirsalantie 11
+   Jorvas  02420
+   Finland
+
+   EMail: Gonzalo.Camarillo@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo                   Standards Track                    [Page 15]
+
+RFC 5362            Pending Additions Event Package         October 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (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.
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo                   Standards Track                    [Page 16]
+