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.