view Side-By-Side changes
SIMPLE WG M. Lonnfors Internet-Draft Nokia Research Center Expires:March 19,July 21, 2004 J. Costa-Requena E. Leppanen H. Khartabil NokiaSeptember 19, 2003January 21, 2004 Partial Notification of Presence Informationdraft-ietf-simple-partial-notify-00draft-ietf-simple-partial-notify-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 onMarch 19,July 21, 2004. Copyright Notice Copyright (C) The Internet Society(2003).(2004). All Rights Reserved. Abstract A Presence service can have constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power.Other limitationsLimitations can also be caused by the interface between the terminal and the network, i.e.overradio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and to increase transport efficiency, by introducing a mechanism called partial notification. Lonnfors, et al. ExpiresMarch 19,July 21, 2004 [Page 1] Internet-Draft Partialnotifications September 2003notification January 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Introductionofto the partial notification mechanism . . . . . . 4 3.1NormalBasic presence server operation . . . . . . . . . . . . . . . 4 3.2 Operationof thewith partial notification . . . . . . . . . . . . . 4 4. Client and server operations . . . . . . . . . . . . . . . . . 5 4.1 Content-type for partial notifications . . . . . . . . . . . . 5 4.2 Watcher generating of SUBSCRIBE requests . . . . . . . . . . ..5 4.3 Notifier processing of SUBSCRIBE requests . . . . . . . . . . 5 4.4 Notifier generating partial notifications . . . . . . . . . . 5 4.5 Watcher processing of partial notifications . . . . . . . . . 6 5.IANA ConsiderationsExamples . . . . . . . . . . . . . . . . . . . . . . . . . . . 85.1 URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf-partial'6. Security Considerations . . . . . . . . . . . .8 6. Examples. . . . . . . 12 6.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . .9 7. XML Schema. 12 6.2 Message Integrity and Authenticity . . . . . . . . . . . . . . 12 6.3 Outbound Authentication . . . . . . . . . . .13 8. Security Considerations. . . . . . . . 12 6.4 Replay Prevention . . . . . . . . . . .14 9.. . . . . . . . . . . 12 6.5 Denial of Service Attacks Against Third Parties . . . . . . . 12 6.6 Denial Of Service Attacks Against Servers . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .1413 Normative references . . . . . . . . . . . . . . . . . . . . .1413 Informative references . . . . . . . . . . . . . . . . . . . .1513 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .1514 Intellectual Property and Copyright Statements . . . . . . . .1716 Lonnfors, et al. ExpiresMarch 19,July 21, 2004 [Page 2] Internet-Draft Partialnotifications September 2003notification January 2004 1. Introduction SIP extensions for presence [4] allow users ('watchers') to subscribe to other users' ('presentities') presence information. The presence information is composed of multiple pieces of data that are delivered to the watcher. The size of the presence information document can be large (i.e. the presence document can contain an arbitrary number of elements called presence tuples that convey data). As specified in [3] and , [4] a Presence server (PS) always delivers all presence data that has been authorized for a certain watcher in presence notification. This is done regardless what presence data has changed compared to last notification. It may not be reasonable to send the complete presence information over low bandwidth and high latency links when only part ofthatpresence information changes. This may end up degrading the presence service and causing bad perception at the watcher side.Presence based applications in wireless terminals have certain limitations because it is envisioned that the presence service may demand high bandwidth. Requirements for wireless environments can be found in [12].There are some mechanisms, such as signaling compression[14][10] and content indirection[11], [10][9] thatmightcan be used to help in this problem.However, none of the existingHowever these solutionsare optimal because theyset additional requirements on basic network functionalities such as security. Some of the existing solutions enforce certain requirements on the network and terminals for supporting compression mechanism, while other solutions require having a specific server to store the requested presence information until the terminal fetches it using another protocol (HTTP) and therefore increases possible security concerns. This draft presents a solution tothese problems,problems described above, calledPartial Notifications. Requirements for this mechanism are presented in [3]. Other set of requirements can be found from [12]. The idea is already identified by the SIP Extensions for Presence document [4] as a potential solution.partial notifications. In general, the partial notification approach means that thePresence Server (PS)presence server delivers to the watchers only those parts of the presence information that have changed compared to the presence information sent in the previousnotification. Notenotifications. This reduces the amount of data that needs be trasported over the network. Mechanism utilizes presence event package [4] and partialnotification is not IMPP compliant. This document introduces a new MIME-Type 'application/pidf- partial+xml'.PIDF MIME type [2]. 2. Conventions In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",Lonnfors, et al. Expires March 19, 2004 [Page 3] Internet-Draft Partial notifications September 2003and "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 RFC2778 [3], presence event package [4], and partial PIDF definition [2]. Lonnfors, et al. Expires July 21, 2004 [Page 3] Internet-Draft Partial notification January 2004 3. Introductionofto the partial notification mechanism This chapter briefly introduces thecurrentnormal functionality of the presence service, and gives an overview of the partial notificationsolution and new items needed to implement it.solution. 3.1NormalBasic presence server operation The presence service normally operates so that the watcher sends the SIP SUBSCRIBE request targeted to the presentity. The request is routed up to the presence server responsible for terminating the request. The SUBSCRIBE request MAY include an Accept header field for indicating the supported content types [5]. The PS receives the SUBSCRIBE request and if there is no Accept header indicating the supported content types or Accept header contains the default PIDF contenttype ,type, the PS will generate the presence notification using the default PIDF format [6]. The PIDF may contain one or multiple tuples and presence document level information. The tuples include a set of elements defined in the presence model[2][3] for representing the presence information. The presence information is sent to the watcher in the body of the NOTIFY request according to [7]. By default, the presence information contains the full state corresponding to the presence status of the presentity, as determinated by the PS local policy and authorization rules. 3.2 Operationof thewith partial notification Themechanism for implementing thepartial notificationconsistsmechanism enables the watcher to ask and the presence server to send only those parts ofdefiningthe presence information that have changed since the last notifications was sent. When watcher receives anew content type. The new content type is namednotification where the "state" attribute, as'application/pidf-partial+xml'. Itdefined in [2], issimilar to PIDF [6] except that it adds new XML attributesset to<presence> element in order"full", this presence document is concidered toenablebe local thepartial notifications. The new XML attributes are "version" and "state". Content type also introduces new XML element called "removed". The "version" attribute is a sequence number that is progressively incrementedpresence document foreach watcher when notification is sent. The "state" attribute indicatesthenature ofpresentity in question. Partial notifications (when thepresence information included"state" attribute as defined in [2] is set to "partial") are relative to thenotified document, whether it containsfullorpresence document. This means that if a partialstate correspondingnotification contains new tuples (tuples which have new tuple ids compared to thecases when thefull presenceinformation or only changed parts ofdocument) they are added to the local full presenceinformationdocument. If it contains tuples which have exsting tuple ids it means that those tuples aredelivered.updated. If "removed" element contains existing tuple ids it means that those tuples are removed. Theuse of these attributes is similar towathcer updates thewatcher information template package [9]. Lonnfors, et al. Expires March 19, 2004 [Page 4] Internet-Draft Partial notifications September 2003local copy accordingly. This behavior is described in detail in Section 4. In the scope of this document the partialupdatesnotifications apply only to the <tuple> level XML elements and everything what is contained Lonnfors, et al. Expires July 21, 2004 [Page 4] Internet-Draft Partial notification January 2004 inside theseelements, in other words:elements i.e. tuples are considered to be atomic data elements. This means that when an update is send to a tuple it is assumed that the whole tuple is completely replaced by the new one. All the data which is located outside the <tuple> elements must be processed as specified in [4]. Usually this means that all those XML elements (for example the <note> element) must be included in every notification. 4. Client and server operations This document assumes that unless otherwise specified in this document the normal subscriber and notifier behavior is applied as defined in [4]. The watcher has the same behavior as a subscriber. 4.1 Content-type for partial notifications The entities supporting the partial notification extension described in this document MUST support the 'application/pidf-partial+xml' content-type. 4.2 Watcher generating of SUBSCRIBE requests The SUBSCRIBE request can be used to negotiate the preferred content type to be used in the notifications. The Accept header is used for this purpose as specified in [5]. When a watcher wants to allow PS to send partial notifications it MUST include the Accept header value 'application/pidf-partial+xml' in the SUBSCRIBE request. The qvalue parameter of the Accept header can be used to indicate the most preferred content type to be used. 4.3 Notifier processing of SUBSCRIBE requests ThePresence Servernotifier receives the subscriptions from the watchers and generates the notifications according to [4]. If the watcher has indicated the supported content types in the Accept header thePresence Serverpresence server compares the content types included in the Accept header with the supported ones, and decides which one to use. If the watcher has used the qvalue parameter of the Accept header for the content types the decisionshouldSHOULD be based on them. Otherwise the decision is made according to the local policy of the presence server. 4.4 Notifier generating partial notificationsIf the content type negotiation betweenIt is RECOMMENDED that if the watcherand the PS resulted in the agreement to useindicates support for partial notifications,thenusing the Accept-header, that the PSMUST usecompliant with this specification sends partial notifications. If the'application/pidf-partial+xml' content type inPS decides to send notifications according to this specification, then the notifier Lonnfors, et al. ExpiresMarch 19,July 21, 2004 [Page 5] Internet-Draft Partialnotifications September 2003notification January 2004 MUST use the 'application/pidf-partial+xml' content type in the NOTIFY requests. The PS MUST deliver the full state of the presence information according to [4] in the first notification. In this case, the "state" attribute of the <presence> element in the presence document MUST be set to the value "full". The "version" attribute MUST also be present and it MUST be initialized to value zero. When the PS generates subsequent notifications, the presence document includes only the tuples that have changed compared to the previous notification. It is up to the local policy to determine what is considered as a change to the previous state. The "state" attribute's value MUST be set to "partial". The PS constructs the partial presence document according to the following logic: o The delivered presence informationisMUST be constructed according to [4] in such a way that only the changed tuples are delivered. New tuples are alsobeadded to the presence information, if any. o The "version" and "state" attributesare alsoMUST be included in the presence document. The version number is incremented by one compared to the earlier delivered presence document to the watcher associated with a certain subscription.The version number should follow the COUNTER32 format so that after reaching the maximum value it starts from zero [15].o When there are changes (e.g. in the authorization) which lead to removal of tuples from the previously delivered presence information the PS lists theIDstuple ids of the removed tuples in the "removed" element. o All the presence information outside the <tuple> elements MUST be included in each notification, i.e., all the notifications which convey partialnotificationspresence documents MUST always have that data. 4.5 Watcher processing of partial notifications If thenegotiation between the watcher and thePSresulted in the agreementdecided to use the partial notifications, then the watcher receives 'application/pidf-partial+xml' content type in the NOTIFY requests. The watcher receives the fullstate of thepresenceinformation according to [4]document in the firstnotification using the partial notifications.notification. In this case, the "state" element of the presence document has the value "full". When the watcher receives the full presence document it MUST perform the following actions: Lonnfors, et al. ExpiresMarch 19,July 21, 2004 [Page 6] Internet-Draft Partialnotifications September 2003 statenotificationit MUST perform the following actions:January 2004 o The watcher MUST discard all previously received presence information from that particular presentity in the context of current dialog. o The watcher MUST initialize an internal version counter, relatedthatto the particular presentity or subscription, to the"version"value of "version" atttribute received in the notification. o The watcher MUST store the values of all tupleIDsids together with the content received in the notification. This is the watcher's local copy of the full presence document. When the watcher receives subsequent notifications and the PS has not changed the used content type, and the "state" element includes the valueof"partial" the watcher MUST construct the presence information according to the following logic: o The "version" attribute of the <presence> element is compared with the version information in the previously received presence document. If the version number is incremented by one, the watcher continues handling the content present in the notification. o TheWatcherwatcher compares tupleIDsids to the tupleIDsids received in the previous notifications. If a tupleIDid in the notification matches an existing tupleID,id, the existing tuple is replaced with the newly received in the notification. If the tupleIDid does not match to those received in the earlier notifications, it is stored as a new tuple. o If the presence document includes the "removed" element the tuples whichIDsids are listed are removed from the local storage. o Tuples whoseIDsids are missing in the NOTIFY remain unchanged. In case the watcher receives apartialnotification with the "version" attribute value higher than the locally stored value by more than one, the watcher assumes that one or moreNOTIFYNOTIFYs werelost andlost. The watcher SHOULD either refresh the subscription within the existing dialog in order to receive acomplete update (full state) of thefull presenceinformationdocument or terminate the subscription. If the watcher receives a notification with the "state"attributeattribute's value "partial" and the "version"attributeattribute's value is equal or smaller than the one in the previous notification, it is considered a PS failure and the watcher SHOULD either refresh or terminate the subscription. All information received in the notification which is located outside the <tuple> element must be processed as specified in [4] i.e., theLonnfors, et al. Expires March 19, 2004 [Page 7] Internet-Draft Partial notifications September 2003watcher must replace the existing data with data received in the Lonnfors, et al. Expires July 21, 2004 [Page 7] Internet-Draft Partial notification January 2004 latest notification. In case the PS changes the content type used in notifications within the existing dialog the watcher must discard all previously received presence information from that particular presentity and process the new content as specified for that content type. 5.IANA Considerations This memo calls for IANA to register a new XML namespace URN per [8]. A new content type 'application/pidf-partial+xml' is defined to represent an XML MIME for the partial presence information content. This specification follows the guidelines of RFC3023 [13]. 5.1 URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf-partial' URI: uurn:ietf:params:xml:ns:pidf-partial Description: This is the XML namespace for XML elements defined by [[[RFCXXXX]]] to describe the 'application/pidf-partial+xml' content type for partial notifications. Registrant Contact: IETF, SIMPLE working group, <simple@ietf.org> Mikko Lonnfors, <mikko.lonnfors@nokia.com> XML: Lonnfors, et al. Expires March 19, 2004 [Page 8] Internet-Draft Partial notifications September 2003 BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>PIDF extension for partial notifications</title> </head> <body> <h1>Namespace for PIDF extension for partial notifications</h1> <h2>application/pidf-partial+xml</h2> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> </body> </html> END 6.Examples The following message flowshowshows an example applying the partial notifications mechanism. Thedocument of the 'application/ pidf-partial+xml' format mentioned in the message details is constructed according to the XML schema described in the chapter Section 7. Thewatcher sends a SUBSCRIBE request including the default presence format (PIDF) and the content type for the partial notification in the Accept header field. The watcher uses the qvalue parameter to set the preference for receiving partial notifications. The PS accepts the subscription and based on the qvalue information selects to send partial notifications in NOTIFY requests. The first NOTIFY request includes the full state of presence information represented in the 'application/pidf-partial+xml' content type. The following notifications only include the delta of the presence information from the previous NOTIFY request. Watcher Presence Server PUA | F1 SUBSCRIBE | | |-------------------------->| | | F2 200 OK | | |<--------------------------| | | F3 NOTIFY | | |<--------------------------| | | F4 200 OK | | |-------------------------->| | | | |Lonnfors, et al. Expires March 19, 2004 [Page 9] Internet-Draft Partial notifications September 2003| | Update presence | | |<----------------------- | | | | | F5 NOTIFY | | |<--------------------------| | | F6 200 OK | | |-------------------------->| | Message Details F1 SUBSCRIBE watcher->example.com server SUBSCRIBE sip:resource@example.com SIP/2.0 Via: SIP/2.0/TCPwatcherhost.example.com;branch=z9hG4bKnashds7watcherhost.example.com; Lonnfors, et al. Expires July 21, 2004 [Page 8] Internet-Draft Partial notification January 2004 branch=z9hG4bKnashds7 To: sip:resource@example.com From: sip:watcher@somewhere.com ;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 17766 SUBSCRIBE Max-Forwards: 70 Event: presence Accept:application/cpim-pidf+xml;q=0.3,application/pidf+xml;q=0.3, application/pidf-partial+xml;q=1 Contact: user@watcherhost.example.com Expires: 600 F2 200 OK example.com server->watcher The Presence Server accepts the subscription and based on the qvalue information in the Accept header uses the partialnotitifcations.notifications. (See that the value 'application/pidf-partial+xml' in the Content-Type header). SIP/2.0 200 OK Via: SIP/2.0/TCPwatcherhost.example.com;branch=z9hG4bKnashds7watcherhost.example.com; branch=z9hG4bKnashds7 ;received=192.0.2.1 To: sip:resource@example.com;tag=ffd2 From: sip:watcher@somewhere.com;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 17766 SUBSCRIBE Event: presence Expires: 600 Contact: sip:server.example.com F3 NOTIFY example.com server-> watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/TCPserver.example.com;branch=z9hG4bKna998skserver.example.com; branch=z9hG4bKna998sk To: sip:watcher@somewhere.com;tag=xfg9Lonnfors, et al. Expires March 19, 2004 [Page 10] Internet-Draft Partial notifications September 2003From: sip:resource@example.com;tag=ffd2 Call-ID: 2010@watcherhost.example.com Event: presence Subscription-State: active;expires=599 Max-Forwards: 70 CSeq: 8775 NOTIFY Contact: sip:server.example.com Content-Type: application/pidf-partial+xml Content-Length: ..PIDF-PARTIAL+XML Document with FULL STATE information:Lonnfors, et al. Expires July 21, 2004 [Page 9] Internet-Draft Partial notification January 2004 'application/pidf-partial+xml' document containing full presence document: <?xml version="1.0" encoding="UTF-8"?> <pidf-part:presencexmlns="urn:ietf:params:xml:ns:cpim-pidf"xmlns="urn:ietf:params:xml:ns:pidf" xmlns:pidf-part="urn:ietf:params:xml:ns:pidf-partial"xmlns:impp="urn:ietf:params:xml:ns:cpim-pidf"entity="pres:someone@example.com" pidf:part:version="1" pidf-part:state="full"><impp:tuple<tuple id="sg89ae"><impp:status><impp:basic>open</impp:basic></impp:status> <impp:contact priority="0.8">tel:09012345678</impp:contact> </impp:tuple> <impp:tuple<status><basic>open</basic> </status> <contact priority="0.8">tel:09012345678 </contact> </tuple> <tuple id="cg231jcr"><impp:status><impp:basic>open</impp:basic></impp:status> <impp:contact<status><basic>open</basic> </status> <contact priority="1.0">im:pep@example.com</impp:contact> </impp:tuple> <impp:tupleim:pep@example.com</contact> </tuple> <tuple id="r1230d"><impp:status><impp:basic>closed</impp:basic></impp:status> <impp:contact<status><basic>closed</basic> </status> <contact priority="0.9">sip:pep@example.com</impp:contact> </impp:tuple> </impp:presence>sip:pep@example.com</contact> </tuple> </presence> F4 200 OK watcher-> example.com server SIP/2.0 200 OK Via: SIP/2.0/TCPserver.example.com;branch=z9hG4bKna998skserver.example.com; branch=z9hG4bKna998sk ;received=192.0.2.2 To: sip:watcher@somewhere.com;tag=xfg9 From: sip:resource@example.com;tag=ffd2 Call-ID: 2010@watcherhost.example.com CSeq: 8775 NOTIFY F5 NOTIFY example.com server -> watcher It is the local policy issue to construct the'PIDF-partial+xml' Lonnfors, et al. Expires March 19, 2004 [Page 11] Internet-Draft Partial notifications September 2003'application/pidf-partial+xml' formated document including the delta from the previous NOTIFY. Note that the tuple which idwas"r1230d" was deleted. Lonnfors, et al. Expires July 21, 2004 [Page 10] Internet-Draft Partial notification January 2004 NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/TCPserver.example.com;branch=z9hG4bKna998slserver.example.com; branch=z9hG4bKna998sl To: sip:watcher@somewhere.com;tag=xfg9 From: sip:resource@example.com;tag=ffd2 Call-ID: 2010@watcherhost.example.com CSeq: 8776 NOTIFY Event: presence Subscription-State: active;expires=543 Max-Forwards: 70 Contact: sip:server.example.com Content-Type: application/pidf-partial+xml Content-Length: ... NewPIDF-PARTIAL+XML Document with PARTIAL STATE information:'application/pidf-partial+xml document containing partial presence document: <?xml version="1.0" encoding="UTF-8"?> <pidf-part:presencexmlns="urn:ietf:params:xml:ns:cpim-pidf"xmlns="urn:ietf:params:xml:ns:pidf" xmlns:pidf-part="urn:ietf:params:xml:ns:pidf-partial"xmlns:impp="urn:ietf:params:xml:ns:cpim-pidf"entity="pres:someone@example.com" pidf-part:version="2" pidf-part:state="partial"><pidf-part:removed><pidf-part:t_id>r1230d</pidf-part:t_id></pidf-part:removed> <impp:tuple<pidf-part:removed><pidf-part:t_id>r1230d</pidf-part:t_id> </pidf-part:removed> <tuple id="cg231jcr"><impp:status><impp:basic>closed</impp:basic></impp:status> <impp:contact<status><basic>closed</basic> </status> <contact priority="1.0">im:pep@examploe.com</impp:contact> <impp:notexml:lang="en">Thisim:pep@examploe.com</contact> <notexml:lang="en">This is an update of existing tuple sent in previous notification</note></impp:tuple> <impp:tuple</tuple> <tuple id="wsqw798jcr"><impp:status><impp:basic>open</impp:basic></impp:status> <impp:contact<status><basic>open</basic> </status> <contact priority="0.4">im:mac@hut.com</impp:contact> <impp:noteim:mac@hut.com</contact> <note xml:lang="en">This is a completely new tuple not sent in previous notification</note></impp:tuple> </impp:presence></tuple> </presence> F6 200 OK watcher-> example.com server SIP/2.0 200 OKVia: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl ;received=192.0.2.2 To: sip:watcher@somewhere.com;tag=xfg9Lonnfors, et al. ExpiresMarch 19,July 21, 2004 [Page12]11] Internet-Draft Partialnotifications September 2003notification January 2004 Via: SIP/2.0/TCP server.example.com; branch=z9hG4bKna998sl ;received=192.0.2.2 To: sip:watcher@somewhere.com;tag=xfg9 From: sip:resource@example.com;tag=ffd2 Call-ID: 2010@watcherhost.example.com CSeq: 8776 NOTIFY7. XML Schema The XML schema for the 'pidf-partial+xml' data format. <?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf-partial" xmlns:tns="urn:ietf:params:xml:ns:pidf-partial" xmlns:pidf="urn:ietf:params:xml:ns:cpim-pidf" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <!--6. Security Considerations Thisimport brings in the XML language attribute xml:lang--> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/> <xs:import namespace="urn:ietf:params:xml:ns:cpim-pidf"/> <xs:element name="presence" type="tns:partial-presence"/> <xs:complexType name="partial-presence"> <xs:complexContent> <xs:extensionBase=pidf:presence> <xs:sequence> <xs:element name="removed" type="tns:removed_tuple" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:attribute name="entity" type="xs:anyURI" use="required"/> <xs:attribute name="version" type="xs:nonNegativeInteger" use="required"/> <xs:attribute name="state" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="full"/> <xs:enumeration value="partial"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extensionBase> </xs:complexContent> </complexType> <xs:complexType name="removed_tuple"> Lonnfors, et al. Expires March 19, 2004 [Page 13] Internet-Draftspecification relies on presence event package [4] and it does not introduce any new protocol functionality. Partial notificationsSeptember 2003 <xs:sequence> <xs:element name="t_id" type="xs:ID" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:schema> 8. Security Considerations Presencecan reveal informationmay contain highly sensitivewhat has changed compared to last time when notificatiuon was sent. This can make it easier for evesdropper to know what kind of changes are happening in presentity's presence information. However, same informationabout the presentities.can be found if presence event package is used with baseline PIDF [6]. Thus, this specification does not introduce any new security conciderations compared to presence event package [4]. Presence related security considerations are extensively discussed in [4] and all those identified security consideration apply to this document as well. Issues described in [4] are briefly reviewed below. 6.1 Confidentiality Confidentiality considerations identified in [4] apply here without any changes. 6.2 Message Integrity and Authenticity Message Integrity and Authenticity identified in [4] apply here without any changes. 6.3 Outbound Authentication Outbound Authentication considerations identified in [4] apply here without any changes. 6.4 Replay Prevention Replay Prevention considerations identified in [4] apply here without any changes. 6.5 Denial of Service Attacks Against Third Parties Lonnfors, et al. Expires July 21, 2004 [Page 12] Internet-Draft Partial notificationmechanism does not add anything new which (in termJanuary 2004 Denial ofthe security) is not already specifiedService Attacks Against Third Parties considerations identified in [4]and [5]. Thus no new securityapply here without any changes. 6.6 Denial Of Service Attacks Against Servers Denial Of Service Attacks Against Servers considerationsare introduced here. 9.identified in [4] apply here without any changes. 7. Acknowledgements The authors would like to thank Jyrki Aarnos, Jonathan Rosenberg, Dean Willis, Kriztian Kiss, Juha Kalliokulju and Tim Moran for their valuable comments. 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-00 (work in progress), January 2004. [3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.[3] Lonnfors, M., Leppanen, E., Requena, J. and H. Khartabil, "Requirements for Efficient Delivery of Presence Information", draft-ietf-simple-presinfo-deliv-reg-00 (work in progress), April 2003.[4] Rosenberg, J., "SIP Extensions for Presence", draft-ietf-simple-presence-10 (work in progress), January 2003. [5] 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. [6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and J. Peterson, "CPIM presence information data format", draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. [7] Roach, A., "SIP-Specific Event Notification", RFC 3265, JuneLonnfors, et al. Expires March 19, 2004 [Page 14] Internet-Draft Partial notifications September 20032002. Informative references [8]Mealling, M., "The IETF XML Registry", draft-mealling-iana-xmlns-registry-05 (work in progress), June 2002. [9]Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-winfo-package-05 (work in progress), January 2003.[10] Khartabil, H., "Congestion safety and Content Indirection", draft-khartabil-sip-congestionsafe-ci-02 (work in progress), March 2003. [11]Lonnfors, et al. Expires July 21, 2004 [Page 13] Internet-Draft Partial notification January 2004 [9] Olson, S., "Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", draft-ietf-sip-content-indirect-mech-03 (work in progress), February 2003.[12] Kiss, K., "Requirements for Presence Service based on 3GPP specifications and wireless environment characheristics", draft-kiss-simple-presence-wireless-reqs-01 (work in progress), February 2003. [13] Murata, M., "XML media types", RFC 3023, January 2001. [14][10] Price, R., "Signaling Compression (SigComp)", RFC 3320, January 2003.[15] McCloghrie, K., "Structure of Management Information Version 2 (SMIv2)", RFC 2578, April 1999.Authors' Addresses Mikko Lonnfors Nokia Research Center Itamerenkatu 11-13 00180 Helsinki Finland Phone: +35850 483640271 8008000 EMail: mikko.lonnfors@nokia.comLonnfors, et al. Expires March 19, 2004 [Page 15] Internet-Draft Partial notifications September 2003Jose Costa-Requena Nokia Valimotie 9 00380 Helsinki Finland Phone: +358 71 8008000 EMail: jose.costa-requena@nokia.com Eva Leppanen Nokia P.O BOX 785 Tampere Finland Phone: +358 7180 77066 EMail: eva-maria.leppanen@nokia.com Lonnfors, et al. Expires July 21, 2004 [Page 14] Internet-Draft Partial notification January 2004 Hisham Khartabil Nokia P.O. Box 321 Helsinki Finland Phone: +358 7180 76161 EMail: hisham.khartabil@nokia.com Lonnfors, et al. ExpiresMarch 19,July 21, 2004 [Page16]15] Internet-Draft Partialnotifications September 2003notification January 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society(2003).(2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Lonnfors, et al. ExpiresMarch 19,July 21, 2004 [Page17]16] Internet-Draft Partialnotifications September 2003notification January 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Lonnfors, et al. ExpiresMarch 19,July 21, 2004 [Page18]17] ----