draft-ietf-sipping-pending-additions-00.txt   draft-ietf-sipping-pending-additions-01.txt 
SIPPING G. Camarillo SIPPING G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: March 21, 2007 September 17, 2006 Expires: May 29, 2007 November 25, 2006
The Session Initiation Protocol (SIP) Pending Additions Event Package The Session Initiation Protocol (SIP) Pending Additions Event Package
draft-ietf-sipping-pending-additions-00.txt draft-ietf-sipping-pending-additions-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 21, 2007. This Internet-Draft will expire on May 29, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines the SIP Pending Additions event package. This This document defines the SIP Pending Additions event package. This
event package is used by relays to inform user agents about the 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. consent-related status of the entries to be added to a resource list.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 4 4. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 4
5. Pending Additions Event Package Definition . . . . . . . . . . 5 5. Pending Additions Event Package Definition . . . . . . . . . . 5
5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5 5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 3, line 26 skipping to change at page 3, line 26
being added to a resource list that defines a translation. being added to a resource list that defines a translation.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations. compliant implementations.
Any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or Relay: Any SIP server, be it a proxy, B2BUA (Back-to-Back User
some hybrid, that receives a request, translates its Request-URI into Agent), or some hybrid, that receives a request, translates its
one or more next-hop URIs (i.e., recipient URIs), and delivers the Request-URI into one or more next-hop URIs (i.e., recipient URIs),
request to those URIs. and delivers the request to those URIs.
3. Overview of Operation 3. Overview of Operation
A user agent subscribes to a relay using the Pending Additions event A user agent subscribes to a relay using the Pending Additions event
package. NOTIFY requests within this event package can carry an XML package. NOTIFY requests within this event package can carry an XML
document in the "application/resource-lists+xml" format [6] or in the document in the "application/resource-lists+xml" format [6] or in the
"application/xcap-diff+xml" format [7]. "application/xcap-diff+xml" format [7].
A document in the "application/resource-lists+xml" format provides A document in the "application/resource-lists+xml" format provides
the user agent with the whole list of resources being added to a the user agent with the whole list of resources being added to a
skipping to change at page 5, line 24 skipping to change at page 5, line 24
Granted: the resource has granted the relay permission to add the Granted: the resource has granted the relay permission to add the
resource to the relay's translation logic. resource to the relay's translation logic.
5. Pending Additions Event Package Definition 5. Pending Additions Event Package Definition
This section provides the details for defining a SIP [2] event This section provides the details for defining a SIP [2] event
notification package, as specified by RFC 3265 [3]. notification package, as specified by RFC 3265 [3].
5.1. Event Package Name 5.1. Event Package Name
The name of this event package is "pending-additions". This package The name of this event package is "consent-pending-additions". This
name is carried in the Event and Allow-Events header, as defined in package name is carried in the Event and Allow-Events header, as
RFC 3265 [3]. defined in RFC 3265 [3].
5.1.1. Event Package Parameters 5.1.1. Event Package Parameters
This package does not define any event package parameters. This package does not define any event package parameters.
5.1.2. SUBSCRIBE Bodies 5.1.2. SUBSCRIBE Bodies
A SUBSCRIBE for Pending Additions events MAY contain a body. This A SUBSCRIBE for Pending Additions events MAY contain a body. This
body would serve the purpose of filtering the subscription. The body would serve the purpose of filtering the subscription. The
definition of such a body is outside the scope of this specification. definition of such a body is outside the scope of this specification.
skipping to change at page 8, line 12 skipping to change at page 8, line 12
</list> </list>
</resource-lists> </resource-lists>
6. Usage of the Pending Additions Event Package with the XCAP Diff 6. Usage of the Pending Additions Event Package with the XCAP Diff
Format Format
As discussed in Section 5.1.4, if a client subscribing to the Pending As discussed in Section 5.1.4, if a client subscribing to the Pending
Additions event package generates an Accept header field that Additions event package generates an Accept header field that
includes the MIME type "application/xcap-diff+xml", the relay has the includes the MIME type "application/xcap-diff+xml", the relay has the
option of returning documents in this format (instead of in the option of returning documents in this format (instead of in the
'application/pending-additions+xml' format). 'application/consent-pending-additions+xml' format).
Upon initial subscription, the relay does not know which instance of Upon initial subscription, the relay does not know which instance of
the resource list document for the user (where each instance is the resource list document for the user (where each instance is
identified by an etag) the client currently possesses, if any. identified by an etag) the client currently possesses, if any.
Indeed, upon startup, the client will not have any documents. Indeed, upon startup, the client will not have any documents.
The initial NOTIFY request in this case MUST include a <document> The initial NOTIFY request in this case MUST include a <document>
element for the resource list. The "previous-etag" attribute MUST be element for the resource list. The "previous-etag" attribute MUST be
absent, and the "new-etag" attribute MUST be present and contain the absent, and the "new-etag" attribute MUST be present and contain the
entity tag for the current version of the document. An XCAP diff entity tag for the current version of the document. An XCAP diff
skipping to change at page 9, line 15 skipping to change at page 9, line 15
7. IANA Considerations 7. IANA Considerations
There are three IANA considerations associated with this There are three IANA considerations associated with this
specification. specification.
7.1. SIP Event Package Registration 7.1. SIP Event Package Registration
This specification registers a SIP event package per the procedures This specification registers a SIP event package per the procedures
in [3]. in [3].
Package name: pending-additions Package name: consent-pending-additions
Type: package Type: package
Contact: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Contact: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Published Specification: RFC XXXX. (Note to the RFC Editor: Please Published Specification: RFC XXXX. (Note to the RFC Editor: Please
replace XXXX with the RFC Number of this specification.) replace XXXX with the RFC Number of this specification.)
7.2. URN Sub-Namespace Registration 7.2. URN Sub-Namespace Registration
skipping to change at page 10, line 43 skipping to change at page 10, line 43
the integrity and confidentially of the information. In order to the integrity and confidentially of the information. In order to
achieve these, an end-to-end SIP encryption mechanism, such as achieve these, an end-to-end SIP encryption mechanism, such as
S/MIME, as described in RFC 3261 [2], SHOULD be used. S/MIME, as described in RFC 3261 [2], SHOULD be used.
If strong end-to-end security means (such as above) is not available, 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 it is RECOMMENDED that hop-by-hop security based on TLS and SIPS
URIs, as described in [2], is used. URIs, as described in [2], is used.
9. Acknowledgements 9. Acknowledgements
Jonathan Rosenberg provided useful ideas on this document. Jonathan Rosenberg provided useful ideas on this document. Ben
Campbell and Mary Barnes performed a thorough review of this
document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
 End of changes. 10 change blocks. 
15 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/