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

[Adam Roach <[e-mail]>]

I propose that we move further discussion of this to the SIP mailing list.

/a

On 1/1/09 10:52 PM, Mark Nottingham wrote:
> Hi Adam,
>
> Sorry for the holiday-induced delay.
>
> On 13/12/2008, at 11:08 AM, Adam Roach wrote:
>>
>>> * 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).
>
> I agree, and wasn't proposing that multiple discovery mechanisms be 
> called out (I see others drafts doing this and wince too); rather, 
> just that the door be left open for other ways to be used if someone 
> wants build on top of this in the future.
>
>
>>> * 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.
>
> I'm not sure enough of it to make a concrete proposal. I can 
> definitely see situations where the subscription lifetime varies 
> significantly, just wondering if it's better to use the expiry time as 
> a default, instead of baking in a (fairly arbitrary) number.
>
>
>>> * 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.
>
> Not message/http, application/http;
>> The application/http type can be used to enclose a pipeline of one or 
>> more HTTP request or response messages (not intermixed).
> I think this will work, provided that the status-line is mandatory. 
> Remember that a HEAD response is allowed to omit a body, so from the 
> purely syntactic standpoint, you should be OK if the body is missing. 
> However, see below.
>
>
>>> * 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.
>
> OK, that makes sense. Would you be comfortable making these 
> requirements a SHOULD (if they aren't already)?
>
>
>> [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"?
>
> Content-Location is probably more appropriate.
>
>
>>> * 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).
>
> OK. My concern is when the client does have a cached or otherwise 
> locally stored copy, and they need to combine it with a partial 
> response -- e.g., when the status code isn't present, or partial 
> headers are there, etc. This area is reasonably well-defined when used 
> inside of HTTP, but taken out of context, it doesn't hold up terribly 
> well. 
>
>
>>> * 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).
>
> I see. I didn't get that from reading the spec; my concerns were about 
> the more complex cases where people were trying to update headers and 
> bodies using the notifications (as above). 
>
> Perhaps the right thing to do is to have a very limited new media type 
> that communicates just a few things;
>  * URI (required)
>  * Content-MD5 (optional)
>  * ETag (optional)
>  * Last-Modified (optional)
>
> without the option for status-line, other headers or body, to avoid 
> the complexity. More advanced uses could use application/http (but you 
> wouldn't necessarily need to specify how to do this...)
>
> Conneg definitely makes things more complex. I think that it's 
> legitimate to say that a notification applies to all representations 
> of a resource, and that you can't selectively send notifications for a 
> particular representation. The only sticky part here is that if there 
> *are* multiple representations for a resource, it's important for the 
> server to keep which one it's using for the ETag and/or Content-MD5 
> straight. 
>
>
>> [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.
>
> Yes; see above.
>
> Cheers,
>
> --
> Mark Nottingham     http://www.mnot.net/
>

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