Thanks for your comments! A few responses inline. On 11/20/08 7:03 PM, Theo Zourzouvillys wrote:
It would be good to explicitly mention that you could also use a <link rel="monitor"/> element within <head> of an (X)HTML document, and <atom:link rel="monitor"/> within an atom entry element, too.
Very interesting proposals. Admittedly, for the use cases SIP is most interested in, the results are not typically HTML, but the idea of communicating these in the body may have merit. I'm curious about which use cases you have in mind -- do you imagine that there will be circumstances under which the HTTP server will have the ability to notify other nodes of changes, but not have the ability to include a Link: header?
I certainly want to accommodate all reasonable use cases; however, unless it enables use cases that would otherwise be impossible, I'm a bit concerned that having more than one way to get this information will lead to either increased implementation complexity (client will have to check both the headers and the body), or decreased interoperability (clients checking only the headers and not the body will fail to locate body-contained URIs).
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.
Does that satisfy the property you're proposing?
Also, The SUBSCRIBE should pass the ETag it received when it fetched the document, so there is no race condition between a GET/HEAD and the subscription being processed by the SIP server - if the ETag has already changed when the SUBSCRIBE is received, a NOTIFY can be sent out immediately.
The NOTIFY needs to be sent out immediately anyway, to satisfy RFC 3265 procedures.
/a _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
