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

From: Adam Roach <[email-masked]>
Date: Thu, 20 Nov 2008 17:18:44 -0600

Based on the discussions we had in BLISS earlier this week, I have put 
together a strawman proposal for a SIP event package to subscribe to the 
state of an HTTP resource. Any feedback you have is welcome.

http://www.ietf.org/internet-drafts/draft-roach-sip-http-subscribe-00.txt

/a

Subject: I-D Action:draft-roach-sip-http-subscribe-00.txt
From: [email-masked]
To: [email-masked]
Date: Thu, 20 Nov 2008 13:15:01 -0800 (PST)
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

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
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: "Theo Zourzouvillys" <[email-masked]>
Date: Fri, 21 Nov 2008 01:03:50 +0000

2008/11/20 Adam Roach <[email-masked]>:
> Any feedback you have is welcome.

Adam,

It's great to see work on this.  After a quick glance over the
document, a few comments:

It would be good to explicitly mention that you could also use a <link
rel="monitor"/> element within <head> of an (X)HTML document, and
<atom:link rel="monitor"/> within an atom entry element, too.

One thing i have been thinking about is monitoring multiple HTTP
resources on the same (logical) server.  In a number of places this
mechanism is useful, a number of subscriptions to the same server
would be common.  It would be nice if there was a way of being able to
collect a number of HTTP URI's and monitoring them all in one
subscribe, assuming they are all on the same server (Which could be
calculated somehow).  My initial thoughts were along the line of
separating the SIP URI for monitoring and a document identifier - then
allowing the SUBSCRIBE to contain the list of document identifiers
that you want monitoring (perhaps via an XML body).

Also, The SUBSCRIBE should pass the ETag it received when it fetched
the document, so there is no race condition between a GET/HEAD and the
subscription being processed by the SIP server - if the ETag has
already changed when the SUBSCRIBE is received, a NOTIFY can be sent
out immediately.

 ~ Theo

-- 
Theo Zourzouvillys
Chief Technical Officer
VoIP.co.uk - Commerce House, Telford Road, Bicester, OX26 4LD
Tel: +44 1908 764 196
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Adam Roach <[email-masked]>
Date: Thu, 20 Nov 2008 22:12:11 -0600

Thanks for your comments! A few responses inline.

> <atom:link rel="monitor"/> within an atom entry element, too.

Very interesting proposals. Admittedly, for the use cases SIP is most 
interested in, the results are not typically HTML, but the idea of 
communicating these in the body may have merit. I'm curious about which 
use cases you have in mind -- do you imagine that there will be 
circumstances under which the HTTP server will have the ability to 
notify other nodes of changes, but not have the ability to include a 
Link: header?

I certainly want to accommodate all reasonable use cases; however, 
unless it enables use cases that would otherwise be impossible, I'm a 
bit concerned that having more than one way to get this information will 
lead to either increased implementation complexity (client will have to 
check both the headers and the body), or decreased interoperability 
(clients checking only the headers and not the body will fail to locate 
body-contained URIs).

> that you want monitoring (perhaps via an XML body).

I think you achieve approximately the same effect by applying RFC 5367 
to the event package described in the draft. There is a minor bit of 
bootstrapping regarding the URI to send the RFC 5367 request to, and the 
draft should probably address this.

Does that satisfy the property you're proposing?
> already changed when the SUBSCRIBE is received, a NOTIFY can be sent

The NOTIFY needs to be sent out immediately anyway, to satisfy RFC 3265 
procedures.

/a

---

From: "Theo Zourzouvillys" <[email-masked]>
Date: Fri, 21 Nov 2008 08:07:25 +0000

On Fri, Nov 21, 2008 at 4:12 AM, Adam Roach <[email-masked]> wrote:
> communicating these in the body may have merit. I'm curious about which use
> cases you have in mind -- do you imagine that there will be circumstances
> under which the HTTP server will have the ability to notify other nodes of
> changes, but not have the ability to include a Link: header?

absolutely - perhaps a resource hosted on a CDN, where you commonly
can not send custom headers.

or a blog, which may be hosted on some other platform (for example,
blogger.com) where you can edit the HTML but not the headers.

> I certainly want to accommodate all reasonable use cases; however, unless it
> enables use cases that would otherwise be impossible, I'm a bit concerned
> that having more than one way to get this information will lead to either
> increased implementation complexity (client will have to check both the
> headers and the body), or decreased interoperability (clients checking only
> the headers and not the body will fail to locate body-contained URIs).

a client would not need to check the body unless it understood the
content-type, and in the cases in SIP these would almost certainly not
be HTML documents, so the client would not need to parse a HTML
document for extracting a header.

the Link header as defined in draft-notthingham-http-link-header
itself is only a way of representing the <link> header in HTML and
<atom:link/> header in atom entries outside of the content where it is
not possible because the content-type does not have support.  So it
already "just works" by creating a link registry entry, however would
be good to explicitly point out that it could be anywhere a link
relation is allowed.

