SIMPLE WG M. Lonnfors
Internet-Draft Nokia Research Center
Expires: April 12, 2005 E. Leppanen
Nokia
A. Niemi
Nokia Research Center
October 12, 2004
Partial Publication of Presence Information
draft-ietf-simple-partial-publish-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 April 12, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
The size of the published presence information document may be large.
As specified in "Event State Publication Extension to the Session
Initiation Protocol (SIP)" a presence user agent publishes a full
event state of presence information in every publication operation
Lonnfors, et al. Expires April 12, 2005 [Page 1]
Internet-Draft Partial Publication October 2004
which modifies the current event state. This is done regardless of
which presence information has been changed compared to the earlier
publications.
It may not be reasonable to send the full presence information over
low bandwidth and high latency links when only a part of presence
information changes. This memo presents a solution that aids in
reducing the impact of those constrains and increasing transport
efficiency, by introducing a mechanism called partial publication.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Document Conventions . . . . . . . . . . . . . 3
3. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Overall Operation of Event State Publication . . . . . . . 4
3.2 Overview of Partial Publication . . . . . . . . . . . . . 4
4. Client and server operations . . . . . . . . . . . . . . . . . 5
4.1 Content-type for Partial Publications . . . . . . . . . . 5
4.2 Presence User Agent Generation of PUBLISH Requests . . . . 5
4.3 Presence Agent Processing PUBLISH Requests . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . 9
5.2 Access Control . . . . . . . . . . . . . . . . . . . . . . 9
5.3 Replay Prevention . . . . . . . . . . . . . . . . . . . . 9
5.4 Denial of Service Attacks . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Normative references . . . . . . . . . . . . . . . . . . . . 10
7.2 Informative references . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 12
Lonnfors, et al. Expires April 12, 2005 [Page 2]
Internet-Draft Partial Publication October 2004
1. Introduction
Event State Publication Extension to the Session Initiation Protocol
(SIP) [3] allows Presence User Agents ('PUA') to publish presence
information of a user ('presentity'). The Presence Agent ('PA')
collects publications for a presentity from one or several presence
user agents, and generates the composite event state of the
presentity.
The base format of the presence information is defined in PIDF [4]
and used by the Event State Publication Extension to SIP [3]. The
presence information is grouped into elements called "tuples". There
may also be some presence information outside the tuple elements.
More information about the presence information model can be found
from RFC 2778 [5].
The size of the published presence information document may be large.
As specified in the Event State Publication Extension to SIP [3] a
PUA publishes its full event state of presence information in every
modify operation of a publication. This is done regardless of what
presence information have been changed compared to the earlier
publications. It may not be reasonable to send the full presence
information over low bandwidth and high latency links when only a
part of presence information changes.
This memo specifies a mechanism called 'partial publication' for the
PUA to be able to publish only changed parts of presence information
compared to the information delivered in the previous publications.
2. Definitions and Document Conventions
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 [1] and
indicate requirement levels for compliant implementations.
This document makes use of the vocabulary defined in RFC 2778 [5],
the State Publication Extension to SIP [3], and PIDF Extension to
Partial Presence [2]. This document introduces the following terms:
Publication Context: A sequence of PUBLISH requests starting from an
initial publication of an event state and ending at a removal or
expiration of the event state.
3. Overall Operation
This chapter introduces the basic functionality of the event state
publication, and gives an overview of the partial publication
Lonnfors, et al. Expires April 12, 2005 [Page 3]
Internet-Draft Partial Publication October 2004
mechanism. This section is informational in nature. It does not
contain any normative statements.
3.1 Overall Operation of Event State Publication
The publication of presence information operates so that a presence
user agent sends a PUBLISH request targeted to the Request URI of the
presentity. The body of the PUBLISH request carries a full event
state of presence information when the event state is either
published first time or modified.
The PA receives and processes the PUBLISH request according to the
Event State Publication Extension to SIP [3]. In case of a
successful PUBLISH request the PA assigns an identifier
('entity-tag') to the published event state.
The PUA uses the entity-tag in the next PUBLISH request for
identifying the event state that the request is refreshing, modifying
or removing. The "id" attribute of each tuple is kept unchanged to
have unique tuple values.
3.2 Overview of Partial Publication
The partial publication mechanism enables the PUA to publish only
presence information that have actually changed.
The partial publication mechanism can be applied to the initial and
modify operations of the event state publication [3]. Normally the
partial publication applies to the initial publication where the full
event state is published, and in consecutive "modify" operations the
partial event state is published. The "modify" operation can also
publish the full event state. The full event state initializes the
internal version counter for the future partial event states.
When the PUA decides to start partial publications the PUA first
publishes the full event state using the
'application/pidf-partial+xml' content type. After that the partial
event states are published. The partial event state may contain new
tuple elements, tuple elements which content have changed and/or a
list of removed tuple elements compared to previously published
tuples. Additionally, the state may contain presence information
outside the tuple elements.
The PUA constructs a PUBLISH request using the partial publication
mechanism according to the Event State Publication Extension to SIP
[3], PIDF Extension to Partial Presence [2] and this specification.
When a presence agent receives a partial publication the PA looks
Lonnfors, et al. Expires April 12, 2005 [Page 4]
Internet-Draft Partial Publication October 2004
into the "state" attribute (defined in the PIDF Extension to Partial
Presence [2]) for resolving if the publication contains a full or
partial event state. In case of the full event state the PA replaces
a possibly existing event state with the new one and stores the
version number received in the PUBLISH request to be used as basis
for partial event states. In case of the partial event state the PA
uses the "id" attribute of each tuple as defined in the PIDF [4] and
existing event state stored in the PA for constructing a new local
copy of the full event state.
4. Client and server operations
Unless otherwise specified in this document, the reqular presence
user agent and presence agent behavior are applied as defined in the
Event State Publication Extension to SIP [3].
4.1 Content-type for Partial Publications
The entities supporting the partial publication extension described
in this document MUST support the 'application/pidf-partial+xml'
content type defined in the PIDF Extension for Partial Presence [2].
4.2 Presence User Agent Generation of PUBLISH Requests
When a presence user agent decides to use the partial publication
mechanism the PUA sets the Content Type header field of each PUBLISH
request to the value 'application/pidf-partial+xml'. The PUA
constructs the body of the PUBLISH request in accordance with the
PIDF Extension for Partial Presence [2] and this specification.
The PUA MUST publish a full event state and initiallize the version
information to form a basis before publishing one or more partial
event states. The PUA can start a publication context by using the
PUBLISH request as specified in State Publication Extension to SIP
[3] and subsequently change to partial publication. The PUA SHOULD
NOT publish by 'application/pidf+xml', while using
'application/pidf-partial+xml', as this will terminate the partial
publication.
The logic which the PUA uses to construct an event state carried in
the body of the PUBLISH request depends on if a full or partial event
state is being published.
The PUA MUST construct the presence document containing the full
event state according to the following logic:
o The "state" attribute is set to the value "full".
Lonnfors, et al. Expires April 12, 2005 [Page 5]
Internet-Draft Partial Publication October 2004
o The value of the "version" attribute is initialized.
o The full presence information related to the publication context
is included.
o No <removed> elements are included.
The presence document containing the partial event state MUST be
constructed according to the following logic:
o The "state" attribute is set to the value "partial".
o The value of the "version" attribute is incremented by one
compared to the previous publication.
o Only the changed or new tuples compared to the previously
published event states are included. Removed tuples are not
considered as changed tuples in this case. Presence information,
which is located outside the tuple elements, is processed as
specified in the PIDF Extension for Partial Presence [2] and the
Event State Publication Extension to SIP [3], i.e. the PUA
includes all this information in every publication.
o When tuples are removed since the previously published event
states, the value of the "id" attribute of each removed tuple
element is listed in the <removed> element as defined in the PIDF
Extension for Partial Presence [2].
When the PA has discovered an error in the processing of a PUBLISH
request containing a partial publication the PUA receives an abnormal
response. The PUA reacts to the exceptional cases according to the
following logic:
o In case the source of the error was the PUA, the PUA SHOULD either
send a full event state by using either partial publication or the
publication mechanism defined in the Event State Publication
Extension to SIP [3] or terminate the publication context.
o In case the PA did not support the partial publication mechanism
the PUA SHOULD use the publication mechanism as defined in the
Event State Publication Extension to SIP [3].
4.3 Presence Agent Processing PUBLISH Requests
If the PA supports the partial publication mechanism the
Lonnfors, et al. Expires April 12, 2005 [Page 6]
Internet-Draft Partial Publication October 2004
functionality described as follows apply.
The PA looks into the "state" attribute of the presence document for
resolving if the publication contains a full or partial event state.
The PA MUST ensure that it has received a full event state before
receiving any partial event states.
In case of the full event state the PA MUST perform the following
actions:
o The PA first discards any existing information related to the
publication context.
o The PA initializes an internal version counter related to the
particular publication context to the value of "version" attribute
received in the PUBLISH request.
o The PA stores the value of the "id" attribute of each tuple
element together with the content of the tuples received in the
publication. Presence information, which is located outside the
tuple elements, is processed as specified in the Event State
Publication Extension to SIP [3], i.e. the PA stores the
information as received in the publication. The stored presence
information is the PA's local copy of the full presence
information of the publication context.
When the PA receives subsequent publications within the same
publication context and the "state" attribute has the value "partial"
the PA MUST construct the presence information according to the
following logic:
o The PA compares the "version" attribute of the presence element
with the version information stored with the previous publication.
If the version number is incremented by one the PA continues
processing the event state present in the publication.
o The PA stores the new version number as received in the PUBLISH
request.
o The PA compares the "id" attribute of each published tuple element
to the tuple id values within the local copy of the publication
context. If an "id" attribute in the publication matches a stored
tuple id the content of the stored tuple is replaced with the
newly received one. If an "id" attribute in the publication does
not match those stored in the local copy of the publication
context, the content of the tuple and its "id" are stored as new
information in the local copy of the publication context.
Lonnfors, et al. Expires April 12, 2005 [Page 7]
Internet-Draft Partial Publication October 2004
o If the published presence document includes the "removed" element,
the PA removes the tuples which "id" attributes are listed in the
publication from the local copy of the publication context.
o Tuples, which "id" attributes are not included in the published
document, remain unchanged in the local copy of the publication
context.
o All presence information which is located outside the tuple
elements are processed as specified in the PIDF Extension to
Partial Presence [2] and the Event State Publication Extension to
SIP [3], i.e., the PA replaces the existing information with the
information received in the publication.
Processing of exceptional cases:
o In case the PA receives a publication containing a partial event
state with an unexpected "version" attribute's value, the PA
assumes a PUA error has happened. The PA MUST respond with an
error.
o In case the PA receives a partial event state before receiving the
corresponding full event state the PA considers it as a PUA error
and MUST respond with an error.
o In case the PA receives a presence document containing the
<removed> element in a full event state the PA considers it as a
PUA error and SHOULD respond with an error.
o In case the PA receives a presence document containing the same
value of the "id" attribute of a tuple as a value in both a tuple
specific information and the <removed> element the PA considers it
as a PUA error and MUST respond with an error.
o In case the PUA changes the content type used in publications
within an existing publication context the PA MUST discard the
local copy of presence information and version information, and
process the new content as specified for that content type. Note
that in case the PUA decides to start publishing partial event
states again the PUA MUST send a full event state as specified in
this specification first.
o In case the PA does not support the 'application/pidf-partial+xml'
content type the PA SHOULD return an error response '415
Unsupported Media Type'.
OPEN: It is still open which error code should be used for PUA
Lonnfors, et al. Expires April 12, 2005 [Page 8]
Internet-Draft Partial Publication October 2004
errors.
5. Security Considerations
This specification relies on the Event State Publication Extension to
SIP [3] and it does not introduce any new protocol functionality.
Partial publications can reveal information what has been changed
compared to last time when publication was done. This can make it
easier for eavesdroppers to know what kind of changes are happening
in presentity's presence information. However, the same information
can be found if publication is done with the baseline PIDF [4].
Thus, this specification does not introduce any new security
considerations compared to the Event State Publication Extension to
SIP [3].
Event state publication related security considerations are
extensively discussed in the Event State Publication Extension to SIP
[3] and all those identified security considerations apply to this
document as well. Issues described in the Event State Publication
Extension to SIP [3] are briefly reviewed below.
5.1 Confidentiality
Confidentiality considerations identified in the Event State
Publication Extension to SIP [3] apply here without any changes.
5.2 Access Control
Access control considerations identified in the Event State
Publication Extension to SIP [3] apply here without any changes.
5.3 Replay Prevention
Replay prevention considerations identified in the Event State
Publication Extension to SIP [3] apply here without any changes.
5.4 Denial of Service Attacks
Denial of service attacks considerations identified in the Event
State Publication Extension to SIP [3] apply here without any
changes.
6. Acknowledgements
The authors would like to thank Atle Monrad, Christian Schmidt and
George Foti for review comments.
Lonnfors, et al. Expires April 12, 2005 [Page 9]
Internet-Draft Partial Publication October 2004
7. References
7.1 Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Lonnfors, M., Khartabil, H. and E. Leppanen, "Presence
Information Data Format (PIDF) Extension for Partial Presence",
draft-ietf-simple-partial-pidf-format-01 (work in progress),
April 2004.
[3] Niemi, A., "An Event State Publication Extension to the Session
Initiation Protocol (SIP)", draft-ietf-sip-publish-04, May
2004.
[4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and
J. Peterson, "CPIM presence information data format", RFC 3863,
August 2004.
7.2 Informative references
[5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
Authors' Addresses
Mikko Lonnfors
Nokia Research Center
Itamerenkatu 11-13
Helsinki
Finland
Phone: +358 71 8008000
EMail: mikko.lonnfors@nokia.com
Eva Leppanen
Nokia
P.O BOX 785
Tampere
Finland
EMail: eva-maria.leppanen@nokia.com
Lonnfors, et al. Expires April 12, 2005 [Page 10]
Internet-Draft Partial Publication October 2004
Aki Niemi
Nokia Research Center
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Lonnfors, et al. Expires April 12, 2005 [Page 11]
Internet-Draft Partial Publication October 2004
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 (2004). 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.
Lonnfors, et al. Expires April 12, 2005 [Page 12]
