Subject: [dispatch] SIP HTTP Event Package [Fwd: New Version Notification for draft-roach-sip-http-subscribe-02]

From: Adam Roach <[email-masked]>
Date: Tue, 07 Jul 2009 14:47:46 -0500

I've just submitted a new version of draft-roach-sip-http-subscribe, 
which addresses a couple of minor comments made regarding -01 [1]. I 
know there are use cases coming out of the BLISS working group that 
would benefit from such a mechanism. I suspect it has a potential 
community of interest beyond that single working group, which is why I'm 
bringing it to DISPATCH.

I'm happy to keep working on the document as long as there is enough 
interest to make the work worthwhile. If we were to form a mailing list 
with the goal of making progress on this work, who would be interested 
in joining?

/a

[1] The only substantive change was in the third paragraph of section 
2.2, which now requires the server to indicate which URIs are causing it 
to forbid a subscription.

Subject: New Version Notification for draft-roach-sip-http-subscribe-02
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Date: Tue, 7 Jul 2009 12:26:36 -0700 (PDT)

A new version of I-D, draft-roach-sip-http-subscribe-02.txt has been successfuly submitted by Adam Roach and posted to the IETF repository.

Filename:	 draft-roach-sip-http-subscribe
Revision:	 02
Title:		 A SIP Event Package for Subscribing to Changes to an HTTP Resource
Creation_date:	 2009-07-07
WG ID:		 Independent Submission
Number_of_pages: 12

Abstract:
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.

The IETF Secretariat.

---

From: Michael Procter <[email-masked]>
Date: Tue, 7 Jul 2009 22:32:36 +0100

2009/7/7 Adam Roach <[email-masked]>:
> interest to make the work worthwhile. If we were to form a mailing list with
> the goal of making progress on this work, who would be interested in
> joining?
>

I'd be interested in joining.  I think there are a number of
interesting things that can be done with a package like this, and I
would be happy to help it progress.  This draft seems to be a
fundamentally useful building block for making advanced applications,
yet remains small enough in scope and application-agnostic to mean we
should be able to achieve consensus relatively quickly.

Michael

---

From: Theo Zourzouvillys <[email-masked]>
Date: Wed, 8 Jul 2009 00:08:36 +0100

> the goal of making progress on this work, who would be interested in

I would absolutely be interested, and really would like to see this
work progress.

 ~ Theo

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 09 Jul 2009 08:14:32 +0100

Adam,

I am interested because of the existing BLISS use cases, but I am sure
there will be other uses. It seems that having this event package
available could save the effort of writing more specific SIP event
packages in certain cases.

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 07 July 2009 20:48
> To: IETF Dispatch
> Subject: [dispatch] SIP HTTP Event Package [Fwd: New Version 
> Notificationfor draft-roach-sip-http-subscribe-02]
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 9 Jul 2009 19:15:26 -0500

Count me in. 

> Sent: Tuesday, July 07, 2009 12:48
> To: IETF Dispatch
> I've just submitted a new version of 
> draft-roach-sip-http-subscribe, which addresses a couple of 
> minor comments made regarding -01 [1]. I know there are use 
> cases coming out of the BLISS working group that would 
> benefit from such a mechanism. I suspect it has a potential 
> community of interest beyond that single working group, which 
> is why I'm bringing it to DISPATCH.
> 
> I'm happy to keep working on the document as long as there is 
> enough interest to make the work worthwhile. If we were to 
> form a mailing list with the goal of making progress on this 
> work, who would be interested in joining?
> 
> /a
> 
>

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 10 Jul 2009 11:41:26 +0300

Hi Adam,

I'd be interested in joining, but to discuss and decide about the real 
need of this package.

I would understand better:
- the advantage of having a SIP Event Package to monitor the changes in 
an HTTP resource ;
  (by the way the draft doesn't explain how it would be possible monitor 
the "creation" or the "deletion" of
   an HTTP resource!)

versus