> I think you achieve approximately the same effect by applying RFC 5367 to
> the event package described in the draft. There is a minor bit of

yup!

> The NOTIFY needs to be sent out immediately anyway, to satisfy RFC 3265

of course it does - sorry ;)

 ~ Theo

---

From: Adam Roach <[email-masked]>
Date: Fri, 21 Nov 2008 09:53:57 -0600

> blogger.com) where you can edit the HTML but not the headers.

I understand the difficulty in putting new HTTP headers into responses 
under such circumstances... but I also don't understand how you'll 
provide notification of changes under such circumstances either. Do you 
envision that people publishing via a CDN or a blog will turn around and 
manually kick a SIP server to cause it to send notifications?

The issue I'm having is that it seems a bit contrived that anyone 
publishing under the relatively constrained circumstances you describe 
will nonetheless have access to a SIP events server that provides 
notification for such changes -- but that could just be a lack of 
imagination on my part. Can you expand your use-case to tell a story 
about where these people are getting their SIP event servers (are they 
hosted?) and how the SIP event server finds out about changes to the 
HTTP server.

> be good to explicitly point out that it could be anywhere a link

That's interesting -- Mark, do you have any input on the topic?

/a

---

From: "Theo Zourzouvillys" <[email-masked]>
Date: Fri, 21 Nov 2008 16:21:06 +0000

On Fri, Nov 21, 2008 at 3:53 PM, Adam Roach <[email-masked]> wrote:

> I understand the difficulty in putting new HTTP headers into responses under
> such circumstances... but I also don't understand how you'll provide
> notification of changes under such circumstances either. Do you envision
> that people publishing via a CDN or a blog will turn around and manually
> kick a SIP server to cause it to send notifications?

probably not manually (i.e by clicking a button), but through an event
triggered causing a HTTP POST by the application or some other event
to the SIP monitoring server, which then does it's thing and notify
everyone monitoring it.

> The issue I'm having is that it seems a bit contrived that anyone publishing
> under the relatively constrained circumstances you describe will nonetheless
> have access to a SIP events server that provides notification for such
> changes -- but that could just be a lack of imagination on my part. Can you
> expand your use-case to tell a story about where these people are getting
> their SIP event servers (are they hosted?) and how the SIP event server
> finds out about changes to the HTTP server.

sure - a SIP service provider who provide a scalable monitoring
service.  for a user to use it, they embed a <link rel="monitor"/> tag
with the correct SIP URI for this document into the HTML (similar to
how you include google's urchin for analytics), then push the document
into a CDN.  The SIP monitoring server can then either be informed via
a simple API call (HTTP POST, perhaps) provided by whatever
application is pushing the document into the CDN, or the service
provider monitor the document regularly (using ETag semantics), and
when it finds a change notify all the watchers.

a domain specific app - for example windows live writer - could add
support for allowing monitoring without whoever is hosting the
resources itself supporting custom headers and having a co-hosted SIP
server.

 ~ Theo

---

From: Adam Roach <[email-masked]>
Date: Fri, 21 Nov 2008 10:23:22 -0600

> resources itself supporting custom headers and having a co-hosted SIP

Okay. That seems reasonable. I'll work the <link/> stuff into the next 
draft.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 26 Nov 2008 14:41:28 +0000

Adam,

Thanks for this initiative. One comment on the discussion below. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Adam Roach
> Sent: 21 November 2008 04:12
> To: Theo Zourzouvillys
> Cc: [email-masked]
> Subject: Re: [BLISS] [Fwd: I-D 
> Action:draft-roach-sip-http-subscribe-00.txt]
> 
[JRE] RFC 5367 presumably has the advantage that the client doesn't need
to know whether the different resources are indeed on the same (logical
or physical) server.

John

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Nov 2008 13:32:23 -0600

On 11/26/08 8:41 AM, Elwell, John wrote:
> ...
>> ...
>> ...
>>> would be common.  It would be nice if there was a way of 
>>>       
>> being able to
>>     
>>> separating the SIP URI for monitoring and a document 
>>>       
>> identifier - then
>>     

I certainly wouldn't want to preclude that mode of operation, but it 
does require a priori knowledge of a server that is willing to perform 
subscription aggregation on your behalf. Sometimes you'll have that, but 
sometimes you won't.

What I had in mind was returning an optional second URI in a Link: 
header with a different relation ("monitor-group," perhaps?). This would 
point indicate a URL that could be used for RFC 5367 functionality. A 
client would gather up all the "monitor" URIs that have the same 
"monitor-group" URI, and then subscribe to the "monitor-group" URI with 
the list of desired "monitor" URIs in the SUBSCRIBE body.

That's probably not the best explanation -- I'll try to put something 
more coherent together in the next version of the document.

/a