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]
