Internet DRAFT - draft-gurbani-spirits-implementation
draft-gurbani-spirits-implementation
INTERNET-DRAFT Vijay K. Gurbani
February 2003 Sudha Gouthama
Expires: August 2003 Byron J. Williams
Lucent Technologies, Inc.
Document: draft-gurbani-spirits-implementation-00.txt
Category: Experimental
Early implementation of the Services in PSTN requesting Internet services
(SPIRITS) protocol
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.
Abstract
This document describes our early implementation of the SPIRITS
protocol. The purpose of the SPIRITS protocol is to support services
that originate in the Public Switched Telephone Network (PSTN) and
necessitate the interactions between the PSTN and the Internet.
1. Introduction
The SPIRITS protocol defines the mechanisms and the semantics to
subscribe to and convey certain PSTN events to interested Internet
hosts for service execution [1]. This Internet-Draft describes our
initial implementation of a SPIRITS framework based on the
architecture and requirements outlined in [2] and [3], respectively.
We have implemented two services based on such an architecture: a
SPIRITS-based presence service which provides a coarse-grained
presence status for a user represented by a device (phone), and a
SPIRITS-based Instant Messaging (IM) service whereby the PSTN sends a
SIP IM to a SPIRITS User Agent (UA). These services, the attendant
architecture and the relevant call flows are described next.
It is expected that the reader is conversant in the SPIRITS and SIP
terminology. For those who are not, [5,6] provide a good reference
for SIP and its event-based mechanism, and [1,2,3] provide a good
draft-gurbani-spirits-implementation-00.txt [Page 1]
Early implementation of the SPIRITS protocol February 2003
reference for SPIRITS.
It is important to point out that the SPIRITS protocol [1] is not a
standard yet, it is still an Internet-Draft. Thus, what is described
in this draft is an early implementation designed to validate the
suitability of the protocol as well as provide some implementation
experience that will be leveraged in further refining the protocol.
2. Services implemented
We implemented two SPIRITS services; the first one is a presence-
based service consisting of a user agent (UA) that subscribes to
those detection points (DP) in the PSTN which constituted a coarse
form of presence -- on-hook, off-hook, and picking the phone up to
make (or receive) a call. When such events occurred, two SIP NOTIFY
requests were send by the PSTN to the SIP UA. The first NOTIFY
request contained the DP that triggered the request, and following it
was a NOTIFY that indicated the change in the presence state for a
user represented by the phone number. Accordingly, the payload type
of the first NOTIFY was "application/spirits-event" and that of the
second NOTIFY was "application/cpim-pidf+xml" [4] with local
extensions to the <status> element to impart the a richer presence-
based component of the service.
The SPIRITS UA is thus able to act as an endpoint which can display
change in presence status for any CPIM-compliant presence system,
including acting as a clients for a SPIRITS-compliant system.
The second service demonstrates the capability of the PSTN to send a
SIP IM to a SPIRITS UA using the SIP MESSAGE extensions [8]. Under
this service scenario, a user in her office may be interested in
knowing who called her home while she was at work. Thus, she would
like to get real-time notifications of calls terminating to her home
line. Accordingly, she subscribes to the DP that gets triggered on
an incoming call. When the DP triggers, the PSTN sends out a SIP
NOTIFY intimating her of that event, and following the NOTIFY is a
SIP MESSAGE request, the body of which contains the date and time the
PSTN received the call, and if available, the callers phone number.
Our initial thrust in service implementation has been the wireline
aspects of the PSTN since these are well formalized by the SPIRITS
protocol I-D. SPIRITS supports the wireless services as well, and the
next sample set of services will be drawn from that domain.
3. Software needed
In order to realize SPIRITS services, we had to write specialized
SPIRITS UAs. These UAs, in addition to being conversant with the
standard SIP extensions for presence [7] and instant messaging [8],
also had to be knowledgeable about SPIRITS. To that extent, they
needed the capability to subscribe to the SPIRITS events and receive
notifications for them and execute the appropriate service-specific
behavior when a notification for these events arrived.
draft-gurbani-spirits-implementation-00.txt [Page 2]
Early implementation of the SPIRITS protocol February 2003
We wrote two specialized SPIRITS UAs. The first UA, corresponding to
the first service, is a presence-based UA that subscribed to the
presence- related DPs in the PSTN. It also accepts NOTIFYs
containing the SPIRITS payload and NOTIFY requests containing a CPIM
document as a payload [4]. We implemented a local namespace to
further quantify the <status> element of the CPIM document.
In order to realize a SPIRITS framework, a Service Control Function
(SCF) associated with a Service Switching Point (SSP) is required
(see Figure 1: SPIRITS Architecture in [2]). We had a specialized
load on a SSP which sent selected events to another piece of software
we authored. This software was the embodiment of a SCF with a co-
located SPIRITS client (as depicted in Figure 1 of [2]). The SPIRITS
client accepted SIP SUBSCRIBE requests from Internet hosts and
maintained a subscription database in the SCF. When the SCF got
notified of an event by the SSP, the subscription database was
checked to see if an Internet host had subscribed to such an event.
If so, a SIP NOTIFY was sent, followed by any other service-specific
SIP extension. For example, if the SPIRITS client "knew" that a
SPIRITS UA supported the MESSAGE extension (through the "Allows" SIP
header), it would also send out a SIP MESSAGE request to the client
(thus realizing the IM service). In the absence of any such
indication, a plain NOTIFY would be sent out.
Note that the machinations described above for SSP and SCF
communications are incidental, and in fact, the SPIRITS protocol does
not deal directly with this interface. What is of utmost importance
is the behavior of the SPIRITS UA; more specifically, the behavior of
the SPIRITS client (in the PSTN domain) and that of the SPIRITS
server (in the Internet domain). The SPIRITS server (or subscriber)
simply sent out a SIP SUBSCRIBE with the Event token and payload as
specified in [1] and the SPIRITS client (or notifier) sent out a SIP
NOTIFY with the payload and behavior as specified in [1]. The
SPIRITS WG is chartered to specify the syntax and semantics of
communication between the SPIRITS client and the SPIRITS server.
What the SPIRITS server does on receiving a SIP NOTIFY is beyond the
need for standardization; it depends on the creativity that leads to
novel services. Likewise, what the SPIRITS client does on receiving a
SIP SUBSCRIBE depends on the service provider and the representation
of their network.
4. Detailed call flows
We now present the detailed call flows for the two services. The
call flows are presented as vertical time-line diagrams, with the
messages being exchanged between the entities represented as
horizontal lines. Each such line has a corresponding number (Fn) and
the contents of that message are described in detail after the call
flow.
For brevity, the messages are directly exchanged between the SPIRITS
server (subscriber) and the SPIRITS client (notifier).
Intermediaries like the SPIRITS gateway or proxies are not
represented in the call flows. Also, we have chosen not to show the
draft-gurbani-spirits-implementation-00.txt [Page 3]
Early implementation of the SPIRITS protocol February 2003
contents of the 200 OK responses.
4.1 Presence
SPIRITS server SPIRITS client
(subscriber) (nofitier)
192.168.1.1 192.168.1.2
|F1 (SUBS) |
+---------------------------->|
| (200 OK SUBS)| Update PSTN elements
|<----------------------------+
| F2 (NOT) |
|<----------------------------+ Accept the subscription;
|(200 OK NOT) | send base notification
+---------------------------->|
| F3 (NOT) |
|<----------------------------+ Send base PIDF document
|(200 OK NOT) |
+---------------------------->|
| |
= =
| |
| | Event of interest occurs
| F4 (NOT) | Send NOTIFY containing DP
|<----------------------------+
|(200 OK NOT) |
+---------------------------->|
| F5 (NOT) |
|<----------------------------+ Send delta PIDF document
|(200 OK NOT) |
+---------------------------->|
| |
\/ \/
F1
SUBSCRIBE sip:192.168.1.2:9001 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.1;branch=z9hG4bK1.0239881922202132
To: <sip:5552207722@192.168.1.2>
From: <sip:192.168.1.1>;tag=6738688359992660166
CSeq: 472596 SUBSCRIBE
Call-ID: 5945339689215500186@192.168.1.1
Event: spirits-INDPs
Allow: SUBSCRIBE, NOTIFY
Accept: application/spirits-event, application/cpim-pidf+xml
Contact: <sip:192.168.1.1:9090>
Content-Type: application/spirits-event
Content-Length: 462
<?xml version="1.0"?>
<spirits-event>
<DP INDPs="TA" Mode="N">
<CalledPartySubaddress>5552207722</CalledPartySubaddress>
</DP>
<DP INDPs="OAA" Mode="N">
draft-gurbani-spirits-implementation-00.txt [Page 4]
Early implementation of the SPIRITS protocol February 2003
<CallingPartySubaddress>5552207722</CallingPartySubaddress>
</DP>
<DP INDPs="OD" Mode="N">
<CalledPartySubaddress>5552207722</CalledPartySubaddress>
</DP>
<DP INDPs="TD" Mode="N">
<CalledPartySubaddress>5552207722</CalledPartySubaddress>
</DP>
</spirits-event>
This SIP request contains a SPIRITS payload that identifies the DPs
required to detect a coarse-grained form of presence on a device
(phone). The DPs are: Termination Answer (TA), Termination
Disconnect (TD) on the Terminating Basic Call State Model (T_BCSM)
side; Origination Attempt Authorized (OAA), and Origination
Disconnect (OD) on the Originating Basic Call State Model (O_BCSM)
side. Whenever a DP from this set is triggered, the SPIRITS client
(notifier) will send a NOTIFY request to the SPIRITS server
(subscriber).
Of interest is also the MIME types that appear in the "Accept" header
of the SUBSCRIBE. The subscriber UA accepts two MIME types: SPIRITS
payload, and a Presence Information Data Format (PIDF) document.
Thus, when a DP from the above set is triggered, a NOTIFY
corresponding to it will be sent (F3); in addition, another NOTIFY
(F4) will also be sent which includes a PIDF document for presence
purposes.
Note that we could have send two SUBSCRIBE requests; one
corresponding to the SPIRITS DPs (Event: spirits-INDPs) and the
other corresponding to presence-related events (Event: presence)
[7]. Instead, in this example implementation, we have chosen to
denote the presence aspect by including the appropriate Accept
header MIME type (application/cpim-pidf+xml).
F2
NOTIFY sip:192.168.1.1:9090 SIP/2.0
To: <sip:192.168.1.1>;tag=6738688359992660166
From: <sip:5552207722@192.168.1.2>;tag=--*befb@@
Call-ID: 5945339689215500186@192.168.1.1
CSeq: 9323 NOTIFY
Via: SIP/2.0/TCP 192.168.1.2:9001;branch=z9hG4bK3e554116
Contact: <sip:192.168.1.2:9001>
Subscription-State: active
Content-Length: 0
A base NOTIFY is sent to the subscriber accepting the subscription.
F3
NOTIFY sip:192.168.1.1:9090 SIP/2.0
To: <sip:192.168.1.1>;tag=6738688359992660166
From: <sip:5552207722@192.168.1.2>;tag=--*befb@@
Call-ID: 5945339689215500186@192.168.1.1
CSeq: 9324 NOTIFY
draft-gurbani-spirits-implementation-00.txt [Page 5]
Early implementation of the SPIRITS protocol February 2003
Via: SIP/2.0/TCP 192.168.1.2:9001;branch=z9hG4bK3e5540fa
Contact: <sip:192.168.1.2:9001>
Content-Type: application/cpim-pidf+xml
Subscription-State: active
Content-Length: 387
<?xml version="1.0"?>
<presence xlmns="urn:ietf:params:xml:ns:cpim-pidf"
xlmns:local="urn:lucent-com:pidf-category"
entity="pres:5552207722@lucent.com">
<tuple id="910ss1">
<status>
<basic>CLOSED</basic>
<local:category>Unavailable</local:category>
</status>
<contact>sip:5552207722@lucent.com</contact>
</tuple>
</presence>
A NOTIFY containing the PIDF document is then sent to the subscriber.
This NOTIFY request initializes the presence state of the device
(Unavailable). We deliberately chose the initial presence state to
be Unavailable due to security and privacy reasons.
F4
NOTIFY sip:192.168.1.1:9090 SIP/2.0
To: <sip:192.168.1.1>;tag=6738688359992660166
From: <sip:5552207722@192.168.1.2>;tag=--*befb@@
Call-ID: 5945339689215500186@192.168.1.1
CSeq: 9325 NOTIFY
Via: SIP/2.0/TCP 192.168.1.2:9001;branch=z9hG4bK3e4891aab
Contact: <sip:192.168.1.2:9001>
Content-Type: application/spirits-event
Subscription-State: active
Content-Length: 223
<?xml version="1.0"?>
<spirits-event>
<DP INDPs="OAA" Mode="N">
<CallingPartySubaddress>5552207722</CallingPartySubaddress>
<CalledPartySubaddress>5552202040</CalledPartySubaddress>
</DP>
</spirits-event>
This NOTIFY is sent out because an event of interest (OAA) was
detected by the SPIRITS client. As per the SPIRITS protocol, all the
relevant information is collated and send as a SPIRITS payload.
F5
NOTIFY sip:192.168.1.1:9090 SIP/2.0
To: <sip:192.168.1.1>;tag=6738688359992660166
From: <sip:5552207722@192.168.1.2>;tag=--*befb@@
Call-ID: 5945339689215500186@192.168.1.1
CSeq: 9326 NOTIFY
draft-gurbani-spirits-implementation-00.txt [Page 6]
Early implementation of the SPIRITS protocol February 2003
Via: SIP/2.0/TCP 192.168.1.2:9001;branch=z9hG4bKuu71aa26
Contact: <sip:192.168.1.2:9001>
Content-Type: application/cpim-pidf+xml
Subscription-State: active
Content-Length: 416
<?xml version="1.0"?>
<presence xlmns="urn:ietf:params:xml:ns:cpim-pidf"
xlmns:local="urn:lucent-com:pidf-category"
entity="pres:5552207722@lucent.com">
<tuple id="910ss1">
<status>
<basic>CLOSED</basic>
<local:category>
In a call since Thu Feb 20 14:56:54 2003
</local:category>
</status>
<contact>sip:5552207722@lucent.com</contact>
</tuple>
</presence>
This NOTIFY is sent out to watchers to update the presence status of
the device. To that extent, it contains a PIDF document with a local
XML namespace extension (local) which further quantifies the <status>
element. The <local:category> element imparts service provider
specific information which may be displayed in the UI of the SPIRITS
subscriber UA. In this case, we opted to send the presence status of
the user as being busy since a certain time. There is no reason why
additional informational elements such as the caller's phone number
cannot be displayed (in fact, this information is already available
through the NOTIFY in F4; however, we chose not to provide it as a
display element in the UI).
4.2 Instant Message
In this service, a subscriber is interested in monitoring a certain
phone line. For example, this line could represent the subscriber's
home line which she would like to monitor from her work. As soon as
a call arrives at the line, she would like the PSTN to send an IM to
her UA, whereupon she can decide if she would like to return the call
immediately.
The call flow is presented next followed by a message analysis.
SPIRITS server SPIRITS client
(subscriber) (nofitier)
192.168.1.1 192.168.1.2
|F1 (SUBS) |
+---------------------------->|
| (200 OK SUBS)| Update PSTN elements
|<----------------------------+
| F2 (NOT) |
|<----------------------------+ Accept the subscription;
|(200 OK NOT) | send base notification
draft-gurbani-spirits-implementation-00.txt [Page 7]
Early implementation of the SPIRITS protocol February 2003
+---------------------------->|
| |
= =
| |
| | Event of interest occurs
| F3 (NOT) | Send NOTIFY containing DP
|<----------------------------+
|(200 OK NOT) |
+---------------------------->|
| F4 (MSG) |
|<----------------------------+ Send the IM
|(200 OK MSG) |
+---------------------------->|
| |
\/
F1
SUBSCRIBE sip:192.168.1.2:9001 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.1;branch=z9hG4bK0.577242217883416
To: <sip:5552202040@192.168.1.2>
From: <sip:192.168.1.1>;tag=-976415514390200217
CSeq: 65037 SUBSCRIBE
Call-ID: -6299696320093323677@192.168.1.1
Allow: SUBSCRIBE, NOTIFY, MESSAGE
Accept: application/spirits-event, text/plain
Contact: <sip:192.168.1.1:9091>
Content-Type: application/spirits-event
Content-Length: 154
<?xml version="1.0"?>
<spirits-event>
<DP INDPs="TAA" Mode="N">
<CalledPartySubaddress>5552202040</CalledPartySubaddress>
</DP>
</spirits-event>
Here, a Termination Attempt Authorized (TAA) is set on a line. This
DP is encountered and is triggered on the terminating side when an
incoming call arrives for the line.
Note that the "Allow" header contains 3 SIP methods that are
supported by this UA: SUBSCRIBE, NOTIFY, and MESSAGE. Thus, the
SPIRITS client (notifier) knows that the subscriber can accept
MESSAGE requests. This is further re-inforced by the presence of the
MIME type "text/plain" in the "Accept" header.
F2
NOTIFY sip:sip:192.168.1.1:9091 SIP/2.0
To: <sip:192.168.1.1>;tag=-976415514390200217
From: <sip:5552202040@192.168.1.2>;tag=--*bf07@@
Call-ID: -6299696320093323677@192.168.1.1
CSeq: 9321 NOTIFY
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bK9aas6794
Contact: <sip:192.168.1.2:9001>
draft-gurbani-spirits-implementation-00.txt [Page 8]
Early implementation of the SPIRITS protocol February 2003
Subscription-State: active
Content-Length: 0
Subscription is accepted and a base NOTIFY request is sent out.
F3
NOTIFY sip:sip:192.168.1.1:9091 SIP/2.0
To: <sip:192.168.1.1>;tag=-976415514390200217
From: <sip:5552202040@192.168.1.2>;tag=--*bf07@@
Call-ID: -6299696320093323677@192.168.1.1
CSeq: 9322 NOTIFY
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bK3e555644
Contact: <sip:192.168.1.2:9001>
Content-Type: application/spirits-event
Subscription-State: active
Content-Length: 223
<?xml version="1.0"?>
<spirits-event>
<DP INDPs="TAA" Mode="N">
<CallingPartySubaddress>5552202040</CallingPartySubaddress>
<CalledPartySubaddress>5552207722</CalledPartySubaddress>
</DP>
</spirits-event>
When a call arrives for the line, a NOTIFY is sent to the subscriber,
followed immediately by a MESSAGE request.
F4
MESSAGE sip:sip:192.168.1.1:9091 SIP/2.0
To: <sip:192.168.1.1>;tag=-976415514390200217
From: <sip:5552202040@192.168.1.2>;tag=--*bf07@@
Call-ID: -6299696320093323677@192.168.1.1
CSeq: 9322 MESSAGE
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bK89asd678
Contact: <sip:192.168.1.2:9001>
Content-Type: text/plain
Content-Length: 86
From PSTN buddy: Phone call from 5552207722
to 5552202040 at Thu Feb 20 16:27:16 2003
The body of the MESSAGE request contains a plain text formatted
message which is displayed in the appropriate window of the SPIRITS
subscriber's UA.
ACKNOWLEDGMENTS
The authors would like to acknowledge Alec Brusilovsky, Jack Kozik,
William O'Keefe, Doug Varney, and Cindy Yao, for their support and
input to the early implementation.
AUTHORS' ADDRESSES
draft-gurbani-spirits-implementation-00.txt [Page 9]
Early implementation of the SPIRITS protocol February 2003
Vijay K. Gurbani
2000 Lucent Lane
Rm 6G-440
Naperville, IL 60566
USA
Email: vkg@lucent.com
Sudha Gouthama
1960 Lucent Lane
Rm 9B-530
Naperville, IL 60566
Email: gouthama@lucent.com
Byron J. Williams
1960 Lucent Lane
Rm 9B-522
Naperville, IL 60566
Email: bjw@lucent.com
ACRONYMS
CPIM Common Presence and Instant Messaging
DP Detection Point
IM Instant Message
IN Intelligent Network
IP Internet Protocol
MIME Multipurpose Internet Mail Extensions
O_BCSM Originating Basic Call State Model
PIDF Presence Information Data Format
PSTN Public Switched Telephone Network
SCF Service Control Function
SIP Session Initiation Protocol
SPIRITS Services in the PSTN/IN Requesting InTernet Services
SSP Service Switching Point
T_BCSM Terminating Basic Call State Model
Normative references
[1] Vijay K. Gurbani (Ed.), Alec Brusilovsky, Igor Faynberg, Hui-Lan
Lu, Musa Unmehopa, Kumar Vemuri, and Jorge Gato, "The SPIRITS
(Services in PSTN requesting Internet services) Protocol",
Internet-Draft, Work in progress, expires May 2003,
<http://www.ietf.org/internet-drafts/draft-ietf-spirits-
protocol-03.txt>
[2] Lev Slutsman (Ed.), Igor Faynberg, Hui-Lan Lu, and Mark
Weissman, "The SPIRITS Architecture", IETF RFC 3136, June
2001, <http://www.ietf.org/rfc/rfc3136.txt>
[3] Igor Faynberg (Ed.), Jorge Gato, Hui-Lan Lu, and Lev Slutsman,
"Service in the Public Switched Telephone Network/Intelligent
Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol
Requirements", IETF RFC 3298, August 2002,
draft-gurbani-spirits-implementation-00.txt [Page 10]
Early implementation of the SPIRITS protocol February 2003
<http://www.ietf.org/rfc/rfc3298.txt>
[4] Hiroyasu Sugano, Shingo Fujimoto, Graham Klyne, Adrian Bateman,
Wayne Carr, and Jon Peterson, "Common Presence and Instant
Messaging (CPIM) Presence Information Data Format", IETF
Internet-Draft, Work in progress, expires June 2003,
<http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-
pidf-07.txt>
Informative references
[5] Jonathan Rosenberg, Henning Schulzrinne, Gonzalo Camarillo, Alan
Johnston, Jon Peterson, Robert Sparks, Mark Handley, and Eve
Schooler, "The Session Initiation Protocol (SIP)", IETF RFC
3261, June 2002, <http://www.ietf.org/rfc/rfc3261.txt>.
[6] Adam Roach, "Session Initiation Protocol (SIP)-Specific Event
Notification", IETF RFC 3265, June 2002,
<http://www.ietf.org/rfc/rfc3265.txt>
[7] Jonathan Rosenberg, "A Presence Event Package for the Session
Initiation Protocol (SIP)" IETF Internet-Draft, Work in
progress, expires July 2003, <http://www.ietf.org/internet-
drafts/draft-ietf-simple-presence-10.txt>
[8] Ben Campbell (Ed.), Jonathan Rosenberg, Henning Schulzrinne,
Christian Huitema, and David Gurle, "Session Initiation
Protocol (SIP) Extension for Instant Messaging", IETF RFC 3248,
December 2002, <http://www.ietf.org/rfc/rfc3428.txt>
FULL COPYRIGHT STATEMENT
"Copyright (C) The Internet Society (date). 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 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 assigns.
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
draft-gurbani-spirits-implementation-00.txt [Page 11]
Early implementation of the SPIRITS protocol February 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
draft-gurbani-spirits-implementation-00.txt [Page 12]
