[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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