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

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/