Yeah, Rohit will fix this when he gets in. Meanwhile, I'll keep it
mirrored at
http://www.cs.caltech.edu/~adam/isen/draft-khare-notify-scenarios-01.txt
Also, a quick question to anyone on FoRK with a little time to read.
We'd really like comments on section 4.3 and section 5.1.3, included
below. Hopefully we'll get some feedback from folks on the public
notify mailing list as well...
> ...
>
> 4.3 "Web Notifications" as a Working Group Strategy
>
> Having set the scene of the possible design space for ISENS, and
> probable users of ISENS, we must extract a plausible intersection of the
> two to move forward. We believe the most persuasive common interest is
> both A) in notification delivery in the form of HTTP messages and B) for
> events affecting HTTP resources.
>
> In particular, there is a large class of applications that already
> detects event occurrences by monitoring Web resources: link maintenance,
> price quotes, package-tracking, and so on. It seems desirable now to
> allow any application that used to poll an event source to now subscribe
> to {Some Set of Methods} X {Some Collection of Resources} and be
> notified immediately whenever information of interest is generated. For
> example, when used with the WebDAV extensions, notifications can
> communicate resource deletions, link modifications, and propertychanges.
>
> The HTTP resource model has proven so sufficiently flexible -- large
> messages and small, immediate and deferred, for humans or machines --
> that it seems likely that many current applications can be "ported" to
> this ENS base. News distribution, presence, conferencing, distributed
> simulations, and tool integration could all proceed to some degree over
> an "instant page" infrastructure.
>
> A cleanly designed HTTP interface should be able to layer on advanced
> capabilities such as intermediated (relayed) delivery and
> event-coalescing functions such as aggregating and filtering. And, as we
> later describe in Section 5.1.3, notification management could also
> proceed over an extensible HTTP interface.
>
> ...
>
> 5.1.3 HTTP + Callbacks
>
> On the surface, HTTP/1.1 [Fielding et al., 1997] seems an unlikely ENS.
> It seems exclusively adapted to low-latency, sink-initiated, end-to-end,
> reliable delivery on a one-to-one basis. There are two relevant features
> that widen its range, however. First, its syntax already affords
> relaying a request and response along a chain of proxy servers (and to
> short-circuit it using a cached response). Second, it is possible (and
> practical) to have both an HTTP client and server at any node on
> theInternet.
>
> At each step in the resolution of an HTTP resource, a request can be
> directed to the origin server, or to a proxy for that resource [Khare
> and Rifkin, 1998]. As currently defined, though, HTTP's semantics are
> serialized and end-to-end (synchronous); even caching is merely an
> approximation of reaching the origin server. An HTTP ENS would make it
> possible to snip this constraint, allowing a client to make a request of
> a resource at one server, and be notified of its reply from another aday
> later.
>
> As defined, HTTP/1.1 proxying already allows intermediation. Proxies can
> aggregate and filter event streams. Caching properties like ETags and
> expiry times can be used judiciously to "cross-post" event notices under
> several topic addresses, and to keep recent notifications available for
> subsequent sink requestors. Wide-area notifications might be
> prepositioned by NNTP-like delivery to a network of Web proxies.
>
> An HTTP server, upon observing an event, can also take advantage of HTTP
> to deliver a notification to a list of listeners. By implementing HTTP
> servers at "client" nodes, the event source can initate delivery as an
> HTTP request (firewall permitting); that is the approach behind GENA's
> NOTIFY method [Aggarwal and Cohen, 1998]. However, rather than cloak a
> response within an HTTP request, it would be cleaner to initiate
> delivery of an HTTP response message, but that would require a
> reinterpretation of HTTP/1.1's flowchart.
>
> In any case, it makes some sense to use HTTP-formatted messages for
> communication in both directions. Other protocols cannot be so easily
> implemented in both roles. E-mail, for example, really argues against
> routing to a "Mail Transfer Agent (MTA) on every desk" and for a handful
> of mail servers instead. Bidirectional HTTP traffic may also be the most
> principled approach to firewall traversal, too.
>
> Furthermore, a human- and machine-readable notification management
> interface can be published over HTTP. Distribution lists can be
> represented as HTTP resources, with subscription operations as HTTP
> methods. Event types and channels can be advertised (and indexed) as
> HTTP resources. Access controls on all of the above can be implemented
> with existing HTTP headers.
>
> Note: Some have proposed an unreliable transport for HTTP; see our
> caveats for unreliable transport in Section 3.4. For some idempotent
> requests leading to a 204 No Content reply, it might make sense to
> define a responseless form of operation -- or to fill a cache, say, with
> spontaneous (requestless) 200 responses. In those cases, we could
> further define a UDP transport -- for sufficiently small messages whose
> losses would be acceptable (in applications for which these losses do
> not alter the runtime semantics).
FYI, the [Fielding et al., 1997] reference is to the HTTP/1.1 spec
ftp://ftp.isi.edu/in-notes/rfc2068.txt
and the [Khare and Rifkin, 1998] reference is to our Monterey paper on
composing active proxies
http://www.cs.caltech.edu/~adam/papers/csa98b.html
and the [Aggarwal and Cohen, 1998] reference is to GENA Base
http://www.ietf.org/internet-drafts/draft-cohen-gena-p-base-01.txt
----
adam@cs.caltech.edu
An object model and technology that a) runs over HTTP, b) allows methods
to be written in multiple programming and scripting languages, c)
storage of the state and behavior independently at different places
around the net, d) dyanmic switching, declaration, polymorphism,
inheritance, e) decentralized tracking, control, versioning,
composition, f) lightweight and componentized, g) fail-safe, h) fast, i)
embedded, built-in networking, j) embedded built-in access control, k)
reflexive, i.e. has the means to reason about itself and adapt,
including distributed annotation and rationale, including adaptive
interaces i) mobile, l) better than having sex in the backseat of an
Abrahm's Battle tank, i.e. better than f-ing with than CORBA.
-- what Greg Bolcer wanted last Christmas,
http://xent.ics.uci.edu/FoRK-archive/oct97/0825.html