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

[Adam Roach <[e-mail]>]

Mark:

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

/a

On 12/10/08 11:48 PM, Mark Nottingham wrote:
> * "...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.

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

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

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.

> * 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)?

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.

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

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

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

Thanks.

[from a later message]

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

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"?

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

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

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

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]

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

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
_______________________________________________
BLISS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bliss