Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http-subscribe-00.txt]

[Mark Nottingham <[e-mail]>]

Sorry for the delay, finally off the road and had a chance to read.

Overall I like this document a lot, and I think it should be easy to  
align its use of the 'monitor' link relation with the Atom-over-HTTP  
protocol described in draft-nottingham-http-cache-channels.

A couple of comments / concerns:

* "...it MUST return a Link: header..." seems like it's too strong;  
servers may want to be selective about when they offer monitoring, and  
there may be other ways to advertise it that are more appropriate.

* Following on that thought, the idea behind the most recent Link  
draft is to talk about link relations generically, and make Link  
headers one use of them. Another use of them is in draft-nottingham- 
site-meta (which is still under pretty active revision); this would  
allow you to advertise a monitoring endpoint for your whole site, for  
example.

* "It MAY return both." is ambiguous; think you mean SIP + SIPS.

* 3.4 Subscription Duration -- just a thought, is it worth tying the  
default subscription duration to the freshness lifetime of the HTTP  
response (as defined by HTTP)?

* 3.5.1 message/httpfrag -- did you consider using application/http  
(defined in RFC2616)? I mention this because HTTP already defines how  
to update a cache entry's headers based upon a HEAD or 304 response;  
it would be nice to reuse that if possible. Also, what does making the  
status-line optional bring? The semantics of the message would be  
clearer if it were required...

* 3.5.2 - Why require an ETag or Content-MD5? Why recommend a Last- 
Modified?

* 3.10 - limiting notifications to one a second makes sense also  
because this is the granularity of time in HTTP.

Specific responses below;


On 22/11/2008, at 2:53 AM, Adam Roach wrote:
> On 11/21/08 2:07 AM, Theo Zourzouvillys wrote:
>> On Fri, Nov 21, 2008 at 4:12 AM, Adam Roach <[e-mail]> 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.

You certainly can, in a cache-driven CDN (e.g., Akamai); the cases  
where you can't aren't really CDNs as the industry understands them,  
they're Web hosting farms (because they use replication; e.g.,  
Amazon's new service, if I read it correctly). In that case, providing  
a channel without coordination with them can be harmful, because you  
can get into race conditions where you send the notification before  
the content is fully replicated.

More to the point, if you're using a CDN (of either type), the most  
likely value-add scenarios are using a monitoring channel to notify  
the CDN itself of changes, and also the CDN providing a monitoring  
server as a service.


>> 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'm getting somewhat exasperated at how often this argument comes up  
in specification discussions; to date mostly at the W3C. If we follow  
it to its conclusion, the only Internet protocols that we can develop  
are those that work with free hosting sites that only provide FTP  
access. Surely the Internet and the Web shouldn't be held hostage to  
them.

That said, I agree that the draft shouldn't preclude other discovery  
mechanisms, as mentioned above.

>> 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.
>
> That's interesting -- Mark, do you have any input on the topic?

I'm having trouble parsing the above -- is the concern that some  
people might believe that any link in the headers *has* to be mirrored  
in the content? If so, that's the first time I've heard this brought  
up, and it certainly isn't the intent. We can clarify if necessary.

Cheers,


--
Mark Nottingham     http://www.mnot.net/

_______________________________________________
BLISS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bliss