On 11/26/08 8:41 AM, Elwell, John wrote:
...
-----Original Message-----
On Behalf Of Adam Roach
...
On 11/20/08 7:03 PM, Theo Zourzouvillys wrote:
...
One thing i have been thinking about is monitoring multiple HTTP
resources on the same (logical) server. In a number of places this
mechanism is useful, a number of subscriptions to the same server
would be common. It would be nice if there was a way of
being able to
collect a number of HTTP URI's and monitoring them all in one
subscribe, assuming they are all on the same server (Which could be
calculated somehow). My initial thoughts were along the line of
separating the SIP URI for monitoring and a document
identifier - then
allowing the SUBSCRIBE to contain the list of document identifiers
that you want monitoring (perhaps via an XML body).
I think you achieve approximately the same effect by applying
RFC 5367
to the event package described in the draft. There is a minor bit of
bootstrapping regarding the URI to send the RFC 5367 request
to, and the
draft should probably address this.
[JRE] RFC 5367 presumably has the advantage that the client doesn't need
to know whether the different resources are indeed on the same (logical
or physical) server.
I certainly wouldn't want to preclude that mode of operation, but it
does require a priori knowledge of a server that is willing to perform
subscription aggregation on your behalf. Sometimes you'll have that, but
sometimes you won't.
What I had in mind was returning an optional second URI in a Link:
header with a different relation ("monitor-group," perhaps?). This would
point indicate a URL that could be used for RFC 5367 functionality. A
client would gather up all the "monitor" URIs that have the same
"monitor-group" URI, and then subscribe to the "monitor-group" URI with
the list of desired "monitor" URIs in the SUBSCRIBE body.
That's probably not the best explanation -- I'll try to put something
more coherent together in the next version of the document.
/a
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
