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

 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:

> 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: sip-http-events-bounces@ietf.org [mailto:sip-http-events-bounces@ietf.org] 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:
>    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
> _______________________________________________
> sip-http-events mailing list
> sip-http-events@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-http-events