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

[Adam Roach <[e-mail]>]

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