-using directly the HTTP long-polling techniques that can perform at 
same time the monitoring
and the content transfer of HTTP resources.
(for an overview of the HTTP long-polling techniques check:   
http://www.ietf.org/internet-drafts/draft-loreto-http-bidirectional-00.txt )

thanks
Sal

Adam Roach wrote:
> community of interest beyond that single working group, which is why 
> I'm bringing it to DISPATCH.
>
> interest to make the work worthwhile. If we were to form a mailing 
> list with the goal of making progress on this work, who would be 
> interested in joining?
>
> /a
>
>
> 2.2, which now requires the server to indicate which URIs are causing 
> it to forbid a subscription.
>
> ------------------------------------------------------------------------
>
> Subject:
> New Version Notification for draft-roach-sip-http-subscribe-02
> From:
> IETF I-D Submission Tool <[email-masked]>
> Date:
> To:
> [email-masked]
> To:
> [email-masked]
> ------------------------------------------------------------------------
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Theo Zourzouvillys <[email-masked]>
Date: Fri, 10 Jul 2009 14:17:09 +0100

On Fri, Jul 10, 2009 at 9:41 AM, Salvatore
Loreto<[email-masked]> wrote:

> - the advantage of having a SIP Event Package to monitor the changes in an
> HTTP resource ;
>  (by the way the draft doesn't explain how it would be possible monitor the
> "creation" or the "deletion" of
>  an HTTP resource!)

see the last paragraph in 3.5.1 for deletion...

> -using directly the HTTP long-polling techniques that can perform at same
> time the monitoring

This would require the connection between the notifier and the server
to stay open.  When a single client is monitoring tens of thousands of
resources potentially over as many servers, this becomes very
unfriendly.  Consider that the period between a SUBSCRIBE and being
notified of changes could potentially be days.  Additionally,
monitoring can be done by millions of clients to a single server -
each of which would need an open connection to the server(s).

 ~ Theo

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 10 Jul 2009 16:41:10 +0300

don't take me wrong, I am just thinking about the pro and cons...
in line!

> see the last paragraph in 3.5.1 for deletion...
right!
but then what about "creation" ?
> to stay open.
right a point in favour of the Event package is that SIP goes over UDP
>   When a single client is monitoring tens of thousands of
> unfriendly.  
How to monitoring more resources on the same server is something that 
people are starting to think
also for web-application using HTTP.
> Consider that the period between a SUBSCRIBE and being
> notified of changes could potentially be days.
right, but then you have refresh the SUBSCRIBE... etc etc.
>   Additionally,
that is not a real problem, with HTML5 and the growing number of web 
applications a Server (a Web Server in this case)
will end up in exactly the same scenario.

---

From: Theo Zourzouvillys <[email-masked]>
Date: Fri, 10 Jul 2009 15:04:16 +0100

> but then what about "creation" ?

Sorry, i missed that bit :-)

My understanding (and how we implement it) is server could return a
Link header in a 404 response in the same way as a 200, which can then
be monitored.  Of course, servers may elect not to return a Link
header for the 404, or could reject the SUBSCRIBE request as received
if they don't support monitoring of non-existent resources.

> right a point in favour of the Event package is that SIP goes over UDP

or one connection for many clients on the same proxy.

> right, but then you have refresh the SUBSCRIBE... etc etc.

only for every <expiry period> interval!

> will end up in exactly the same scenario.

agreed.

Note that this is just one protocol that can be used for monitoring
(using the Link 'monitor' header).  There could be others, such as
over bi-direcitonal HTTP, XMPP, etc :)

 ~ Theo

---

From: Adam Roach <[email-masked]>
Date: Fri, 10 Jul 2009 10:41:10 -0500

> if they don't support monitoring of non-existent resources.

That seems like a really good idea. I'll put it on the list for the next 
version.

/a

> only for every <expiry period> interval!

And the draft explicitly addresses this point:

   Subscriptions to slower-changing resources lack this property, and
   the need to periodically refresh subscriptions render short
   subscriptions wasteful.  For these type of subscriptions, expirations
   as long as 604800 (one week) or even longer may well make sense.

/a

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 13 Jul 2009 11:33:07 +0300

> if they don't support monitoring of non-existent resources.
this could be a possibility,
but it should be explicitly insert the SUBSCRIBE the willingness to 
monitor also *non-existent resource*
moreover  if a subscriber has several subscriptions to the same server, 
it should be avoided that the server sends
this kind of information to each single subscription.
for example the server should accept only one SUBSCRIBE willing to 
monitor *non-existent resource* per each UA.

/Sal

---

From: "Rifaat Shekh-Yusef" <[email-masked]>
Date: Mon, 13 Jul 2009 15:47:33 -0400

I am interested and willing to help this work progress.

Regards,
 Rifaat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adam Roach
Sent: Tuesday, July 07, 2009 3:48 PM
To: IETF Dispatch
Subject: [dispatch] SIP HTTP Event Package [Fwd: New Version
Notificationfor draft-roach-sip-http-subscribe-02]

/a

---

From: "Scott Lawrence" <[email-masked]>
Date: Tue, 14 Jul 2009 10:20:54 -0400

> I'm bringing it to DISPATCH.

I think this draft is a great idea - I've got a few comments, but will
send those separately

> the "creation" or the "deletion" of

I don't think that the mechanisms used to implement the service need to
be a part of the discussion at all.

The draft should concern itself with the on-the-wire behavior of the
event package, not how the service providing it gets the information it
needs.  There are any number of ways it could be done, including
integrating a SIP UA into the web server, the file store behind the web
server, some application providing data via the web server, etc.  None
of that needs to be (or should be) in the draft defining the event
package.