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

From: "Theo Zourzouvillys" <[email-masked]>
Date: Thu, 11 Dec 2008 05:59:30 +0000

On Thu, Dec 11, 2008 at 5:48 AM, Mark Nottingham <[email-masked]> wrote:

>> 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.

Nope, I was just trying to point out - all be it with some rather
awful grammar - that when a new link type is defined, it can be used
in any of the places links can be used; i.e, in <head>, <atom:link/>,
or Link header (or draft-nottingham-site-meta).

 ~ 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-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: "Theo Zourzouvillys" <[email-masked]>
Date: Thu, 11 Dec 2008 06:14:27 +0000

On Thu, Dec 11, 2008 at 5:57 AM, Mark Nottingham <[email-masked]> wrote:

> * Conversely, if you are you intent on allowing transfer of an entity with a
> notification, you may want to consider allowing the transfer of multiple
> entities, to allow the use of content negotiation (e.g., both an English and
> French representation under the same URI, or a png and a gif).
> application/http would support this.

Although in our own implementation of this internally we transfer a
diff of the body that changes, we're currently only using it for XML
files.  After reading this in relation to something more substantial
like an image, the thought of transferring potentially unbounded
amounts of data for an entity representation in a single SIP
notification scares me - that's what we have HTTP for!

 ~ Theo

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Dec 2008 16:48:48 +1100

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 <[email-masked]> 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.
>

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/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Dec 2008 16:57:44 +1100

Three more;

* Does the NOTIFY message include the URI of the resource that has  
changed (didn't see it, but I may be missing something). It should be  
added if not; otherwise, you're baking in a one-to-one relationship  
between monitoring channels and http URIs. There will be use cases  
where the receiver of the NOTIFY doesn't have enough context to  
associate the message body you're sending with a URI.

* The simplest and most efficient notification message to send is  
"this resource has changed"; the client can then decide whether or not  
to fetch an update, and combining any old response with a new one is  
simple. It also assures that the subscribing client isn't required to  
implement a cache. I would very much encourage you to support this  
mode of interaction.

* Conversely, if you are you intent on allowing transfer of an entity  
with a notification, you may want to consider allowing the transfer of  
multiple entities, to allow the use of content negotiation (e.g., both  
an English and French representation under the same URI, or a png and  
a gif). application/http would support this.

Cheers,

On 11/12/2008, at 4:48 PM, Mark Nottingham wrote:

> servers may want to be selective about when they offer monitoring,  
> and there may be other ways to advertise it that are more appropriate.
>
> allow you to advertise a monitoring endpoint for your whole site,  
> for example.
>
> (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...
>
> 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.
>
> 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.
>
>>> <atom:link/> header in atom entries outside of the content where  
>>> it is
> 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,
>
>
> --

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Dec 2008 17:01:59 +1100

Ah - got it.  Yes, that's the intent, and hopefully more places besides.

Cheers,

On 11/12/2008, at 4:59 PM, Theo Zourzouvillys wrote:

>> people

---

From: Adam Roach <[email-masked]>
Date: Fri, 12 Dec 2008 18:08:21 -0600

Mark:

Thank you very much for taking the time to look over the draft. 
Responses inline.

/a

> there may be other ways to advertise it that are more appropriate.

It was certainly intended to be subject to policy -- I'll rephrase the 
predicate to make this clearer.

> headers one use of them.

I understand what you're saying, but I'm somewhat sensitive to having 
many optional ways of doing the same thing in the same protocol. In my 
experience, you either end up with everyone supporting every way of 
doing things (driving up implementation costs), or with people selecting 
only their favorite mechanisms (driving down interoperability). There 
is, of course, an unhappy medium between those two extremes, in which 
you get both an increase in implementation complexity and a decrease in 
interoperability (albeit to a lesser degree).

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

That is what I meant. I'll attempt to clarify.

> response (as defined by HTTP)?

I'm not sure. The goal behind selecting subscription durations is to 
balance server load against time to recover in the case of a failure. If 
you want to propose a concrete formula, I'll be happy to incorporate it 
into the document, but I think it is of limited value.

> clearer if it were required...

I'm hardly an HTTP expert -- so, on first glance, I feared that re-using 
message/http would run afoul of semantic restrictions associated with 
that content type (in the same way that omitting critical header fields 
from a SIP message would make it invalid; that is what drove development 
of the message/sipfrag content type).

If you think that re-use of message/http is kosher in this context, then 
I'd be quite pleased to use that instead of defining a new content-type. 
I strongly prefer re-use over re-invention.

The optional status-line feature was copied from message/sipfrag. It has 
little value here, so I'm happy to make status lines mandatory.

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

Philosophically: SIP Events, in general, reports the state of a 
resource, not events that change its state (despite its name, which I 
have grown to regret). It is true that state is usefully reported when 
it changes, but thinking about it as the changes themselves instead of 
the resultant state tends to put the cart before the horse.

Practically: without some means of tying the notification to the 
resultant HTTP document, you end up with race conditions in which the 
state of a document changes between retrieval and subscription to its 
state. There are other ways to solve this race, but they're messy.

ETag and Content-MD5 form positive identifiers that the subscribing 
party is able to associate with the resource when they retrieve it in 
the first place. Content-MD5 has the benefit that it can be calculated 
from a locally-cached value. Systems that are already using ETags for 
other purposes can leverage the fact that they are already storing that 
value with the resource.

The inclusion of Last-Modified had an appeal to me for optimizing 
use-cases like this: I have a file on my file system that I know was 
retrieved from a particular HTTP URL. The filesystem has a timestamp 
associated with the file that represents the time it was downloaded. I 
can compare this against the Last-Modified value much more cheaply than 
I can generate an MD5 hash of its contents and compare that against the 
Content-MD5. (Compare this behavior with the handling of the -N flag in 
wget).

> because this is the granularity of time in HTTP.

Thanks.

[from a later message]

> associate the message body you're sending with a URI.

Good point. How would you feel about adding a requirement to include a 
"Link" header in the message/http body with a relation type of "self"?

> implement a cache. I would very much encourage you to support this 

That is effectively what I'm trying to do; however, see my notes above 
about race conditions. If a client doesn't want to cache anything, they 
can simply treat each NOTIFY message as an indication that the resource 
has (likely) changed. (They would still be well off keeping track of the 
Content-MD5 and/or ETag for the brief period between the HTTP operation 
and the SIP subscription just to make sure the resource didn't change 
between those steps).

> a gif). application/http would support this.

I'm ambivalent about allowing the inclusion of bodies in the 
notifications. I would hesitate precluding future specifications from 
doing so, but I'm not all that interested in developing a complicated 
mechanism in this document that replicates the full set of HTTP features 
(such as language and content negotiation).

[responses to previous messages in thread]

> ...

I'll reiterate my concerns about too many ways to do something. I'm 
adding in the <link> and <atom:link/> mechanisms, but I'd hate to see an 
explosion of mechanisms here, as it would make client implementations 
untenably complicated.

/a