INTERNET-DRAFT Gordon Mohr Expires: October, 1998 Activerse, Inc. WhoDP: Widely Hosted Object Data Protocol draft-mohr-whodp-00.txt (03/02/98) 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), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract The Widely Hosted Object Data Protocol (WhoDP) exists to communicate the current location and state of large numbers of dynamic, relocatable objects. Initially and most commonly, these objects are people, and the groupings or spaces that people use to enable communication. Loosely patterned after HTTP, WhoDP implements a publish-and- subscribe model, with objects' location and identity specified via URLs. A WhoDP program "subscribes" to locate and receive information about an object; a WhoDP program "publishes" to control the location and visible state of an object. 3. Contents 1. Status of this Memo...........................................1 2. Abstract .....................................................1 3. Contents......................................................1 4. Introduction..................................................3 4.1 The Need for a "Presence" Standard..........................3 4.2 Architectural Goals.........................................4 4.3 Overview of Operation.......................................5 4.4 Notable Features............................................6 4.4.1 URL Namespace...........................................6 4.4.2 Lightweight Servers.....................................6 4.4.3 Subscriber Selectivity..................................6 5. Protocol Parameters...........................................6 5.1 Protocol Version............................................6 INTERNET-DRAFT WhoDP [Page 2] 5.2 Message Format..............................................7 5.3 Message Transport...........................................7 5.4 URLs........................................................7 6. Terminology...................................................7 7. Method Definitions............................................9 7.1 SUB.........................................................9 7.2 PUB.........................................................9 7.3 UPD.........................................................9 7.4 GET........................................................10 7.5 PUT........................................................10 8. Status Code Definitions......................................10 8.1 Informational - 1xx........................................10 8.2 Successful - 2xx...........................................10 8.2.1 200 OK.................................................10 8.2.2 201 Created............................................10 8.3 Redirection - 3xx..........................................10 8.3.1 301 Moved Permanently..................................10 8.3.2 302 Moved Temporarily..................................10 8.4 Client Error - 4xx.........................................11 8.4.1 400 Bad Request........................................11 8.4.2 401 Unauthorized.......................................11 8.4.3 403 Forbidden..........................................11 8.4.4 404 Not Found..........................................11 8.4.5 410 Gone...............................................11 8.4.6 424 Unsupported Publishing Option......................11 8.4.7 425 Unsupported Content-Domain.........................11 8.4.8 426 Sessionless........................................12 8.4.9 427 Elsewhere..........................................12 8.5 Server Error...............................................12 8.5.1 500 Internal Server Error..............................12 8.5.2 501 Not Implemented....................................12 8.5.3 503 Service Unavailable................................12 8.5.4 505 Bad Version........................................12 9. Header Field Definitions.....................................12 9.1 Subject:..................................................12 9.2 Sender:...................................................13 9.3 Reply-To:.................................................13 9.4 To:.......................................................13 9.5 Request-ID:...............................................13 9.6 Session-ID:...............................................14 9.7 Location:.................................................14 9.8 Refresh:..................................................14 9.9 Sequence-Number:..........................................14 9.10 Content-Domain:...........................................14 9.11 Content-Type:.............................................15 9.12 Subscriber:...............................................15 9.13 Expires:..................................................15 9.14 Publish-Via:..............................................15 9.15 Repossess:................................................16 9.16 Retry-After:..............................................16 9.17 Software:.................................................16 9.18 Date:.....................................................16 10. General Behavior............................................17 10.1 Handling of Identity URLs.................................17 10.2 Requests..................................................18 INTERNET-DRAFT WhoDP [Page 3] 10.3 Responses.................................................18 10.4 UDP Retry Policies........................................19 10.5 Session Decay.............................................19 10.5.1 Refreshing Sessions...................................19 10.5.2 Inactivity Expiration.................................20 10.5.3 Communication Failure.................................20 11. Subscriptions...............................................20 11.1 Initiating a Subscription.................................20 11.1.1 Initial Request.......................................20 11.1.2 Granting a Subscription...............................21 11.1.3 Redirecting a Subscription............................21 11.1.4 Rejecting a Subscription..............................21 11.2 Continuing Communication in a Subscription................21 11.2.1 Client-to-server SUBs.................................22 11.2.2 Server-to-client UPDs.................................22 12. Publishing-Control-Sessions.................................22 12.1 Control Options...........................................22 12.1.1 Fulfill...............................................22 12.1.2 Redirect..............................................23 12.1.3 Consult...............................................23 12.1.4 Forbid................................................23 12.1.5 Proxy.................................................23 12.2 Initiating a Publishing-Control-Session...................23 12.2.1 Initial Request.......................................23 12.2.2 Granting a publishing-control-session.................24 12.2.3 Rejecting publishing-control..........................24 12.3 Continuing Communication in Publishing-Control............25 12.3.1 Client-to-server PUBs.................................25 12.3.2 Server-to-client UPDs.................................25 12.4 "Proxy" mode..............................................26 13. Content-Domains.............................................26 13.1 Default Content-Domain....................................27 13.1.1 Meaning of Content Entities...........................27 13.1.2 Meaning of Headers....................................28 13.2 Rules for Additional Content-Domains......................28 14. Security Issues.............................................28 15. Examples....................................................28 16. Issues......................................................33 16.1 This Document.............................................33 16.2 For Future Versions.......................................33 17. Version Notes...............................................33 18. References..................................................33 19. Author Contact and Discussion Info..........................34 20. Expiration..................................................34 4. Introduction 4.1 The Need for a "Presence" Standard 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 themselves -- information such as their current INTERNET-DRAFT WhoDP [Page 4] availability, capabilities, or interest in communication or collaboration. Sharing such information gives Internet users a useful sense of "presence", creating opportunities for interaction analogous to those offered by being in the same location. A burgeoning category of applications known as "buddy lists", "people browsers" or "colleague awareness tools" seek to provide the benefits of presence, but so far have used proprietary schemes: undocumented protocols, closed namespaces, and centrally-administered service centers. WhoDP was designed to serve as an open presence protocol, which can bring the benefits of standardization, interoperability, and ubiquity to the presence application category. 4.2 Architectural Goals In the spirit of the widely successful internet protocols for host-name-resolution, email, and the web, four qualities are essential for a standard, open presence protocol: 1. Scalability. Presence and instant-messaging functionality will become a standard utility available on every internet desktop and perhaps other internet-connected devices. Consequently, any protocol solution must scale to worldwide usage. 2. Openness. Since this functionality will spread across platforms, and become embedded in other applications, a standard is inevitable and desirable. Any protocol must thus enable the easy development of interoperable software by independent groups, across various implementation environments. Well-understood existing standards should be used and/or mimicked whenever appropriate. 3. Precision. An effective sense of "real-time presence" requires instantaneous, reciprocal, and reliable interaction. Thus, source and destination endpoints must be explicitly identified, and notification or communication between endpoints must be asynchronous, relatively lagless, and optionally cryptographically protected. 4. Flexibility. This level of real-time interaction between people (and other agents) opens up new application and platform possibilities, only some of which can be foreseen today. (For example, novelty or notification robots, shared gathering places, hardware device or mobile software agent monitoring and communication; etc.) Therefore, any architecture should be able to accommodate new entities and new modes of communication as they arise. WhoDP was designed to meet these goals, allowing presence networks to gracefully "grow like the web", without central coordination, as new servers, users, and applications come online. INTERNET-DRAFT WhoDP [Page 5] 4.3 Overview of Operation WhoDP aims to allow remote observation of WhoDP objects with interesting dynamic state, regardless of from where that object is currently being served. WhoDP achieves this by giving any interesting object an "authoritative" URL, which serves not only as its unique identity but also as a pointer to the location where that object resides "by default." For example, "whodp://activerse.com/jsmith". "Home servers" are thus the authoritative publishers of persons' presence information. A person comes "online" anywhere on the net by running a WhoDP user-agent on a capable internet- connected machine. She then contacts her "home server" to assume publishing-control over the WhoDP object representing herself. This control may involve changing the information published by the home server, causing subscriptions to be redirected elsewhere (including directly to her current machine), or some combination thereof. Control continues for as long as the user asserts it, according to minimum-activity parameters dictated by the home server. Having established control over her own "presence", the user would then attempt to "subscribe" in turn to each of people of interest to her. These initial subscription-requests would first be directed at each person's authoritative location, from where they would either be fulfilled or redirected to a current location. A successful subscription -- whether with the authoritative server or a temporary location -- begins with a complete report of object state, and continues with a small- level of followup traffic, such as publisher-generated updates regarding the object's state, or subscriber-generated "still- interested" traffic, according to refresh parameters dictated by the publisher. The user can go "offline" by canceling her subscriptions, and ending publishing-control over her identity WhoDP object. Notably, when someone is offline, it does not mean you cannot subscribe to her -- instead it means that you are subscribed to the relatively static version of her that is served by the "home server". All attempts to observe a WhoDP object should be done on behalf of another WhoDP object, allowing for user-configurable limitations on who can remotely observe what. All communication is UDP-based with a simple retry policy. Successful attempts to subscribe to or assume publishing-control over an object result in the creation of a "session", which affects the addressing of subsequent messages regarding that ongoing relationship. In any session (or attempt to begin a session), the side that initially requests the session is considered the 'client', whereas the side that responds to that request is considered the 'server'. A session only ends when INTERNET-DRAFT WhoDP [Page 6] either side cancels it, or when communication fails for other reasons, such as network unreliability or the abnormal exit of client or server software. Notably, any one WhoDP application often serves 'client' and 'server' roles simultaneously -- even doing both with the same remote peer application. In any session, the WhoDP location initially addressed is considered the 'target' of that session, while the WhoDP identity sought is considered the 'subject' of that session. 4.4 Notable Features 4.4.1 URL Namespace WhoDP features a decentralized, URL-based namespace. New servers, coming online anywhere, can immediately assign names, and publish objects to existing clients, without plugging into an official server-network. 4.4.2 Lightweight Servers WhoDP allows authoritative servers to be extremely lightweight, simple in implementation and resource requirements. In particular, if clients are encouraged to assume publishing- control by "self-publishing", causing all subscriptions to be redirected straight to the active client itself, servers paradoxically have less to do when more of their users are online, because each client effectively donates its own CPU and bandwidth to the system. Especially if the clients have wide state, rapidly changing state, or different viewable states for different subscribers, the improved scalability with "self- publishing" can be enormous. Such an arrangement also allows a high level of robustness against server failures. If a home server becomes unavailable, the direct relationships that are already established with other self-published entities are unaffected: basic presence awareness and communication is still possible. Only new attempts to subscribe to entities at the unavailable home server will fail. 4.4.3 Subscriber Selectivity Since WhoDP subscriptions are entered on behalf of another WhoDP identity, publishers have fine-grained control over what their subscribers see. A publishing application knows all current subscribers, and may selectively reject or publish different information to each. 5. Protocol Parameters 5.1 Protocol Version WhoDP follows the version-numbering scheme described in Section 3.1 of the HTTP/1.1 specification [RFC2068]. WhoDP is INTERNET-DRAFT WhoDP [Page 7] abbreviated "W" in version-fields. The version of WhoDP described in this document is "W/0.9". 5.2 Message Format WhoDP messages follow the syntax of HTTP/1.1 messages [RFC2068]. 5.3 Message Transport WhoDP messages -- both requests and responses -- are sent via UDP, which places special demands on the protocol. Since UDP is connectionless, the protocol needs facilities for matching responses to requests, and associating related series of messages. Message headers, including the headers "To", "Reply- To", "Request-ID" and "Session-ID", provide these facilities. Since UDP is unreliable, the protocol needs simple policies for handling packet loss, duplication, or out-of-order arrival. The headers "Request-ID", "Session-ID", and "Sequence-Number" assist in handling these situations, and section 10.4 describes minimal acceptable retry policies. Notably, WhoDP responses serve both as confirmation that the matching request was received, and as a substantive report of what effect, if any, that request had. Since UDP reliability is inversely proportional to the size of transmitted packets, in number of maximum-transmission-units (MTUs), WhoDP is best suited for applications where individual messages can be kept small, and resend policies may choose to take message size into account. Future versions of WhoDP may include optional, conditional, or fallback use of TCP connections for message transport. (See Section 16.2.) 5.4 URLs WhoDP identities and locations are both described as URLs, as specified in RFC1738. The scheme of a WhoDP URL is "whodp", and the syntax follows the "Common Internet Scheme Syntax" described in Section 3.1 of RFC1738. It is always clear from context whether a WhoDP URL is being used as an identity or a location; for example, the meaning of a WhoDP URL in any particular header is constant. Further information on the interpretation of identity URLs is available in section 10.1. If not explicitly specified, the default port value in a WhoDP URL is 2222. 6. Terminology WhoDP Object: A discrete, addressable, identifiable package of INTERNET-DRAFT WhoDP [Page 8] data which may be published or subscribed to through this protocol. WhoDP Objects have constant identities but may have transient locations -- and may in fact have multiple locations at once. A WhoDP Object need not appear to have the same state to all concurrent subscribers at all locations. WhoDP Program: Any program which generates WhoDP message traffic conformant to this specification. The term "user-agent" is also used to describe a WhoDP program commonly used by a single individual to access multiple remote WhoDP services. request: A message sent by a WhoDP program which requires a reply message. Requests may be standalone (GET and PUT), session- initiating (certain SUBs and PUBs), or in-session (UPD and other SUBs and PUBs). response: The reply to a request. WhoDP location: A WhoDP URL describing a host, port, and URI to which a message may be addressed. WhoDP identity: A WhoDP URL which uniquely names a WhoDP object, as well as providing the default WhoDP location for that object. session: A related series of WhoDP messages about a specific WhoDP object -- the "Subject" of the session. Only specific WhoDP messages, when successfully acknowledged, begin a session, and a session only ends when cancelled by either side, or communication fails for other reasons. server: A WhoDP program which meaningfully responds to SUB, PUB, GET, and PUT requests, and generates in-session UPD requests; or, in any session, the side which granted the session. client: A WhoDP program which generates SUB, PUB, GET, and PUT requests, and responds to in-session UPD requests; or, in any session, the side which initially requested the session. It is quite common for WhoDP programs to serve as both "clients" and "servers" at the same time. subject: The WhoDP identity to which a request or session is directed. target: The WhoDP location to which a request or session is directed. sender: the WhoDP identity on whose behalf a request is sent or a session is initiated. source: the WhoDP location from which a request is sent or a session is initiated. subscription: A session expressing interest in the current state of a WhoDP object at a particular location -- both at the moment the subscription is entered and whenever that state changes. INTERNET-DRAFT WhoDP [Page 9] publishing-control-session: A session expressing interest in remotely controlling what is published, and how, from a particular WhoDP location. authoritative location: A WhoDP identity treated as the default location for subscribing-to or publish-controlling a WhoDP object. The WhoDP program which hosts an object's authoritative location can be considered that object's "home server". Content-Domain: A specific binding of an interesting problem domain or data model into the WhoDP protocol. Within the broad outlines of WhoDP publishing and subscribing, various additional domain-specific semantics can be inserted. A named Content- Domain specifies additional interpretation for WhoDP traffic, especially for the continuing traffic in an ongoing session. 7. Method Definitions 7.1 SUB The "SUB" method is used in WhoDP requests to initiate, refresh, modify, or cancel subscriptions. Its effects depend on the headers present. The Request-URI in a SUB request always specifies the location expected to provide a subscription, which may or may not match the identity for which a subscription is sought. For the purposes of this document, an "initiating SUB request" seeks to begin a new subscription. A "continuing SUB request" seeks to operate on an already-granted subscription. The detailed semantics of a subscription are described in Section 11. 7.2 PUB The "PUB" method is used in WhoDP requests to initiate, refresh, modify, or cancel a publication-control-session for a WhoDP object. Its effects depend on the headers present. The Request- URI in a PUB request always specifies the remote location through which publishing will be affected, which may or may not match the identity that is being published. For the purposes of this document, an "initiating PUB request" seeks to begin control of publishing through a remote location. A "continuing PUB request" seeks to operate on an already- established publishing-control-session. The detailed semantics of a publishing-control-session are described in Section 12. 7.3 UPD The "UPD" method is used in WhoDP requests to update, modify the information carried by, or cancel an ongoing subscription or publishing-control-session. Its effects depend on the headers present. UPD requests are always sent by the program that granted the subscription or publishing-control-session (the INTERNET-DRAFT WhoDP [Page 10] server). The Request-URI used in an UPD request is dictate by the value of the "Reply-To" header used by the client when the session was initiated. 7.4 GET The "GET" method allows one-time retrieval of information from a WhoDP location, without indicating a desire for a continuing session. 7.5 PUT The "PUT" method allows one-time deposit of information to a WhoDP location, without indicating a desire for a continuing session. 8. Status Code Definitions The following status codes are defined for use in WhoDP response messages: 8.1 Informational - 1xx Informational codes are not used in this version of WhoDP. 8.2 Successful - 2xx 8.2.1 200 OK Used in a response to indicate that the matching request has succeeded. Additional details may be found in the response headers. Note that successful initiating SUB requests and initiating PUB requests actually generate a 201 code, indicating that a session has been created. 8.2.2 201 Created Used in a response to indicate that the matching request has succeeded, creating what was intended. For example, a continuing subscription or publishing-control-session was created. Details about what was created are included in the response headers. 8.3 Redirection - 3xx 8.3.1 301 Moved Permanently The requested object has been assigned a new permanent URL and any future references to this resource SHOULD be done using the returned URL, which MUST be given by the "Location" header in the response. Clients determine their own policies for automatically following this redirection, updating internal references, and/or querying the user for guidance. 8.3.2 302 Moved Temporarily INTERNET-DRAFT WhoDP [Page 11] The requested resource resides temporarily under a different URI. Since the redirection may often be different, the client SHOULD continue to use the Request-URI for future requests. The "Location" header of the response MUST give the current location for this resource. Clients SHOULD automatically follow this redirection, and MAY do so transparently to the user. 8.4 Client Error - 4xx 8.4.1 400 Bad Request The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. 8.4.2 401 Unauthorized The request requires user authentication. The response MUST include headers indicating a preferred security-scheme and parameters the client can use in a follow-up request to attempt authorization via that scheme. If the request already included authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. 8.4.3 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable. 8.4.4 404 Not Found The server has not found anything matching the Request-URI and/or the "Subject" header. 8.4.5 410 Gone The requested object is no longer available at the server and no forwarding address is known. This condition SHOULD be considered permanent. Clients SHOULD delete references to the URI given in the "Subject" header after user approval. 8.4.6 424 Unsupported Publishing Option The request specified a "Publish-Via" header which cannot be supported by the server. 8.4.7 425 Unsupported Content-Domain The request specified a "Content-Domain" header which cannot be supported by the server, addressed location, or addressed identity. INTERNET-DRAFT WhoDP [Page 12] 8.4.8 426 Sessionless The request to grant a session cannot be fulfilled, but the addressed location or identity may be available for a sessionless response. A SUB request MAY then be retried as a GET, or a PUB request retried as a PUT, if appropriate in the given Domain. 8.4.9 427 Elsewhere The request to assume publishing-control cannot be fulfilled, because a still-valid publishing-control session already exists to an alternate source location, and the request did not include a "Repossess" header of "true". 8.5 Server Error 8.5.1 500 Internal Server Error The server encountered an unexpected condition which prevented it from fulfilling the request. 8.5.2 501 Not Implemented The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. 8.5.3 503 Service Unavailable The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay may be indicated in a "Retry-After" header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response. 8.5.4 505 Bad Version The server does not support, or refuses to support, the WhoDP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message. 9. Header Field Definitions The following are the headers which must be understood to minimally implement the WhoDP protocol and version described here. Overlaid security-schemes and Domains may add additional meaningful headers. 9.1 Subject: INTERNET-DRAFT WhoDP [Page 13] The "Subject" header specifies the identity of the WhoDP object that a message is regarding. In SUB, PUB, GET, and PUT requests, the "Subject" is the target of the operation; in responses and UPD requests, the "Subject" confirms what identity the response or update describes. Acceptable values for the "Subject" header are WhoDP identity URLs. "Subject" is abbreviated "S" in messages. 9.2 Sender: The "Sender" header declares the identity of a requestor. In SUB, PUB, GET, and PUT requests, the "Sender" describes "on whose behalf" the operation is being requested. Acceptable values for the "Sender" header are WhoDP identity URLs. "Sender" is abbreviated "SE" in messages. 9.3 Reply-To: The "Reply-To" header specifies addressing information for future responses and UPD requests related to the current message. The "Reply-To" URI will be reflected in the "To" header of future responses on the same session, and in the Request-URI of future UPD requests on the same session. Acceptable values for the "Reply-To" header are URIs, as defined in section 3.2.1 of the HTTP/1.1 specification [RFC2068]. "Reply-To" is abbreviated "RT" in messages. 9.4 To: The "To" header supplies additional addressing information in responses, analogous to the Request-URI in the Request-Line of requests. Acceptable values for the "To" header are URIs, as defined in section 3.2.1 of the HTTP/1.1 specification [RFC2068]. "To" is abbreviated "T" in messages. 9.5 Request-ID: The "Request-ID" header provides additional information to help match responses to requests. A response must include a "Request- ID" value identical to that in the matching request. Acceptable values for the "Request-ID" header are tokens, as defined in section 2.2 of the HTTP/1.1 specification [RFC2068]. "Request-ID" is abbrieviated "RI" in messages. INTERNET-DRAFT WhoDP [Page 14] 9.6 Session-ID: The "Session-ID" header provides additional information to help match requests and responses to an ongoing session. Once specified in a session-granting-response, all subsequent messages regarding that session must include an identical "Session-ID" value. Acceptable values for the "Session-ID" header are tokens, as defined in section 2.2 of the HTTP/1.1 specification [RFC2068]. "Session-ID" is abbreviated "SI" in messages. 9.7 Location: The "Location" header field is used to specify a target for redirections. Acceptable values for the "Location" header are absolute URLs. URLs in "Location" headers are only WhoDP identity URLs in 301 ("Moved Permanently") responses, and are WhoDP location URLs in all other cases. "Location" is abbreviated "L" in messages. 9.8 Refresh: The "Refresh" headers suggests or dictates a number of seconds after which a subscription or publishing-control-session will decay without activity. "Refresh" values in SUB or PUB requests are suggestions; "Refresh" values in responses to SUBs and PUBs, or in UPD requests, set the prevailing refresh-interval for the current session. A "Refresh" value of zero (0) cancels a session. Acceptable values for the "Refresh" header are integer second counts. "Refresh" is abbreviated "R" in messages. 9.9 Sequence-Number: The "Sequence-Number" header serializes communication in an ongoing session. All SUB and PUB requests which do not initiate a session must include a "Sequence-Number" header, whose value is the count of like requests sent on this session. All UPD requests similarly must include a "Sequence-Number" header whose value is the number of UPDs sent on this session. Acceptable values for the "Sequence-Number" header are integers. "Sequence-Number" is abbreviated "SN" in messages. 9.10 Content-Domain: The "Content-Domain" header specifies a context for INTERNET-DRAFT WhoDP [Page 15] understanding WhoDP traffic. The WhoDP protocol merely establishes a minimal framework which can be used to carry various sorts of dynamic information and notifications. Defining and implementing a Domain enables refined interpretation of WhoDP messages, and especially message content-entities, appropriate to a specific application. Acceptable values for the "Content-Domain" header are absolute URLs which serve as the unique name of a defined and documented WhoDP Domain. If absent, the default Domain described in Section 13.1 is assumed. "Content-Domain" is abbreviated "CD" in messages. 9.11 Content-Type: The "Content-Type" header describes the MIME-type of any included content-entity. Acceptable values for the "Content-Type" header are valid MIME- types. "Content-Type" is abbreviated "CT" in messages. 9.12 Subscriber: The "Subscriber" header describes to which particular subscriber a bulletin or publishing command applies, in the context of a publishing-control-session. Acceptable values for the "Subscriber" header are WhoDP identity URLs or the string "*" signifying all subscribers. "Subscriber" is abbreviated "SU" in messages. 9.13 Expires: The "Expires" header is used to express a time after which a response or successful request should cease having an effect. Acceptable values for the "Expires" header are either the token "Never" or dates in the format specified by RFC 1123, and referred to as HTTP-dates in the HTTP/1.1 specification [RFC2068]. For example: Sun, 06 Nov 1994 08:49:37 GMT "Expires" is abbreviated "EX" in messages. 9.14 Publish-Via: The "Publish-Via" header is used to exercise fine-grained control in a publishing-control-session over how subscription requests are treated. INTERNET-DRAFT WhoDP [Page 16] Acceptable values for the "Publish-Via" header are one or more of the tokens "Fulfill", "Redirect", "Consult", "Forbid", or "Proxy". When a "Publish-Via" value is needed, but this header is absent, a default value of "Fulfill" is assumed. "Publish-Via" is abbreviated "PV" in messages. 9.15 Repossess: The "Repossess" header is used to indicate whether a request for publishing-control should displace an existing publishing- control-session from elsewhere. Acceptable values for the "Repossess" header are "T", "t", "true", "F", "f", or "false". When a "Repossess" value is needed, but this header is absent, a default value of "true" is assumed. "Repossess" is abbreviated "REP" in messages. 9.16 Retry-After: The "Retry-After" header can be used to indicate how long a service is expected to be unavailable to the requesting client. The time given, as either an absolute date or second-count from now, indicates the time after which a rejected request or cancelled session may be reattempted, with a possibility to success/re-establishment. Acceptable values for the "Retry-After" header are either integer second counts or dates in the format specified by RFC1123, refered to as HTTP-dates in the HTTP/1.1 specification [RFC2068]. "Retry-After" is abbreviated "RA" in messages. 9.17 Software: The "Software" header is used to identify the software which generated the WhoDP message. It is roughly analogous to the "User-Agent" or "Server" headers in HTTP. Acceptable values for the "Software" header are arbitrary strings describing the name and version of the relevant WhoDP program. "Software" is abbreviated "SW" in messages. 9.18 Date: The "Date" header is used to specify the time at which the INTERNET-DRAFT WhoDP [Page 17] current message was generated. Acceptable values for the "Date" header are dates in the format specified by RFC1123, referred to as HTTP-dates in the HTTP/1.1 specification. "Date" is abbreviated "D" in messages. 10. General Behavior 10.1 Handling of Identity URLs Certain URLs in WhoDP are distinguished as "identity URLs". In particular, URLs which appear in the "Subject", "Sender", and "Subscriber" headers always refer to a WhoDP identity -- not a transitory WhoDP location from which that identity may currently be publishing or subscribing. WhoDP URLs follow the "Common Internet Scheme Syntax" described in section 3.1 of RFC1738. For the purposes of comparing two WhoDP identity URLs, to determine if they refer to the same WhoDP object, WhoDP applications... · MUST NOT treat case as significant in the 'scheme' or 'host' portions of a URL. · MUST treat case as significant in the 'url-path' portion of a URL. · MUST NOT consider hostnames which resolve to the same IP address as identical. · MUST NOT consider the presence or absence of a trailing "/" to be significant, if the 'url-path' portion is empty. · MUST NOT consider the explicit specification of the default port to be different than implied specification of the default port. For example, the following WhoDP identity URLs are prima facie identical: whodp://ding.activerse.com WHODP://ding.activerse.com whodp://DING.activerse.COM whodp://ding.activerse.com/ whodp://ding.activerse.com:2222 WHODP://ding.ACTIverse.com:2222/ The following two URLs MUST NOT be assumed to represent the same identity: whodp://ding.activerse.com/bill whodp://ding.activerse.com/Bill Similarly, the following two URLs MUST NOT be assumed to represent the same identity, even if the current DNS resolution of "ding.activerse.com" is "207.8.29.7": INTERNET-DRAFT WhoDP [Page 18] whodp://ding.activerse.com/bill whodp://207.8.29.7/bill If a particular WhoDP server wishes to adopt a policy of case- insensitivity or hostname-equivalence, it should choose a preferred identity URL representation for each WhoDP object hosted. Requests for that entity under acceptably-close "Subject" names MAY then generate "301-Moved Permanently" replies which include the preferred name. For example, a request for "whodp://207.8.29.7/BILL" might result in a 301 reply, with the new "Location" as "whodp://ding.activerse.com/Bill". 10.2 Requests All requests are either "standalone" (GET, PUT), "session- initiating" (SUB, PUB, without "Session-ID" header), or "in- session" (SUB, PUB, UPD, with "Session-ID" header). Standalone and session-initiating requests MUST include a "Subject" header, and MUST NOT include either a "Session-ID" header or "Sequence-Number" header. Any request MAY include either or both of the "Request-ID" header and the "Reply-To" header. In-session requests MUST include a "Session-ID" header and a "Sequence-Number" header. In-session requests MAY include more than one "Session-ID" header, and if so, only the first to appear actually describes the session to which the request applies. The additional headers only have significance as described in Section 10.5.1. 10.3 Responses So that responses can be matched with requests, given a request, the corresponding response... · MUST include a "Subject" header, IF the request included such a header, with an identical value. · MUST include a "Request-ID" header, IF the request had such a header, with an identical value. · MUST include a "To" header, IF the request had a "Reply-To" header, with a corresponding value. · MUST include a "Session-ID" header, IF the request had such a header, with an identical value to the first "Session-ID" header on the request. · MAY include additional "Session-ID" headers, IF the request had multiple "Session-ID" headers, as described in Section 10.5.1. · MUST include a "Sequence-Number" header, IF the request had such a header, with an identical value. Any error response (non-2xx) to a standalone or session- initiating request MAY include a content-entity which describes the problem in a human readable format (most likely 'text/plain' or 'text/html'). INTERNET-DRAFT WhoDP [Page 19] A WhoDP program SHOULD send a valid response, even if just an error, to every request it receives and understands well enough to compose a legal error response. 10.4 UDP Retry Policies WhoDP applications may adopt their own policies for resending unacknowledged requests, within the following parameters: · A single request should be resent no more than 10 times. · A single request should be resent no more than once per second. · A single request should not be resent more than 90 seconds after the initial send. · If multiple retries fail to generate a received response within the desired amount of time, an application should wait at least 30 seconds before performing any operation which effectively restarts the retry-cycle on a similar transaction with the same remote host. For example, an acceptable retry policy within these parameters would be: resend a request every 3 seconds, up to 5 times, until a response is received; give up if no response is received within 30 seconds after the initial send, and refrain from sending a similar request to the same destination until 60 seconds after the initial send. Beyond these guidelines, applications are free to choose their own retry repetition, frequency, and timeout policies. By separate, explicit agreement (through mechanisms unspecified), communicating WhoDP programs may adopt retry policies outside these parameters. 10.5 Session Decay 10.5.1 Refreshing Sessions WhoDP clients MUST maintain for each ongoing session the time of last activity on that session, 'activity' defined as either the sending of a SUB or PUB request which referred to that session and was acknowledged, or the receipt of an UPD request. If the number of seconds since last activity is equal to or greater than the currently-established session "Refresh" value, and the client wishes the session to remain valid, it MUST send a request for the purpose of "refreshing" the session. Clients SHOULD NOT send requests which are solely for the purpose of refreshing a session significantly sooner than than specified by the "Refresh" value. A request for the purpose of refreshing a session MUST include appropriate "Session-ID" and "Sequence-Number" headers. Any client-generated request, on any session, MAY include additional "Session-ID" headers, beyond the first, to refresh INTERNET-DRAFT WhoDP [Page 20] the named sessions in a "piggy-back" fashion. The named sessions must be served from the same WhoDP server (same host & port), and must have all been created with the same "Reply-To" header value. The server MUST only consider refreshing these additional sessions if the primary request generates a successful response (2xx), and MUST list all sessions for which activity has been noted as additional "Session-ID" headers in the response. The client MUST only consider as successfully refreshed those sessions listed in a successful response. 10.5.2 Inactivity Expiration If a server receives no activity which refers to a session -- neither requests nor responses to server-sent UPDs -- for a period of time equal to twice the "Refresh" interval, it MAY discard the session due to inactivity. Once discarded, requests referencing the session should be answered with a status-code 404 ("Not Found"). 10.5.3 Communication Failure If a WhoDP program makes repeated attempts to deliver a request, in accordance with the guidelines in Section 10.4, and receives no response, it SHOULD discard any session(s) associated with the request on account of communication-failure. Requests referencing discarded sessions should be answered with a status- code 404 ("Not found"). The program MAY attempt to reestablish those sessions for which it was serving as the client. 11. Subscriptions 11.1 Initiating a Subscription 11.1.1 Initial Request A SUB request for the purpose of initiating a subscription... · MUST include a "Subject" header, specifying the WhoDP identity to which a subscription is desired. · SHOULD include a "Sender" header, specifying the WhoDP identity representing the subscriber. · MAY include either or both of the headers "Request-ID" and "Reply-To", as may be necessary or convenient for the sending application to recognize a response to this SUB. · MAY include a "Refresh" header, suggesting a refresh interval for a granted subscription. · MAY include a "Domain" header, suggesting a context for interpreting this and subsequent messages in this subscription. · MAY include additional headers, suggesting a security scheme, or headers defined by the Domain or security scheme in use. 11.1.2 Granting a Subscription INTERNET-DRAFT WhoDP [Page 21] If a subscription is granted, the response... · MUST use the response-code 201 ("Created"). · MUST include a "Subject" header, confirming the identity this subscription regards. · MUST include a "Request-ID" header, IF the SUB request had such a header, with a matching value. · MUST include a "To" header, IF the SUB request had a "Reply- To" header, with a matching value. · MUST include a "Session-ID" header. · MUST include a "Refresh" header, IF the SUB request did not suggest a refresh-value, and MAY include a "Refresh" header which overrides a suggested value. · MUST include a "Domain" header, unless the subscription is to be interpreted according to the default Domain described in section 13.1. · MAY include other headers related to a security scheme or Domain in use. · SHOULD include a content-entity describing the subject WhoDP object. 11.1.3 Redirecting a Subscription If a subscription cannot be granted, but should be tried elsewhere, the response... · MUST use the response-code 301 ("Moved Permanently") or response-code 302 ("Moved-Temporarily") · MUST include a "Subject" header, confirming the identity this response regards. · MUST include a "Request-ID" header, IF the SUB request had such a header, with a matching value. · MUST include a "To" header, IF the SUB request had a "Reply- To" header, with a matching value. · MUST include a "Location" header, containing the WhoDP location URL where a subscription should currently be attempted. 11.1.4 Rejecting a Subscription If a subscription cannot be granted, nor can a suggestion for obtaining it elsewhere be made, the response... · MUST use a response-code describing the nature of the problem. · MUST include a "Subject" header, confirming the identity this response regards. · MUST include a "Request-ID" header, IF the SUB request had such a header, with a matching value. · MUST include a "To" header, IF the SUB request had a "Reply- To" header, with a matching value. · MAY include other headers related to a security scheme or Domain in use, that might further detail why a subscription is unavailable or help a future request succeed. 11.2 Continuing Communication in a Subscription INTERNET-DRAFT WhoDP [Page 22] 11.2.1 Client-to-server SUBs A SUB request relating to an existing subscription... · MUST continue to use the same Request-URI used in the successful subscription-initiating SUB request. · MUST include a "Session-ID" header, matching the value returned when the subscription was granted. · MUST include a "Sequence-Number" header, indicating the number of SUB requests sent on this subscription. · MAY include a "Refresh" header, to suggest a new refresh value, or with the value "0", to cancel the subscription. · MAY include other headers related to a security scheme or Domain in use. · MAY include a content-entity interpreted according to the Domain in use. 11.2.2 Server-to-client UPDs An UPD request relating to an existing subscription... · MUST use a Request-URI derived from the "Reply-To" header which was in the successful initiating-SUB. · MUST include a "Session-ID" header, matching the value returned when the subscription was granted. · MUST include a "Sequence-Number" header, indicating the number of UPD requests sent on this subscription. · MAY include a "Refresh" header, dictating a new refresh value, or with the value "0", to cancel the subscription. · MAY include a "Location" header, redirecting the subscription elsewhere, IF a "Refresh" header is canceling the subscription. · MAY include other headers related to a security scheme or Domain in use. · MAY include a content-entity interpreted according to the Domain in use. 12. Publishing-Control-Sessions 12.1 Control Options WhoDP's PUB method allows flexible control over how a remote location handles subscriptions, as specified through the "Publish-Via" header. 12.1.1 Fulfill "Fulfill", the simplest and default option, indicates that a subscription or subscriptions at the target location should be granted, maintained, or denied according to prevailing policies local to that location, with no effect on the publishing-control- session. Asserting publishing-control with the option "Fulfill" avoids receiving any information about individual subscribers; instead, INTERNET-DRAFT WhoDP [Page 23] a client only controls publishing by changing the WhoDP object state published by the server. 12.1.2 Redirect "Redirect" indicates that a subscription or subscriptions at the target location should be redirected to the location given in an accompanying "Location" header. If no "Location" is specified, the client source location is assumed. Asserting publishing-control with the option "Redirect" causes all current and future subscriptions to be redirected to the location provided. 12.1.3 Consult "Consult" indicates that for the applicable subscription(s), the client should be asked what to do. Asserting publishing-control with the option "Consult" causes all current and future subscriptions to generate an UPD message to the client, allowing the client to individually specify how to handle that subscription. 12.1.4 Forbid "Forbid" indicates that for the applicable subscription(s), existing service should be cancelled or a subscription-request should be rejected with the 403 ("Forbidden") response. 12.1.5 Proxy "Proxy" indicates that the target location will serve as a proxy for the source location. For as long as the publishing-control- session is active, all messages arriving at the target location from the source (which do not concern the active session) will be forwarded along to other final destinations, and all messages arriving at the target from elsewhere will be forwarded back to the source location. "Proxy" is the most complicated and resource-consumptive mode of operation, and thus may not be supported by all servers. Its behavior is described separately from the more simple options, in Section 12.4. 12.2 Initiating a Publishing-Control-Session 12.2.1 Initial Request A PUB request for the purpose of initiating a publishing-control- session... · MUST include a "Subject" header, specifying the WhoDP identity for which control is desired. · MAY include either or both of the headers "Request-ID" and INTERNET-DRAFT WhoDP [Page 24] "Reply-To", as may be necessary or convenient for the sending application to recognize a response to this PUB. · MAY include a "Refresh" header, suggesting a refresh interval for a granted publishing-control-session. · MAY include a "Publish-Via" header, specifying how all current and future subscriptions are to be handled. · MAY include a "Location" header, if a "Publish-Via" option of "Redirect" was specified, to give the location to which subscriptions should be redirected. · MAY include a "Repossess" header, specifying whether this request should supercede a valid ongoing publishing-control- session from elsewhere. · MAY include a "Domain" header, suggesting a context for interpreting this and subsequent messages in this session. · MAY include additional headers, suggesting a security scheme, or headers defined by the Domain or security scheme in use. 12.2.2 Granting a publishing-control-session If publishing-control is granted, the response... · MUST use the response-code 201 ("Created"). · MUST include a "Subject" header, confirming the identity this subscription regards. · MUST include a "Session-ID" header. · MUST include a "Refresh" header, IF the PUB request did not suggest a refresh-value, and MAY include a "Refresh" header which overrides a suggested value. · MUST include a "Domain" header, unless the publication- control is to be interpreted according to the default Content- Domain described in section 13.1. · MAY include "Location" headers, describing alternate names under which the target location is known. · MAY include other headers related to a security scheme or Content-Domain in use. · SHOULD include a content-entity describing the current state of the subject WhoDP object, at the session target location. Note that certain "Publish-Via" options, such as "Consult", may also trigger a flurry of UPD messages on the publishing-control- session as the client is asked how to handle each existing subscription at the server. 12.2.3 Rejecting publishing-control If publishing-control cannot be granted for any reason, the response... · MUST use a response-code describing the nature of the problem. · MUST include a "Subject" header, confirming the identity that this response regards. · MAY include other headers related to a security scheme or Content-Domain in use, that might further detail why a subscription is unavailable or help a future request succeed. INTERNET-DRAFT WhoDP [Page 25] Redirection of an initial PUB request is possible, and generally means that the client can achieve the desired effect by going to the redirected location. User-agents may adopt their own policies as to whether such redirections are revealed to the user. If another publishing-control session exists and "Repossess" was not specified, the rejection MAY include a "Location" header describing the location of the active session. 12.3 Continuing Communication in Publishing-Control 12.3.1 Client-to-server PUBs A PUB request relating to an existing publishing-control- session... · MUST continue to use the same Request-URI used in the successful session-initiating PUB request. · MUST include a "Session-ID" header, matching the value returned when the session was granted. · MUST include a "Sequence-Number" header, indicating the number of PUB requests sent on this subscription. · MAY include a "Publish-Via" header, specifying how the target location handles subscriptions. · MAY include a "Subscriber" header, modifying which identities that an accompanying "Publish-Via" header affects. · MAY include a "Refresh" header, to suggest a new refresh value, or with the value "0", to cancel the session. · MAY include other headers related to a security scheme or Domain in use. · MAY include a content-entity interpreted according to the Domain in use. 12.3.2 Server-to-client UPDs An UPD request relating to an existing publishing-control- session... · MUST use a Request-URI derived from the "Reply-To" header value that was in the successful initiating-PUB. · MUST include a "Session-ID" header, matching the value returned when the session was granted. · MUST include a "Sequence-Number" header, indicating the number of UPD requests sent on this session. · MAY include a "Subscriber" header, indicating the identity of a subscriber which this UPD regards. · MAY include a "Publish-Via" header, which indicates the options available for handling the subscriber named in an accompanying "Subscriber" header. · MAY include a "Refresh" header, dictating a new refresh value, or with the value "0", to cancel the session. · MAY include a "Location" header, redirecting the session elsewhere, IF a "Refresh" header is canceling the session. INTERNET-DRAFT WhoDP [Page 26] · MAY include other headers related to a security scheme or Domain in use. · MAY include a content-entity interpreted according to the Domain in use. In a publishing-control-session established with a "Publish-Via" option of "Consult", UPD messages which include a "Subscriber" header are information about that subscriber. If such a UPD also includes a "Publish-Via" value, it indicates that the named WhoDP identity either is currently subscribing or has requested a subscription at the target location, and the tokens in the "Publish-Via" header list possible options for handling this subscriber. The client's confirming response to this UPD should include a "Publish-Via" header which chooses one of the options. If the choice is again "Consult", the client wishes to receive notification when the subscription ends, and reserves the right to "Redirect" that subscriber in a future PUB message on the current session. A UPD which includes a "Subscriber" but an empty "Publish-Via" header indicates that the subscriber's subscription has ended, and no further publishing-control options are available with regard to them. 12.4 "Proxy" mode The "Proxy" publishing-control option must be set for an entire publishing-control-session, at initiation. If the request for a "Proxy" publishing-control-session is granted, then for the duration of the session, the target server MUST forward messages according to the following rules: · Any requests or responses which come from the client source location, and specify a Request-URI or "To" header value representing a location not on the target server, MUST be forwarded to that specified location. The proxying server MAY alter the Request-URI, "To" header, or "Reply-To" header to assist the ultimate destination in understanding the message, or to indicate how responses must be addressed to find their way back to the client. · Any requests or responses that are directed at the target location, and received from other sources, MUST be forwarded to the publishing-control-session's source location. The proxying server MAY alter the Request-URI, "To" header, or "Reply-To" header as necessary. Modifications to the Request-URI, "To" header, or "Reply-To" header should be limited to removing routing information only needed by the proxying server, and altering "Reply-To" values so that properly-formed responses to forwarded requests can find their way back to the actual request-originator. 13. Content-Domains INTERNET-DRAFT WhoDP [Page 27] "Content-Domains" provide a context for interpreting WhoDP activity in the same manner that "Content-Type" allows the interpretation of individual content entities. Specifying a Content-Domain dictates the meaning of headers and content entities, for either a single transaction or the duration of a session. Thus, when a new application or notification/state-sharing scheme would like to make use of WhoDP's general session and control mechanisms, but requires a different interpretation of headers, content-entities, and continuing session messages than existing WhoDP applications, a new Content-Domain may be defined. Applications operating in the new problem domain can identify each other, and those not understanding the new domain can avoid misinterpreting new traffic. Identifiers for Content-Domains are absolute URIs, following the example of the XML namespace mechanism [REF] or the extension- identifiers of PEP [REF]. When no "Content-Domain" header is present, programs MUST consider the default domain described below as being in effect. 13.1 Default Content-Domain 13.1.1 Meaning of Content Entities 13.1.1.1 In GET and Initiating SUB Requests Content entities in GET and initiating SUB requests, if present, should be considered the request originator's reported state for the WhoDP object named in an accompanying "Sender" header. In successful responses (2xx) to GET and initiating SUB requests, content MUST indicate the current state of the requested "Subject", at the target location, for the requestor. 13.1.1.2 In PUT and all PUB Requests Content entities in PUT and all PUB requests must be considered an attempt to set the state of the target location, to be equal to the included content. Any state set as a result of a PUB operation only persists as long as the enclosing publishing- control-session is valid; when it is cancelled or decays, the object MUST revert to its previous state. (Only PUTs may be used to effect indefinitely persistent changes.) 13.1.1.3 In Subscription UPDs In Subscription UPDs, a content entity, if present, must be considered a report of the current state of the subscription's subject, at the target location, for the purposes of the sender/source location. 13.1.1.4 In Error Responses INTERNET-DRAFT WhoDP [Page 28] Any unsuccessful response (status code other than 2xx) MAY include a human-readable explanation of the problem, typically of Content-Type 'text/plain' or 'text/html'. 13.1.1.5 Elsewhere The meaning of content entities in all other messages is undefined and programs SHOULD NOT use content entities where their meaning is undefined. Specifically, there is no default meaning for content entities which appear in: · successful responses to PUT, PUB, or in-session SUB requests · UPD requests inside a publishing-control-session · successful responses to UPD requests 13.1.2 Meaning of Headers No special headers or header meanings are defined for the default Content-Domain. 13.2 Rules for Additional Content-Domains Defining new Content-Domains requires explaining what significance, if any, content entities and headers have in various messages, and how those entities and headers must or should be interpreted. For example, in the default Content-Domain, PUBs and subscription UPDs must include a complete representation of the Subject's current or desired state. Other Content-Domains could offer an interpretation of PUBs or UPDs which allows them to specify only that portion of the Subject that should or has changed. Definition of new Content-Domains must not contradict with this base specification in ways that would confuse WhoDP programs unfamiliar with the new Content-Domain. 14. Security Issues Security issues, such as authenticating subscribers or publishers, or encrypting traffic against eavesdropping, are explicitly not considered in this specification. It is expected that adequate schemes can be overlaid into WhoDP traffic, adapted or derived from other prevailing mechanisms. Companion documents to this specification will address these issues. 15. Examples Assume that a number of individuals are using WhoDP, under just the default Content-Domain, to share short descriptions of their current moods. Consider a user James, working at the machine 'jim.activerse.com', who has advertised to others that his current mood will always be available from the URL INTERNET-DRAFT WhoDP [Page 29] "whodp://mood.activerse.com/james". For the purpose of clarity, full header names will be shown in example traffic, rather than the abbreviations which must actually be used. James launches his mood-sharing WhoDP agent, which seeks to assert publishing-control over his the authoritative location for his mood: [udp to mood.activerse.com:2222 from jim.activerse.com:2222] PUB /james W/0.9 Subject: whodp://mood.activerse.com/james Request-ID: Foo604 Publish-Via: Redirect Refresh: 20 [end] Understanding this message: This request indicates that James wishes to assert publishing control over the WhoDP object named "whodp://mood.activerse.com/james", at its authoritative location, also "whodp://mood.activerse.com/james". Since no "Reply-To" is specified, the source location of this request is the root location at the originating machine: "whodp://jim.activerse.com/". The type of control requested is for all subscriptions and subscription to be redirected elsewhere. Since no preferred "Location" is specified, the source location of the request, "whodp://jim.activerse.com/", is where redirections are desired. James' user-agent wishes to refresh a granted session once every 20 seconds, in the absence of other activity. Since no content entity is included, James does not want to change any state kept at his home server -- not even temporarily. (In a real application, this initial PUB request would almost certainly include additional headers authenticating James to his home server, using mechanisms specified elsewhere.) If this request for publishing-control is granted, a response like the following will ensue: [udp to jim.activerse.com:2222 from mood.activerse.com:2222] W/0.9 201 Session Created Subject: whodp://mood.activerse.com/james Request-ID: Foo604 Session-ID: 90210 Refresh: 60 Content-Type: text/plain Healthy, wealthy, and wise! [end] Understanding this message: this response indicates that James' request for publishing-control has been granted. The Session-ID to use in future messages relating to this session is "90210". Barring other activity, James' user-agent should only concern itself with refreshing the session every 60 seconds -- not the INTERNET-DRAFT WhoDP [Page 30] every 20 it originally suggested. Finally, the current server- side state of the Subject WhoDP object is reported -- perhaps to let James know how he has been seen while absent, or to seed his interface with an initial value for him to edit. If there is no activity on session "90210" for 60 seconds, James' user-agent should generate keep-alive traffic reasserting his interest in keeping the session open. This would look like: [udp to mood.activerse.com:2222 from jim.activerse.com:2222] PUB /james W/0.9 Session-ID: 90210 Sequence-Number: 2 [end] Receiving this message would cause the server to mark the publishing-control-session as still active, and generate the following minimal response: [udp to jim.activerse.com:2222 from mood.activerse.com:2222] W/0.9 200 OK Session-ID: 90210 Sequence-Number: 2 [end] Now, James' user-agent may turn its attention to retrieving live information on the moods of everyone else James is interested in. If James has registered an interest in the mood of his colleague Susan, with a WhoDP identity of "whodp://whodp.w3.org/susan", his program would generate the following: [udp to whodp.w3.org:2222 from jim.activerse.com:2222] SUB /susan W/0.9 Subject: whodp://whodp.w3.org/susan Sender: whodp://mood.activerse.com/james Request-ID: Bar321 [end] Understanding this message: this request indicates an interest in a continuing subscription to the WhoDP object named "whodp://whodp.w3.org/susan", from the same location. Additionally, the WhoDP identity of the requester is identified. (Again, in a real application, this message could include additional information which would allow the server at whodp.w3.org to verify that the sender is authorized to use the identity "whodp://mood.activerse.com/james".) If Susan's home server decides to grant this subscription, there will be a response like the following: [udp to jim.activerse.com:2222 from whodp.w3.org:2222] W/0.9 201 Subscription Created Subject: whodp://whodp.w3.org/susan Request-ID: Bar321 Session-ID: 78705 INTERNET-DRAFT WhoDP [Page 31] Refresh: 45 Content-Type: text/plain Acceptably jolly. [end] Now, let's assume Susan launches her "mood client" from a machine named "dialup99.isp.net". She decides to assert publishing-control with the "Consult" option, and change her home-server state at the same time: [udp to whodp.w3.org:2222 from dialup99.isp.net:2222] PUB /susan W/0.9 Subject: whodp://whodp.w3.org/susan Request-ID: Baz901 Publish-Via: Consult Content-Type: text/plain Quasi-jolly. [end] If successful, this request will cause three things to happen: a response to Susan confirming her publishing-control-session (not shown); an update on James' subscription reflecting the new state for "whodp://whodp.w3.org/susan"; and an update on Susan's publishing-control-session consulting her what to do with James' subscription. Let's look at the update sent to James first: [udp to jim.activerse.com:2222 from whodp.w3.org:2222] UPD / W/0.9 Session-ID: 90210 Sequence-Number: 1 Content-Type: text/plain Quasi-jolly. [end] If an alternate "Reply-To" had been specified in James' initial SUB, the Request-URI in this message would be something other than the default "/". James must send a simple confirming response to this message (not shown). Now, because Susan has requested the "Consult" publishing-control option, she will receive an update asking her what to do with any current or new subscriptions. For example: [udp to dialup99.isp.net:2222 from whodp.w3.org:2222] UPD / W/0.9 Session-ID: 78705 Sequence-Number: 1 Subscriber: whodp://mood.activerse.com/james Publish-Via: Fulfill Redirect Consult [end] Susan's response to this message will determine how her home- INTERNET-DRAFT WhoDP [Page 32] server treats James' subscription going forward: "Fulfill" indicates continue to serve the subscription from the server; "Redirect" indicates that a redirection to a given location should occur; "Consult" means fulfill but continue to give notifications about this subscriber (such as when he stops subscribing). Let's assume Susan's current client configuration demands a redirect, so she sends the response: [udp to whodp.w3.org:2222 from dialup99.isp.net:2222] 200 OK Session-ID: 78705 Sequence-Number: 1 Publish-Via: Redirect Location: whodp://dialup99.isp.net/mood1 [end] Above we see that Susan's user-agent has specified a non-default redirection target: "whodp://dialup99.isp.net/mood1". Now, Susan's home-server must cancel James' existing subscription, redirecting him instead to the location Susan's program requested. It sends the following message on James' subscription: [udp to jim.activerse.com:2222 from whodp.w3.org:2222] UPD / W/0.9 Session-ID: 90210 Sequence-Number: 2 Refresh: 0 Location: whodp://dialup99.isp.net/mood1 [end] James' user-agent must confirm this message with a simple response (not shown), then reattempt subscribing at the suggested location: [udp to dialup99.isp.net:2222 from jim.activerse.com:2222] SUB /mood1 W/0.9 Subject: whodp://whodp.w3.org/susan Sender: whodp://mood.activerse.com/james Request-ID: Joy407 [end] Susan's user-agent would recognize this request for a direct subscription and grant the subscription with an appropriate response(not shown), including a content-entity reflecting Susan's current mood state -- which may be different than that reflected by her home server. If and when Susan's user-agent attempts to subscribe to James, its initial SUB to "whodp://mood.activerse.com/james" would be immediately redirected, with a 302 response, to the redirection target of James' publishing-control session: "whodp://jim.activerse.com/". INTERNET-DRAFT WhoDP [Page 33] 16. Issues 16.1 This Document Related protocol efforts like RVP and SGAP should be referenced. A future revision should describe specific headers and practices for negotiating a mutually acceptable authentication scheme. For clarity, future revisions should explicitly describe features and formats inherited from HTTP, rather than including them by reference. Additional HTTP headers and response status codes might be appropriate to bring over, in case they are needed -- especially for the GET and PUT methods. A number of headers are overloaded, used for disparate purposes, which may be confusing. For example, "Location" is used to tell servers where to send people, to tell people where to go, and to give a permanent new authoritative address (in 301 responses). "Publish-Via" is used both to list publishing options and to choose one option. For clarity, perhaps different uses of these headers should occur under different header names. The parameters for acceptable UDP retry policies may warrant further tuning for maximum network-friendliness. Further explanations and examples of the "Proxy" mode are needed, as is further clarification of the role and use of "Content-Domains. "References" section needs expansion. 16.2 For Future Versions Should TCP transport be available as an option, and if so, how should UDP & TCP transports be mixed? Should TCP be used only under certain conditions, or as a fallback? Can a single session use both transports? Can a single TCP connection be used for multiple messages -- both requests and responses -- in both directions? 17. Version Notes This is the first public version of the WhoDP specification. Currently shipping Activerse products use an earlier, undocumented version of WhoDP. Although closely related, that version uses different, sometimes binary request-line, response- line, and header formats, and several different message and header names to achieve similar effects. Also, the only publishing-control option in previous versions is "Relinquish", which is analogous to "Redirect" here. 18. References INTERNET-DRAFT WhoDP [Page 34] RFC 1123 Dates RFC 1738 URLs RFC 2068 HTTP/1.1 PEP XML 19. Author Contact and Discussion Info The author may be contacted at: Gordon Mohr Activerse, Inc. 1301 W. 25th St Suite 500 Austin, TX 78705 gojomo@activerse.com The author recommends discussing WhoDP via the discussion list established for discussing the "Rendezvous Protocol (RVP)" and related issues. For information, send a message with the body "info" to rvp-request@iastate.edu. To subscribe, send a message with the body "subscribe" to rvp-request@iastate.edu. 20. Expiration This document expires in October 1998.