So just finished an afternoon reread of Ari Luotonen's book,
hadn't looked at it in a couple of years; also some material
online. I've *almost* convinced myself that HttpEvents as we are
currently discussing them are mostly extraneous. I'm going to
say some things about my understanding of the current very rough
but gradually converging consensus, then lay out the strawman for
why this approach is unnecessary. It's a straw man, whack away.

CURRENT CONSENSUS: An HttpEvents protocol could be any one of or
combination of things. It might be (1) simply a state-change
notification protocol, (2) a push-based state replication
protocol, or (3) a subscription / listener management protocol.
It appears that we are generally converging on (1), viewing (2)
as either an optimization or application-specific or both, and
(3) as interesting but somewhat out-of-scope for this spec. (We
are talking about reifying subscribers and subscriptions, but
pushing out "listener management" etc.)

Is that about right?

If so, then we may be spinning our wheels somewhat; various folks
did a fair bit of work on NOTIFY back in the early days [1] in
the context of proxy cache notification and in the course of the
HTTP-NG discussions. Not sure what the current state of NOTIFY
is; did it ever go anywhere? I apologize if there's an obvious
answer to this, as my own "cache" of HTTP caching-related
information is a bit stale. No mention of NOTIFY / this draft in
Ari's 1998 book, and very little I can find via Google.

BUT...

[1] describes a protocol extension (with a "new" method, NOTIFY)
that solves (1) in a very HTTPish way. It doesn't reify
subscriptions, but it doesn't have to --- it appears that
subscriptions are at-most-once commitments to notify the
subscriber that the state of a resource has changed, for the
purpose of cache invalidation. Renewal of the subscription
appears to happen incrementally --- the subscription "expires"
after the first notification, and is "renewed" on the subsequent
GET (if any) that happens to refresh the cache after the
notification is received.

The more I think about this, the more elegant it seems.

Here's how this protocol could be used to accomplish (1):

CLIENT -> SERVER
----------------------
GET /foo HTTP/1.1
Accept: text/html
Proxy-Features: my.host.com; notify

(Note that we're "pretending" to be our own proxy server cache.
We're requesting notification of state change on the resource if
it's available.)

SERVER -> CLIENT
---------------------
201 OK
Cache-Control: notify
Content-Type: text/html

...text...

(The SERVER responds and says, among other things, that it is
willing to notify (via the Cache-Control directive) the CLIENT
at-most-once (?) that the resource has changed by possibly
emitting a NOTIFY for that resource to the CLIENT at some later
date.)

Later on, when /foo changes, the SERVER initiates a connection
back to CLIENT (the machine specified in Proxy-Features:, i.e.
my.host.com) and sends notification that the state change
occurred / the cached copy (if any) has expired:

SERVER -> CLIENT
---------------------
NOTIFY /foo HTTP/1.1

(Presumably the fully-qualified URI is somehow reconstructed from
TCP connection data. This is gross and unworkable, so I would
assume that instead NOTIFY is required to provide a
fully-qualified URI.)

The client CLIENT proceed to refresh its cache via a GET. At
this point, the SERVER is presumably allowed to stop sending
further notifications; in order to receive the next
notification, the client parameterizes the GET so that it looks
just like the first one. This cycle repeats, ad infinitum, as
long as the CLIENT is interested in being updated about state
changes on SERVER/foo:

CLIENT -> SERVER
----------------------
GET /foo HTTP/1.1
Accept: text/html
Proxy-Features: my.host.com; notify

...lather, rinse, repeat...

DISCUSSION
--------------

PROS: This seems generally workable. It avoids issues with
management of subscriptions, etc. by its at-most-once
notification semantics. (It's at-most-once in that notifications
aren't guaranteed; the origin server may provide data to feed
cache age and freshness calculations, and the client / proxy must
use its own heuristics to determine whether to trust a cached
object in the absense of a notification.) The net effect is the
same as (1) in that clients receive state change notifications
for particular objects. *** It also partially addresses Lucas'
concern about state-leakage, in much the same manner that Lucas
suggested; a notification client need only support the NOTIFY
method. Responses to NOTIFY aren't described, but presumably a
reasonable set of responses could be specified so that extra
state isn't leaked in response to a NOTIFY. *** It also, as Alex
notes, avoids complications with overloading the semantics of
i.e. POST.

CONS: As noted in [1], any point-to-point notification protocol
suffers when there are a large number of parties interested in
receiving notifications; the draft explicitly states that
"clients should not attempt to use this facility as a matter of
course" for that reason. IMO, we're no better or worse off in
this regard with either [1] or HttpEvents as contemplated. There
are some problems with this draft, such as the lack of fully
qualifying the URI in the NOTIFY message --- how does the
notification client know what the notification relates to? Also,
the terminology is very proxy specific. It doesn't reify the
notion of a subscription, but given a one-shot semantics I'm not
sure this is necessary or even desirable. (!) :-/

TANGENTIAL ISSUES
------------------------

Most of the notification application scenarios I've been
contemplating are actually made simpler by simply recasting them
in terms of proxy cache invalidation and assuming something like
the above. This does *not* specify any state replication /
update by piggybacking the NOTIFY, nor does it address the issue
of fan-out. It also doesn't address the issue of proxy fan-out,
where a *request* to an intermediary needs to be fanned out to
multiple origin servers, but that's a completely different topic
and scenario.




[1] http://www.w3.org/TR/WD-proxy