Adam, Thanks for this initiative. One comment on the discussion below.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Adam Roach > Sent: 21 November 2008 04:12 > To: Theo Zourzouvillys > Cc: [email protected] > Subject: Re: [BLISS] [Fwd: I-D > Action:draft-roach-sip-http-subscribe-00.txt] > > 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. [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. John _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
