[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-lonnofors-simple-partial-notify) 00 01 02 03 04 05 06 07 08 09 10 RFC 5263

SIMPLE WG                                                    M. Lonnfors
Internet-Draft                                     Nokia Research Center
Expires: July 21, 2004                                  J. Costa-Requena
                                                             E. Leppanen
                                                            H. Khartabil
                                                                   Nokia
                                                        January 21, 2004


              Partial Notification of Presence Information
                  draft-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 on July 21, 2004.

Copyright Notice

   Copyright (C) The Internet Society (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. Limitations can also be caused by
   the interface between the terminal and the network, i.e. radio 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.         Expires July 21, 2004                  [Page 1]

Internet-Draft            Partial notification              January 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Introduction to the partial notification mechanism . . . . . .  4
   3.1 Basic presence server operation  . . . . . . . . . . . . . . .  4
   3.2 Operation with 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.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.1 Confidentiality  . . . . . . . . . . . . . . . . . . . . . . . 12
   6.2 Message Integrity and Authenticity . . . . . . . . . . . . . . 12
   6.3 Outbound Authentication  . . . . . . . . . . . . . . . . . . . 12
   6.4 Replay Prevention  . . . . . . . . . . . . . . . . . . . . . . 12
   6.5 Denial of Service Attacks Against Third Parties  . . . . . . . 12
   6.6 Denial Of Service Attacks Against Servers  . . . . . . . . . . 13
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
       Normative references . . . . . . . . . . . . . . . . . . . . . 13
       Informative references . . . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 16

























Lonnfors, et al.         Expires July 21, 2004                  [Page 2]

Internet-Draft            Partial notification              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 of presence information changes. This may end up
   degrading the presence service and causing bad perception at the
   watcher side.

   There are some mechanisms, such as signaling compression [10] and
   content indirection [9] that can be used to help in this problem.
   However these solutions set 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 to problems described above, called
   partial notifications.

   In general, the partial notification approach means that the presence
   server delivers to the watchers only those parts of the presence
   information that have changed compared to the presence information
   sent in the previous notifications. This reduces the amount of data
   that needs be trasported over the network.

   Mechanism utilizes presence event package [4] and partial PIDF MIME
   type [2].

2. 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 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. Introduction to the partial notification mechanism

   This chapter briefly introduces the normal functionality of the
   presence service, and gives an overview of the partial notification
   solution.

3.1 Basic 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 content 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 [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 Operation with partial notification

   The partial notification mechanism enables the watcher to ask and the
   presence server to send only those parts of the presence information
   that have changed since the last notifications was sent.

   When watcher receives a notification where the "state" attribute, as
   defined in [2], is set to "full", this presence document is
   concidered to be local the presence document for the presentity in
   question. Partial notifications (when the "state" attribute as
   defined in [2] is set to "partial") are relative to the full presence
   document. This means that if a partial notification contains new
   tuples (tuples which have new tuple ids compared to the full presence
   document) they are added to the local full presence document. If it
   contains tuples which have exsting tuple ids it means that those
   tuples are updated. If "removed" element contains existing tuple ids
   it means that those tuples are removed. The wathcer updates the local
   copy accordingly. This behavior is described in detail in Section 4.

   In the scope of this document the partial notifications 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 these 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

   The notifier 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 the
   presence 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 decision SHOULD be based on them. Otherwise the
   decision is made according to the local policy of the presence
   server.

4.4 Notifier generating partial notifications

   It is RECOMMENDED that if the watcher indicates support for partial
   notifications, using the Accept-header, that the PS compliant with
   this specification sends partial notifications. If the PS decides to
   send notifications according to this specification, then the notifier



Lonnfors, et al.         Expires July 21, 2004                  [Page 5]

Internet-Draft            Partial notification              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 information MUST be constructed according
      to [4] in such a way that only the changed tuples are delivered.
      New tuples are also added to the presence information, if any.

   o  The "version" and "state" attributes MUST 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.

   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 the tuple 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 partial presence documents MUST always have that data.


4.5 Watcher processing of partial notifications

   If the PS decided to use the partial notifications, then the watcher
   receives 'application/pidf-partial+xml' content type in the NOTIFY
   requests.

   The watcher receives the full presence document in the first
   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.         Expires July 21, 2004                  [Page 6]

Internet-Draft            Partial notification              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, related
      to the particular presentity or subscription, to the value of
      "version" atttribute received in the notification.

   o  The watcher MUST store the values of all tuple ids 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
   value "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  The watcher compares tuple ids to the tuple ids received in the
      previous notifications. If a tuple id in the notification matches
      an existing tuple id, the existing tuple is replaced with the
      newly received in the notification. If the tuple id 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
      which ids are listed are removed from the local storage.

   o  Tuples whose ids are missing in the NOTIFY remain unchanged.

   In case the watcher receives a notification with the "version"
   attribute value higher than the locally stored value by more than
   one, the watcher assumes that one or more NOTIFYs were lost. The
   watcher SHOULD either refresh the subscription within the existing
   dialog in order to receive a full presence document or terminate the
   subscription. If the watcher receives a notification with the "state"
   attribute's value "partial" and the "version" attribute'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., the
   watcher 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. Examples

   The following message flow shows an example applying the partial
   notifications mechanism.

   The watcher 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                 |                         |
            |-------------------------->|                         |
            |                           |                         |
            |                           |   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/TCP watcherhost.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/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 partial
      notifications. (See that the value 'application/pidf-partial+xml'
      in the Content-Type header).

            SIP/2.0 200 OK
            Via: SIP/2.0/TCP watcherhost.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/TCP server.example.com;
              branch=z9hG4bKna998sk
            To: sip:watcher@somewhere.com;tag=xfg9
            From: 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: ..




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:presence xmlns="urn:ietf:params:xml:ns:pidf"
                xmlns:pidf-part="urn:ietf:params:xml:ns:pidf-partial"
                entity="pres:someone@example.com" pidf:part:version="1"
                pidf-part:state="full">

              <tuple id="sg89ae">
                <status><basic>open</basic>
                </status>
                <contact priority="0.8">tel:09012345678
                </contact>
              </tuple>

              <tuple id="cg231jcr">
                <status><basic>open</basic>
                </status>
                <contact priority="1.0">
                      im:pep@example.com</contact>
              </tuple>
              <tuple id="r1230d">
                <status><basic>closed</basic>
                </status>
                <contact priority="0.9">
                      sip:pep@example.com</contact>
              </tuple>
            </presence>

         F4 200 OK watcher-> example.com server

            SIP/2.0 200 OK
            Via: SIP/2.0/TCP server.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
      'application/pidf-partial+xml' formated document including the
      delta from the previous NOTIFY. Note that the tuple which id
      "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/TCP server.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: ...

            New 'application/pidf-partial+xml document containing partial
            presence document:

            <?xml version="1.0" encoding="UTF-8"?>
            <pidf-part:presence xmlns="urn:ietf:params:xml:ns:pidf"
                xmlns:pidf-part="urn:ietf:params:xml:ns:pidf-partial"
               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>

              <tuple id="cg231jcr">
                <status><basic>closed</basic>
                </status>
                <contact priority="1.0">
                      im:pep@examploe.com</contact>
                <notexml:lang="en">This is an update of existing
                tuple sent in previous notification</note>
              </tuple>

              <tuple id="wsqw798jcr">
                <status><basic>open</basic>
                </status>
                <contact priority="0.4">
                      im:mac@hut.com</contact>
                <note xml:lang="en">This is a completely new
                tuple not sent in previous notification</note>
              </tuple>
            </presence>

         F6 200 OK watcher-> example.com server

            SIP/2.0 200 OK



Lonnfors, et al.         Expires July 21, 2004                 [Page 11]

Internet-Draft            Partial notification              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 NOTIFY



6. Security Considerations

   This specification relies on presence event package [4] and it does
   not introduce any new protocol functionality. Partial notifications
   can reveal information what 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 information 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 notification              January 2004


   Denial of Service Attacks Against Third Parties considerations
   identified in [4] apply here without any changes.

6.6 Denial Of Service Attacks Against Servers

   Denial Of Service Attacks Against Servers considerations 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.

   [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, June
        2002.

Informative references

   [8]   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.




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.

   [10]  Price, R., "Signaling Compression (SigComp)", RFC 3320, January
         2003.


Authors' Addresses

   Mikko Lonnfors
   Nokia Research Center
   Itamerenkatu 11-13 00180
   Helsinki
   Finland

   Phone: +358 71 8008000
   EMail: mikko.lonnfors@nokia.com


   Jose 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.         Expires July 21, 2004                 [Page 15]

Internet-Draft            Partial notification              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 (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.         Expires July 21, 2004                 [Page 16]

Internet-Draft            Partial notification              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.         Expires July 21, 2004                 [Page 17]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/