Re: [sip-http-events] HTTP Subscribe: Remaining Open Issue

[Adam Roach <[e-mail]>]

On 12/1/09 9:40 AM, Rifaat Shekh-Yusef wrote:
> 1. Section 3.2, Monitoring Multiple HTTP Resources
>
> I like the ability to monitor multiple resources, but I am not sure
> about the approach.
> I tend to agree with Salvatore's comments below.
>
> With services that have established a hierarchical and descriptive
> structure of URIs,
> the ability to monitor a group of resources by monitoring the parent
> resource would be the best solution.
>
> I am not suggesting that this approach should replace the existing RLS
> approach.
>
>    

This document is designed to be completely agnostic to the underlying 
application that is making use of HTTP. I think it would be reasonable 
for someone to define -- in another document -- the means by which one 
would apply it to specific applications (such as ones where there is an 
implicit relationship between URLs based on some external rules, like 
those described in draft-zourzouvillys-bliss-ach-http-api).

But I would not support adding this kind of application-specific 
functionality to the base SIP HTTP subscribe draft.

>   2. Section 5, Example Message Flow
>
> In step 9: is the body of the NOTIFY message, which has the HTTP 200 OK,
> really needed in this case?
>    

Yes, it is. Unless you communicate some content identifier (such as etag 
or content-md5), there are race conditions in which clients can think 
they have the most recent version of a document when, in fact, they don't.

/a