On Fri, Nov 21, 2008 at 4:12 AM, Adam Roach <[EMAIL PROTECTED]> wrote: > 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?
absolutely - perhaps a resource hosted on a CDN, where you commonly can not send custom headers. or a blog, which may be hosted on some other platform (for example, blogger.com) where you can edit the HTML but not the headers. > 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). a client would not need to check the body unless it understood the content-type, and in the cases in SIP these would almost certainly not be HTML documents, so the client would not need to parse a HTML document for extracting a header. the Link header as defined in draft-notthingham-http-link-header itself is only a way of representing the <link> header in HTML and <atom:link/> header in atom entries outside of the content where it is not possible because the content-type does not have support. So it already "just works" by creating a link registry entry, however would be good to explicitly point out that it could be anywhere a link relation is allowed. > 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? yup! > The NOTIFY needs to be sent out immediately anyway, to satisfy RFC 3265 > procedures. of course it does - sorry ;) ~ Theo -- Theo Zourzouvillys Chief Technical Officer VoIP.co.uk - Commerce House, Telford Road, Bicester, OX26 4LD Tel: +44 1908 764 196 _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
