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

On 1/9/09 4:57 PM, Kris Zyp wrote:
> Is the intent of this mechanism to have each resource's monitor URI be
> different.

Yes.

> That, is if I have two separate URIs/resources, can they
> both share the same subscription/monitor URI, such that a client can
> connect to that same URI to track changes to both resources?

Not quite the way you describe, but this kind of subscription 
aggregation is always an option through the use of RFC 4662. The most 
recent version of the draft (-01) adds more explicit text around a 
couple of different ways to subscribe to multiple resources with a 
single subscription.

> If so,
> are there any proposed mechanism for how the subscriber declares to
> the subscription server which resources it wishes to monitor?

When aggregating resources in a single subscription, this is handled via 
the RFC 5367 "uri-list" mechanisms.

> Is this
> left up to the protocols used by the subscription servers? I would
> like to look at using this mechanism from our JavaScript library using
> "Comet"-style connections (long-lived connections to a server over
> HTTP awaiting an asynchronous response from the server with
> notifications), but within browser, connections are limited and one
> would need to be able to use a single connection for all subscriptions
> (for a given server). Also, it seems a prime target transport for this
> type of subscription mechanism would be with the WebSocket protocol
> that (the ID for that was recently distributed). It certainly seems
> that message/httpfrag messages could be delivered nicely with WebSockets.
>   

I'm not familiar enough with those technologies to have an informed 
opinion on how you would use them for subscribing. The document I'm 
putting together defines semantics for using SIP for the subscriptions, 
and leaves the question of how to perform such subscriptions with other 
protocols to be defined elsewhere.

> Also, I was curious if this approach leaves open the possibility that
> resource changes could be "missed" between the time that a
> client/subscriber receives a response from the server with a monitor
> link and the time it is able to connect to the monitor resource for
> tracking changes?

No -- the subscriber can compare the MD5 value and/or Etag in the NOTIFY 
with the MD5 value and/or Etag value in the HTTP response. If they 
match, it can be assured that the value of the resource has not change 
in the interim.

/a

Received on Friday, 9 January 2009 23:13:01 UTC