INTERNET-DRAFT G. Mohr, Activerse
Expires: February 7, 1999 S. Aggarwal, Microsoft
M. Day, Lotus
A. Houri, Ubique
Y. Kohda, Fujitsu
D. Marvit, Fujitsu
7 August 1998
PIP-DEMO: An Interoperable Presence Information Protocol
draft-mohr-pip-pipdemo-00.txt
1. Status of this Memo
This document is an Internet-Draft. 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."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments
to the PIP discussion group at pip@iastate.edu. Discussions of
the group are archived at http://lists.fsck.com/cgi-bin/wilma/pip.
2. Abstract
PIP/0.2 is a demonstration protocol designed as a testbed
for certain ideas about meeting 'Presence Information Protocol'
requirements in a straightforward, interoperable fashion.
Drawing from earlier proposals in this area, PIP/0.2 aims to:
1) Enable basic 'presence information' sharing
2) Enable simple text messaging; and
3) Remain easy to understand and implement
PIP/0.2 specifically makes NO attempt to be:
1) Secure
2) Scalable/efficient; or
3) Rigorously specified
3. Contents
1. Status of this Memo
2. Abstract
3. Contents
4. Introduction
5. Naming
6. Message format
7. Transport
8. Character Encoding
9. Methods
9.1 SUBSCRIBE
9.2 UNSUBSCRIBE
9.3 CHANGE
9.4 NOTIFY
9.5 FETCH
10. Response Codes
11. Headers
11.1 Adopted from HTTP/1.1 Without Change
11.2 Duration
11.3 Renew-Duration
11.4 From
11.5 Origin
11.6 Sendback
11.7 Subscription-ID
11.8 Notify-class
11.9 Regarding
12. Leases
13. Subscriptions
14. Redirections
15. Domain Conventions
15.1 Presence Information
15.2 Messaging
15.3 Establishing Redirection (Optional)
16. Proxying
17. Security
18. Examples
18.1 Establishing availability
18.2 Subscribing to others
18.3 Instant messaging
18.4 Publishing from elsewhere
19. References
20. Author Addresses
4. Introduction
At any moment, millions of people worldwide are interacting with
the Internet. But can they interact with each other?
Often they cannot, because the Internet lacks a standard, widely
deployed mechanism for people to advertise dynamic information
about their online status, and exchange simple, endpoint-to-
endpoint messages.
A burgeoning category of applications known as "buddy lists",
"people browsers", "pagers", "messengers", or "colleague awareness
tools" have sought to provide these capabilities, but so far such
applications have used proprietary schemes: undocumented
protocols, closed namespaces, and centrally-administered service
centers.
A number of companies and individuals have begun an effort to
adopt an open, interoperable standard for basic presence- and
messaging- functionality, under the name "PIP", for "Presence
Information Protocol(s)". Efforts are underway to formally
enumerate the requirements such a standard should meet,
investigate the applicability of existing technologies and
standards, and initiate an IETF working group focused on this
area.
PIP/0.2 is a demonstration protocol designed as a testbed
for certain ideas about meeting "Presence Information Protocol"
requirements in a straightforward, interoperable fashion.
Drawing from earlier proposals in this area, PIP/0.2 aims to:
1) Enable basic "presence information" sharing
2) Enable simple text messaging; and
3) Remain easy to understand and implement
PIP/0.2 specifically makes NO attempt to be:
1) Secure
2) Scalable/efficient; or
3) Rigorously specified
The authors intend to demonstrate test software, independently
developed by their respective companies, which interoperates
based on this protocol, but such PIP/0.2 software should not be
considered indicative of any actual product offerings.
PIP/0.2 aims to demonstrate end-user to end-user
interoperability, without mandating a particular split of
responsibility between client and server. In particular, it
should be acceptable for a client to subscribe directly to
an alien server, use a native server as a proxy to an alien
server, or any mixture of the two. This flexibility is
possible because the alien server doesn't really care
whether a subscription is "really" from a client, it just
manages the subscription and delivers the notifications
regardless.
At the time of this writing, individual implementations of this
protocol are underway but full functionality and interoperability
have not yet been confirmed by intervendor testing. Thus lessons
from further implementation and testing may continue to
incrementally alter the specifics of this protocol, beyond
what is documented here.
5. Naming
Resources which represent people or the means of messaging
them are identified via URLs. These URLs have the protocol
identifier 'pip'. For example, "pip://pip.lotus.com/JR_Ewing".
These URLs serve both to identify system principals and to
describe network locations where messages may be directed.
While identity URLs may serve as the default location at which
to attempt certain communication tasks, alternate temporary
URL locations are often used instead. For example, the person
"pip://pip.lotus.com/JR_Ewing" may actually request that any
subscriptions he begins deliver their information to
"pip://dallas.xyz.lotus.com/", and that any attempts to
instantly message him be directed to
"pip://dallas.xyz.lotus.com/iibox".
For this version of the demonstration protocol, PIP URLs
are always case-insensitive. Otherwise, they follow the
conventions of the URL "Common Internet Scheme Syntax"
described by RFC 1738.
6. Message format
All messages follow the formats established for HTTP/1.1
[HTTP/1.1]. The protocol identifier for messages compliant with
this demo protocol must read "PIP/0.2".
7. Transport
For this demo protocol, all transactions will be possible
through short-lived TCP hits, on which a single request and
response complete before the connection is closed.
HTTP/1.1-style pipelining MAY be implemented; since that
mechanism requires agreement by both sides to keep the
connection open, the added capability of some programs to
pipeline should not cause any problems for programs unable to
pipeline.
The default port for PIP/0.2 transactions is 321 [IANA].
8. Character Encoding
Request-lines, response lines, and headers must be encoded as
per HTTP/1.1. Character encodings for the content of PRESENCE
updates and instant-messages (as defined in Section 14) are
assumed UTF-8 (Unicode) as a default. Other encodings may be
specified by "charset" attribute in Content-type as in the
example below.
Content-Type: text/plain; charset="ISO-2022-JP"
9. Methods
9.1 SUBSCRIBE
The SUBSCRIBE method is used to express a persistent interest
in a remote resource, including any changes which occur at that
resource, or notifications which are delivered at that resource.
If a SUBSCRIBE request includes a 'Subscription-ID' header, it
serves to renew an existing subscription, and should also
include a 'Renew-Duration' header.
A SUBSCRIBE request should include a 'From' header,
identifying the principal (by PIP URL) who is requesting a
subscription. It may include a 'Sendback' header, describing
the PIP location to which the series of NOTIFYs which may follow
on this subscription must be directed. A SUBSCRIBE request may
include a 'Duration' header, which indicates the length of time
the subscriber would like the subscription to persist even in
the absence of any notification or renewal traffic.
A SUBSCRIBE request which succeeds will generate a 201
Created response, and must include a 'Duration' header which
dictates how long the subscription will persist in the absence
of traffic. It will include a 'Subscription-ID' header giving
the subscription a unique name at the providing resource. The
response content will be the current visible state of the
target resource.
9.2 UNSUBSCRIBE
The UNSUBSCRIBE method ends a previously established
subscription. It must include a 'Subscription-ID' identifying
the subscription to be cancelled. It may either be sent by
the subscriber or the publisher.
An UNSUBSCRIBE request from a publisher may include a
'Location' header, indicating an alternate place to
attempt the subscription, now that this subscription has
ended. (See part 10, Redirections.)
9.3 CHANGE
The CHANGE method is used to alter the content stored at
a given resource. This will result in NOTIFYs to subscribers
of that resource, and at least a temporary change in the
stored content of the resource at its server.
A CHANGE request may include a 'Duration' header, which
indicates that rather than replacing the current permanent
value of the resource, it instead provides an 'overlay'
or 'lease' for the given duration. Until that period expires,
the 'lease value' is the only one visible to external
operations.
Only one 'lease' may be active for a resource at once; the
most recent always takes precedence. A CHANGE that replaces
content with identical content still generates NOTIFYs.
9.4 NOTIFY
The NOTIFY method is used (1) to report CHANGEs inside a
subscription; and (2) to deliver arbitrary content to a
resource, outside a subscription, for potential acceptance
or relay; and (3) to relay a NOTIFYs inside a subscription.
When used to report CHANGEs, NOTIFYs are delivered to the
subscriber's 'Sendback' location, with a 'From' header
describing the resource that CHANGEd, a 'Subscription-ID'
header, and a 'Notify-class' header value of 'value'. The
recipient must acknowledge the receipt of a NOTIFY
on a valid subscription with a 200 OK response.
When used to deliver arbitrary content to a resource, the
NOTIFY request should include a 'From' header describing the
principal who initiated the notification and a 'Notify-class'
header with a value of 'transient'. Such NOTIFYs must not
have a 'Subscription-ID' header. If the NOTIFY can be
meaningfully accepted or relayed, it must generate
a 200 OK response; if it cannot be currently relayed (for
example no current subscribers to a valid resource) a
505 service unavailable response is appropriate.
When used to relay a delivery of arbitrary content to
a resource, inside a subscription to that resource, a
NOTIFY request must include a 'Subscription-ID' and
a 'Notify-class' header with a value of 'transient'.
The 'From' header provided by the original NOTIFY
initiator must be reported in an 'Origin' header,
and a new 'From' header describing the relaying
resource must be inserted. The recipient must acknowledge
the NOTIFY with a 200 OK (unless an error occurs).
A NOTIFY which reports something that occurred
inside a subscription (that is, meaning (1) or (3)
above) always has a 'Subscription-ID' header and
must not be treated as if it were a NOTIFY
delivering arbitrary content to a resource (meaning
(2)). Thus, a NOTIFY coming from one subscription,
going to a specific PIP resource, cannot generate
further NOTIFYs on other subscriptions to that
intermediate resource.
9.5 FETCH
The FETCH method is used to retrieve the current content
of a resource without beginning a subscription. (It is
essentially HTTP's GET, differently named to avoid any
mistaken impressions that it yet supports all GET facilities --
such as 'If-Modified-Since', etc.)
A successful response to a FETCH uses the 200 OK response
and includes as content the content of the targetted
resource.
10. Response Codes
PIP/0.2 reuses HTTP/1.1 response codes whenever appropriate.
A 404 Not Found response is appropriate when a request
with a 'Subscription-ID' identifies a subscription unknown
to the recipient, even if the resource identified by the
Request-URI can be found.
Software should follow HTTP/1.1 conventions when determining
whether an request which generated an error may be retried.
The 412 Precondition Failed response is used when certain
unsupported or currently inappropriate headers appear on
a request. This is not precisely the same meaning of that
response as in HTTP/1.1.
11. Headers
Any HTTP/1.1 headers may be included, however, only those
listed or described here are guaranteed to have meaning
to PIP/0.2 interoperable programs.
11.1 Headers Adopted from HTTP/1.1 Without Change:
Host
Location
User-Agent
Content-Type
Content-Length
11.2 Duration
An integer second count; used in SUBSCRIBE requests to
suggest a subscription lifetime; used in SUBSCRIBE responses
to dictate a subscription lifetime; used in CHANGE requests
to request a lease lifetime; used in CHANGE responses to
dictate a lease lifetime.
11.3 Renew-Duration
An integer second count; used in CHANGE requests and
SUBSCRIBE requests to request renewal of an existing lease
or subscription for the given period.
11.4 From
Identifies the principal/resource originating a request or
response. May appear almost anywhere.
11.5 Origin
Identifies the original initiator of a relayed NOTIFY,
when the original 'From' gets replaced by the relaying
resource's name.
11.6 Sendback
Used in SUBSCRIBE requests to specify a delivery location
for in-subscription notifications ifferent from the default
identity location of the subscriber.
11.7 Subscription-ID
A token uniquely identifying a subscription at a publishing
resource. Used in the response to an initial SUBSCRIBE to give
the subscription a name to be referred to later. Used in
NOTIFYs to identify what subscription they concern. Used in
renewing SUBSCRIBES to specify a subscription to renew.
A Subscription-ID is a 'token' as defined in the HTTP/1.1
specification.
11.8 Notify-class
Used in NOTIFY requests to distinguish those reporting CHANGEs
from those reporting arbitrary content relaying. May have
values of 'value' or 'transient'.
11.9 Regarding
May be used to indicate a method applies to something other
than the main content of a resource. Acceptable values are
"content" and "control"; if absent, a value of "content"
(default behavior) is implied. If a header specifying
"Regarding: control" appears on a request and the recipient
of that request does not offer remote-resource-control, a
response of 412 Precondition Failed should be returned.
When "Regarding: control" appears on a CHANGE, it changes
the control-info for a resource, rather than its content.
(This may subsequently affect the behavior of that resource
as described elsewhere.) When "Regarding: control" appears
on a FETCH, the returned content should be the control-info
for the given resource rather than the content. When
"Regarding: control" appears on a SUBSCRIBE, a subscription
should be granted which reports on the status of the
control-info rather than the content. NOTIFYs on such a
subscription should also have a "Regarding: control" header
line.
12. Leases
Leases are established by issuing a CHANGE request on
a resource with a 'Duration' header. The 'Duration'
value included with the request is the lifetime of the
lease, unless the response dictates a different 'Duration'.
Only one lease -- the most recently established lease --
exists at a resource at a time.
If any leased value has been set, that is the only value
visible to outside viewers of that resource (for example,
the content of a successful response to a SUBSCRIBE). The
expiration of a leased value generates NOTIFYs, even if
the permanent value reverted-to is identical to the expiring
leased value.
CHANGEs without a 'Duration' header change the "permanent"
version of a resource. If a current lease is in effect, such
a permanent change may generate no NOTIFYs until the lease
expires.
A lease may be cancelled by issuing another lease with
'Duration' zero. Proper usage of leases dictates that the
holder of a lease should cancel it explicitly with a CHANGE
request with 'Duration' zero as soon as reversion to the
permanent value is appropriate. The lease holder should not
rely on the immediate or prompt expiration of a lease as a
means of revising an obsolete value.
A lease may be refreshed by issuing a CHANGE request with
a 'Renew-Duration' header. The content of any such request
is ignored. That requested lifetime is honored, unless the
response to that request dictates a different 'Duration'.
If no lease is in effect at the time a renewal is requested,
an error response of 412 Precondition Failed should be
returned.
13. Subscriptions
A subscription begins with a SUBSCRIBE request. A subscription
definitely ends with any of (1) a matching UNSUBSCRIBE request
from the subscriber; (2) an UNSUBSCRIBE request delivered by
the publisher to the subscriber; (3) the elapse of a period of
time matching the last publisher-specified 'Duration' value,
with no successful SUBSCRIBE or NOTIFY traffic on the
subscription.
An attempt or attempts to deliver a NOTIFY on a subscription
which does not receive a 200 OK response may cause the
publisher to discard the subscription, but the publisher
should attempt continue to try delivering NOTIFYs until the
'Duration' otherwise expires.
14. Redirections
Redirections (302 moved temporarily responses which result
in an automatic transaction to an alternate address) are
only supported on initial SUBSCRIBES and FETCHes.
If the response to an initial SUBSCRIBE includes a 302 moved
elsewhere response, the SUBSCRIBE must be tried at the
URL suggested in the included 'Location' header. If fulfilled
at the given location, it need not be retried at the original
location unless the subscription at the alternate location
ends.
15. Domain Conventions
15.1 Presence Information
The common format for sharing online status information is a
well-formed XML document. The root element of this document
must be named 'PRESENCE'.
If the user represented by this data is 'online' then the
'PRESENCE' root must include a child element named 'ONLINE'.
It may include an element named 'OFFLINE' if the user
represented is 'offline'. ('OFFLINE' is assumed if neither
'ONLINE' or 'OFFLINE' appears.) These elements need not
have any content.
The following additional pieces of presence information
are optional. Any client should gracefully ignore any
information inside <PRESENCE> that it does not understand.
The 'ONLINE' element may include child elements named either
'AWAY' or 'BUSY' to indicate either absence from the vicinity
of the 'ONLINE' terminal (perhaps derived from programmatic
idle sensing) or an expressed desire not to be disturbed,
respectively.
The 'PRESENCE' root may include a child element named 'NOTE'
whose content is a free-form textual bulletin about their
current status.
The 'PRESENT' root may include a child element named
'NICKNAME' whose content is the represented user's
preferred short-form representation in a user interface.
EXAMPLES:
The minimum legal presence document indicating that
someone is offline is:
<PRESENCE />
The minimum legal presence document indicating that
someone is online is:
<PRESENCE>
<ONLINE />
</PRESENCE>
Using optional entities that all clients need not understand,
the following is an indication that someone is online, but
away, and "out to lunch":
<PRESENCE>
<ONLINE>
<AWAY />
</ONLINE>
<NOTE>out to lunch</NOTE>
</PRESENCE>
15.2 Messaging
Applications must attempt to send instant communications to
the entity represented at PIP URL 'X' by executing a NOTIFY to
the URL 'X/iibox' (which stands for "instant inbox"). That is,
the URL for delivering messages is established by applying a
convention to the subscribing URL. If subscribing to an
entity at a non-canonical location, the messaging URL must
be derived from the current subscribing location.
The NOTIFY must include a 'Notify-class' header with the value
'transient'. The content-type may be 'text/plain' or
'text/html'. It is expected that the URL to which the NOTIFY
is sent is either (1) a location which can directly display
the message to the intended recipient; or (2) a location to
which the intended recipient is SUBSCRIBEd, so that the
NOTIFY is effectively relayed to a final destination which
can directly display the message to the intended recipient.
If the message is adequately delivered to an endpoint which
"consumes" the message, the NOTIFY must receive a response
of 200 OK. If the location to which the NOTIFY is delivered
does not believe message will reach an adequate end
destination -- for example, it is an '/iibox' resource at a
server, to which the owner of that resource is not currently
subscribed, then the NOTIFY must receive an error response,
such as 505 Retry later.
15.3 Establishing Redirection (Optional)
A resource may be set to issue 302 Moved Temporarily
redirecting responses to all requests by using the
CHANGE request, together with a "Regarding: control"
header, to establish redirection instructions for a given
remote resource. These instructions should be provided
via an an XML document with a single element, a root
named 'REDIRECT', whose content is the URL to be
provided by redirections. For example:
<REDIRECT>pip://ws0013.activerse.com/</REDIRECT>
This control-info change may be subject to a lease, just as
with content changes. The control-info for a resource may
be viewed via a FETCH with a suitable 'Regarding' header,
or subscribed-to via a SUBSCRIBE with a suitable 'Regarding'
header.
16. Proxying
PIP applications may adopt an HTTP-like proxying strategy,
relaying messages through a local machine by including
information about the message's ultimate destination in
the Request-URI and/or 'Host' header.
However, processes which are the end destination receiving
proxied messages need not treat them specially, or even
take note that the traffic is proxied. As such, interop
demo programs may or may not attempt to implement proxying
at their own discretion.
Further proxying examples should appear in the transcripts.
17. Security
Security issues have been explicitly set aside for the
purposes of this demo. An eventual standard should include
suggested lowest-common-denominator mechanisms for
authenticating communicating peers across vendor/security
realms (analogous in its contribution to interoperability
to HTTP 'Digest' password authntication) as well as a way
for stronger authentication/encryption mechanisms to be
overlaid by mutual agreement between compatible software.
18. Sample Transcripts
18.1 Establishing availability through leases & instant-inbox
subscription
Consider Alice, with PIP URL "pip://pip.fujitsu.com/alice".
She begins running a PIP client on her desktop machine,
"aardvark.fujitsu.com", which secures local user port 1321
for inbound communications.
Before doing anything else, she may wish to confirm how the
world sees her:
[open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321]
out> FETCH /alice PIP/0.2
out> Host: pip.fujitsu.com
in< PIP/0.2 200 OK
in< Content-type: text/xml
in< Content-length: 12
in<
in< <PRESENCE />
[socket closes]
Then, she wants to appear online to the world -- but in case
of network or client troubles, she doesn't want this status
to persist indefinitely, so she requests a 20-second lease:
[open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321]
out> CHANGE /alice PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Duration: 20
out> Content-type: text/xml
out> Content-length: 34
out>
out> <PRESENCE>
out> <ONLINE />
out> </PRESENCE>
in< PIP/0.2 200 OK
in< Duration: 40
[socket closes]
Note that the server overrode the requested 'Duration' value,
perhaps because it wants to limit the frequency of renewal-
traffic. (Had the server been maintaining current subscriptions
to Alice's resource, her CHANGE would trigger a number of
NOTIFYs to subscribers. Examples of that appear later.)
Alice also wants to be able to receive instant-messages. By
PIP/0.2 conventions, people who want to message her will send
a NOTIFY to "pip://pip.fujitsu.com/alice/iibox". So, Alice
wants to subscribe to that location, to receive relayed
messages:
[open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321]
out> SUBSCRIBE /alice/iibox PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Sendback: pip://aardvark.fujitsu.com:1321
out> Duration: 30
in< PIP/0.2 201 subscription created
in< Duration: 60
in< Subscription-ID: aaii
[socket closes]
Alice is granted the subscription -- again with an altered
duration. This subscription-response has no content, although many
subscription-granting responses will include the current content
of the target resource.
Alice is online indefinitely, so shortly before the 40-second
content lease expires, she issues a lease renewal, which the server
confirms:
[open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321]
out> CHANGE /alice PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Renew-Duration: 40
in< PIP/0.2 200 renewed
in< Duration: 40
[socket closes]
Shortly before the 60-second 'iibox' subscription expires, she
issues a subscription-renewal as well:
[open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321]
out> SUBSCRIBE /alice/iibox PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Subscription-ID: aaii
out> Renew-Duration: 60
in< PIP/0.2 200 renewed
in< Duration: 60
[socket closes]
These renewals continue as long as Alice desires to remain
online and messageable. Any NOTIFYs delivered on the
subscription, confirmed by the subscriber, also serve to renew
the subscription for the last reported 'Duration'.
When Alice eventually decides to go offline, she should
cancel both her leased value and her instant-inbox
subscription. (Relying upon eventual expiration of these
relationships is discouraged.)
[open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321]
out> CHANGE /alice PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Renew-Duration: 0
in< PIP/0.2 200 lease terminated
in< Duration: 0
[socket closes]
[open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321]
out> UNSUBSCRIBE /alice/iibox PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Subscription-ID: aaii
in< PIP/0.2 200 cancelled
[socket closes]
18.2 Subscribing to others
Assuming Alice is online, she will typically subscribe to a
number of colleagues whose online status interests her. Let's
assume she is chiefly interested in Bob
(pip://pip.microsoft.com/bob) and Carl
(pip://pip.activerse.com/carl). She subscribes to Bob:
[open TCP from aardvark.fujitsu.com to pip.microsoft.com:321]
out> SUBSCRIBE /bob PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Sendback: pip://aardvark.fujitsu.com:1321
out> Duration: 60
in< PIP/0.2 201 granted
in< Subscription-ID: a2b
in< Duration: 60
in< Content-type: text/xml
in< Content-length: 12
in<
in< <PRESENCE />
[socket closes]
...and then to Carl...
[open TCP from aardvark.fujitsu.com to pip.activerse.com:321]
out> SUBSCRIBE /carl PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Sendback: pip://aardvark.fujitsu.com:1321
out> Duration: 60
in< PIP/0.2 201 granted
in< Subscription-ID: a2c
in< Duration: 60
in< Content-type: text/xml
in< Content-length: 22
in<
in< <PRESENCE></PRESENCE>
[socket closes]
Alice will refresh these subscriptions over time just as she did
the subscription to her own instant-inbox resource.
Now say Bob comes online. He issues a CHANGE (not shown) like
Alice's first change, which results in Alice receiving the
following notification, at the 'Sendback' location she
specified earlier:
[open TCP from pip.microsoft.com to aardvark.fujitsu.com:1321]
out> NOTIFY / PIP/0.2
out> From: pip://pip.microsoft.com/bob
out> Subscription-ID: a2b
out> Notify-class: value
out> Content-type: text/xml
out> Content-length: 31
out>
out> <PRESENCE><ONLINE /></PRESENCE>
in< PIP/0.2 200 ok
[socket closes]
Similarly, if at some later point while online, Bob adds an
optional <NOTE> element to offer a free-form glimpse of his
current activity, Alice will receive a similar notification:
[open TCP from pip.microsoft.com to aardvark.fujitsu.com:1321]
out> NOTIFY / PIP/0.2
out> From: pip://pip.microsoft.com/bob
out> Subscription-ID: a2b
out> Notify-class: value
out> Content-type: text/xml
out> Content-length: 67
out>
out> <PRESENCE>
out> <ONLINE />
out> <NOTE>about to head home</NOTE>
out> </PRESENCE>
in< PIP/0.2 200 ok
[socket closes]
When Bob eventually goes offline, Alice will receive a
notification returning his state to the original minimal value.
Alternatively, if Alice goes offline first, she should if
possible explicitly cancel her subscription, like the following:
[open TCP from aardvark.fujitsu.com to pip.microsoft.com:321]
out> UNSUBSCRIBE /bob PIP/0.2
out> Host: pip.microsoft.com
out> From: pip://pip.fujitsu.com/alice
out> Subscription-ID: a2b
in< PIP/0.2 200 cancelled
[socket closes]
18.3 Instant messaging
Assume both Alice and Bob are online, and subscribed to
each other, and Alice wants to send Bob a message. She
does so by generating a NOTIFY to Bob's instant-inbox:
[open TCP from aardvark.fujitsu.com to pip.microsoft.com:321]
out> NOTIFY /bob/iibox PIP/0.2
out> Host: pip.microsoft.com
out> From: pip://pip.fujitsu.com/alice
out> Notify-class: transient
out> Content-type: text/plain
out> Content-length: 42
out>
out> When do you arrive at the IETF conference?
Bob has previously subscribed (not shown) to the resource at
"pip://pip.microsoft.com/bob/iibox", in order to receive
relayed instant-messages. (If noone was subscribed to this
resource, Alice's message attempt above would generate an
immediate error, such as 505 Retry later.) Thus, Alice's
NOTIFY will be relayed along to the 'Sendback' location Bob
specified in his earlier subscription, which we will assume
to be "pip://bear.microsoft.com:1321":
[open TCP from pip.microsoft.com to bear.microsoft.com:1321]
out> NOTIFY / PIP/0.2
out> Origin: pip://pip.fujitsu.com/alice
out> From: pip://pip.microsoft.com/bob/iibox
out> Notify-class: transient
out> Subscription-ID: iibb
out> Content-type: text/plain
out> Content-length: 42
out>
out> When do you arrive at the IETF conference?
in< PIP/0.2 200 ok
[socket from pip.microsoft.com to bear.microsoft.com closes]
This successful in-subscription delivery allows Alice
to receive a confirmation of her message's delivery in
response to her initial NOTIFY
[on already-open socket from aardvark to pip.microsoft.com]
in< PIP/0.2 200 ok
[socket from aardvark.fujiotsu.com to pip.microsoft.com closes]
18.4 Publishing from elsewhere via redirection
Assume now that Carl comes online, using a client and server
which allows him to use redirection to publish from a different
location when online than when offline. Rather than establishing
a lease on the content of his "pip://pip.activerse.com/carl"
resource, he establishes a lease on its control-configuration:
[open TCP from cat.activerse.com to pip.activerse.com:321]
out> CHANGE /carl PIP/0.2
out> Host: pip.activerse.com
out> From: pip://pip.activerse.com/carl
out> Regarding: control
out> Duration: 30
out> Content-type: text/xml
out> Content-length: 49
out>
out> <REDIRECT>pip://cat.activerse.com:1321</REDIRECT>
in< PIP/0.2 200 OK
in< Duration: 30
[socket closes]
As a result, for the duration of this control lease, future
subscriptions to Carl's canonical URL will be redirected to
his current location, at "cat.activerse.com". Assuming Alice
is still subscribed at "pip.activerse.com", her subscription
will be cancelled by the server:
[open TCP from pip.activerse.com to aardvark.fujitsu.com:1321]
out> UNSUBSCRIBE / PIP/0.2
out> From: pip://pip.activerse.com/carl
out> Subscription-ID: a2c
in< PIP/0.2 200 cancelled
[socket closes]
...which will cause Alice to retry the subscription -- but
that attempt will be redirected rather than granted:
[open TCP from aardvark.fujitsu.com to pip.activerse.com:321]
out> SUBSCRIBE /carl PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Sendback: pip://aardvark.fujitsu.com:1321
out> Duration: 60
in< PIP/0.2 302 elsewhere
in< Location: pip://cat.activerse.com:1321
[socket closes]
...and Alice will then subscribe to Carl at the redirected
location:
[open TCP from aardvark.fujitsu.com to cat.activerse.com:1321]
out> SUBSCRIBE / PIP/0.2
out> Host: cat.activerse.com
out> From: pip://pip.fujitsu.com/alice
out> Sendback: pip://aardvark.fujitsu.com:1321
out> Duration: 60
in< PIP/0.2 201 granted
in< Subscription-ID: a2cc
in< Duration: 60
in< Content-type: text/xml
in< Content-length: 32
in<
in< <PRESENCE><ONLINE /></PRESENCE>
[socket closes]
Future NOTIFYs on this subscription will go direct from
"cat.activerse.com" to "aardvark.fujitsu.com:1321". If Alice
wishes to instant-message Carl, she will direct that
NOTIFY relative to her current subscription for Carl,
to "pip://cat.activerse.com:1321/iibox", rather than
through any URL at "pip.activerse.com".
19. References
[HTTP/1.1] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L.
Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1":
http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-03.txt
[IANA] IANA Protocol Numbers and Assignment Services, Port Numbers
http://www.isi.edu/in-notes/iana/assignments/port-numbers
20. Author Addresses
Gordon Mohr
Activerse, Inc.
1301 W. 25th St Suite 500
Austin, TX 78705
gojomo@activerse.com
Sonu Aggarwal
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
sonuag@microsoft.com
Mark Day
Lotus Development Corporation
55 Cambridge Parkway
Cambridge, MA 02142
Mark_Day@lotus.com
Avshalom Houri
Ubique
Building 18/D, Science Park
POB: 2523
Rehovot 76123, Israel
avshalom@ubique.com
Youji Kohda
Fujitsu Laboratories Ltd.
64 Nishiwaki, Ohkubo-cho
Akashi, 674-8555, Japan
kohda@flab.fujitsu.co.jp
Dave Marvit
Fujitsu Labs America
595 Lawrence Expressway,
Sunnyvale, CA 94086-3922
dave@marvit.org