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

From: Mark Nottingham <[email-masked]>
Date: Thu, 1 Jan 2009 23:52:32 -0500

FYI; I've been discussing it a bit with them over on the bliss list.

Begin forwarded message:

> From: [email-masked]
> Date: 21 November 2008 8:15:01 AM
> To: [email-masked]
> Subject: I-D Action:draft-roach-sip-http-subscribe-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : A SIP Event Package for Subscribing to Changes to  
> an HTTP Resource
> 	Author(s)       : A. Roach
> 	Filename        : draft-roach-sip-http-subscribe-00.txt
> 	Pages           : 12
> 	Date            : 2008-11-20
>
> The Session Initiation Protocol (SIP) is increasingly being used in
> systems that are tightly coupled with Hypertext Transport Protocol
> (HTTP) servers for a variety of reasons.  In many of these cases,
> applications can benefit from being able to discover, in near-real-
> time, when a specific HTTP resource is created, changed, or deleted.
> This document proposes a mechanism, based on the SIP events
> framework, for doing so.
>
> This document further proposes that the HTTP work necessary to make
> such a mechanism work be extensible to support protocols other than
> SIP for monitoring HTTP resources.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-roach-sip-http-subscribe-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--
Mark Nottingham     http://www.mnot.net/

---

From: Kris Zyp <[email-masked]>
Date: Fri, 09 Jan 2009 15:57:37 -0700

I have some questions about this proposal, that might be due to my
lack of understanding of the context. I am not sure if you intended
questions to be raised on this group, so please point in the right
direction if it's the wrong place:
Is the intent of this mechanism to have each resource's monitor URI be
different. 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? If so,
are there any proposed mechanism for how the subscriber declares to
the subscription server which resources it wishes to monitor? 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.

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? Is there any way to ensure that all changes are
received, even in this window. We have worked on an HTTP-semantics
based notification system, and we included the subscription request
within the HTTP request so that the subscription and the HTTP response
would leave no window for missing notifications.

Thanks,
Kris

Mark Nottingham wrote:
>>     Title           : A SIP Event Package for Subscribing to
>> Changes to an HTTP Resource
>>     Author(s)       : A. Roach

- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com

---

From: Adam Roach <[email-masked]>
Date: Fri, 09 Jan 2009 17:12:23 -0600

On 1/9/09 4:57 PM, Kris Zyp wrote:
> different.

Yes.

> That, is if I have two separate URIs/resources, can they
> 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,
> 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

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.

> 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