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 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: The minimum legal presence document indicating that someone is online is: Using optional entities that all clients need not understand, the following is an indication that someone is online, but away, and "out to lunch": out to lunch 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: pip://ws0013.activerse.com/ 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< [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> out> out> 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< [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< [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> in< PIP/0.2 200 ok [socket closes] Similarly, if at some later point while online, Bob adds an optional 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> out> out> about to head home out> 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> pip://cat.activerse.com:1321 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< [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