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

From: Adam Roach <[email-masked]>
Date: Mon, 23 Nov 2009 11:03:19 -0600

There has been increasing interest in having a finalized version of 
draft-roach-sip-http-subscribe ready for publication. I have a couple of 
open items myself (mostly, generation of example messages), but there is 
one open item called out in the draft at the moment. I expect to take 
care of these in the near future, and request publication as soon as 
feasible.

Currently, the package mentions that notifications of HTTP resource 
state changes don't include the actual resource state -- although it 
leaves open the possibility that someone may define an extension to do 
so in the future; the relevant text is:

    When used in the HTTP monitor event package, the message/http MUST
    NOT contain a message-body component, unless the corresponding
    subscription has explicitly indicated the desire to receive such
    bodies in the form of a filter.  Filters for this event package are
    out of scope for this specification.

In section 3.2, we ask whether this document should define a simple 
filter parameter (e.g., "body=true") that would request that event state 
changes include the new resource state. I *suspect* this would be a very 
straightforward thing to define, and it may be quite useful for certain 
usages (e.g., some of the proposed BLISS applications have very, very 
small documents -- on the order of 4 to 40 characters or so), as it 
would save the HTTP round-trip. On the other hand, the prospect of 
pushing large HTTP documents through the SIP network may prove 
problematic. (If we define this mechanism, I would definitely propose 
that including this in a SUBSCRIBE is simply a request, and give the 
server the option of declining to honor it).

If you have an opinion one way or another about this topic, please post 
is to the list.

The current version of the document is here:

http://tools.ietf.org/html/draft-roach-sip-http-subscribe-02

/a

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 23 Nov 2009 18:42:57 +0100

For the UA config application I would not see a need for this option, because data could potentially be rather large. Although for the BLISS application there might be a marginal benefit in having this option, in the interests of simplicity I have a slight leaning towards omitting the option.

John

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 23 November 2009 17:03
To: SIP HTTP Subscription Package
Subject: [sip-http-events] HTTP Subscribe: Remaining Open Issue

There has been increasing interest in having a finalized version of draft-roach-sip-http-subscribe ready for publication. I have a couple of open items myself (mostly, generation of example messages), but there is one open item called out in the draft at the moment. I expect to take care of these in the near future, and request publication as soon as feasible.

Currently, the package mentions that notifications of HTTP resource state changes don't include the actual resource state -- although it leaves open the possibility that someone may define an extension to do so in the future; the relevant text is:

In section 3.2, we ask whether this document should define a simple filter parameter (e.g., "body=true") that would request that event state changes include the new resource state. I *suspect* this would be a very straightforward thing to define, and it may be quite useful for certain usages (e.g., some of the proposed BLISS applications have very, very small documents -- on the order of 4 to 40 characters or so), as it would save the HTTP round-trip. On the other hand, the prospect of pushing large HTTP documents through the SIP network may prove problematic. (If we define this mechanism, I would definitely propose that including this in a SUBSCRIBE is simply a request, and give the server the option of declining to honor it).

If you have an opinion one way or another about this topic, please post is to the list.

/a

---

From: Theo Zourzouvillys <[email-masked]>
Date: Tue, 24 Nov 2009 17:48:02 +1100

> If you have an opinion one way or another about this topic, please post is

The filter parameter sounds good to me - I certainly see the use for it...

 ~ Theo

-- 

Sent from Sydney, Nsw, Australia

---

From: Shida Schubert <[email-masked]>
Date: Tue, 24 Nov 2009 17:35:38 +0900

I generally agree with John to keep things simple but I don't 
think adding the filter to say "no body" or "with body" will complicate 
things more and I actually see use for such filter.

 For example HTTP resource a cell-phone subscribes to may be a 
service that monitors multiple HTTP resources (stock price, 
friends location in relation to you etc.) on behalf of the user and when 
resources monitored is changed, it would send the URI of the 
resource in question in body of NOTIFY. Application may then be 
launched to fetch those resources (financial application when 
stock changes etc.).. Having the ability to send body in such 
scenario I believe is useful..  

 Regards
   Shida

On Nov 24, 2009, at 2:42 AM, Elwell, John wrote:

> _______________________________________________
> sip-http-events mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-http-events

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 24 Nov 2009 09:41:13 +0100

Hi Adam,

I like that the filter mechanism will be useful for this event package and I agree with your proposal that it should be a request which the server can decline.

My personal preference would be to include this simple filter in the draft I don't think it should cause too much complexity.

Regards
Andy

/a

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 24 Nov 2009 10:55:19 +0200

Hi Adam,

thanks for the effort in continuing this work

as one of my doubts and previously comment to use SIP to monitor HTTP 
resource was the extra HTTP round-trip to fetch the new resource state,
I am in support and I do think we should define some sort of basic 
filter parameter so that event changes state can include the new 
resource state.

I have also taken the occasion to re-read all the draft and I have an 
additional comment:

I like the possibility to Monitoring Multiple HTTP Resources,
however it is not clear to me if it is possible or not to Subscribe to a 
monitor-group URI without including the URI list.

for example, consider the case in which a client wishes to monitor the 
resources associated to Alice in draft 
draft-zourzouvillys-bliss-ach-http-api-01

does the client have to perform a GET or HEAD operation  for  each  
resource in order to  discover the 
monitor-link of each of them and only after it has discovered all the 
monitor-links Subscribe to the monitor-group including the URI list;

or it would be enough perform a GET or HEAD operation for 
https://api.example.com/alice/ach/
and subscribe to the monitor-group URI returned by the operation without 
including any URI list.

The latter would a sort of implicit registration to all the resources 
included in the monitor-group, where the
inclusion of an URI list would be a sort of filter for the subset of 
resources included in the monitor-group  the client is interested in.

/Sal

Adam Roach wrote:
> draft-roach-sip-http-subscribe ready for publication. I have a couple 
> of open items myself (mostly, generation of example messages), but 
> there is one open item called out in the draft at the moment. I expect 
> to take care of these in the near future, and request publication as 
> soon as feasible.
>
> filter parameter (e.g., "body=true") that would request that event 
> state changes include the new resource state. I *suspect* this would 
> be a very straightforward thing to define, and it may be quite useful 
> for certain usages (e.g., some of the proposed BLISS applications have 
> very, very small documents -- on the order of 4 to 40 characters or 
> so), as it would save the HTTP round-trip. On the other hand, the 
> prospect of pushing large HTTP documents through the SIP network may 
> prove problematic. (If we define this mechanism, I would definitely 
> propose that including this in a SUBSCRIBE is simply a request, and 
> give the server the option of declining to honor it).
>
> ------------------------------------------------------------------------
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 25 Nov 2009 15:30:11 -0600

Based on the feedback so far (thanks for replying so quickly!) it 
certainly seems like there is significant support for adding the ability 
to request inclusion of bodies in the NOTIFY messages. The -03 version 
of the document has incorporated this feature.

/a