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

Shida Schubert <> Tue, 24 November 2009 08:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05AAA3A62C1 for <>; Tue, 24 Nov 2009 00:35:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.965
X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L2OUFmAjd6lN for <>; Tue, 24 Nov 2009 00:35:46 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id CA7753A68F1 for <>; Tue, 24 Nov 2009 00:35:45 -0800 (PST)
Received: (qmail 11999 invoked from network); 24 Nov 2009 08:49:04 -0000
Received: from ( by with SMTP; 24 Nov 2009 08:49:04 -0000
Received: from ([]:49866 helo=[]) by with esmtpa (Exim 4.69) (envelope-from <>) id 1NCqs8-0001hS-6o; Tue, 24 Nov 2009 02:35:40 -0600
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/alternative; boundary=Apple-Mail-2--575818865
From: Shida Schubert <>
In-Reply-To: <>
Date: Tue, 24 Nov 2009 17:35:38 +0900
Message-Id: <>
References: <> <>
To: "Elwell, John" <>
X-Mailer: Apple Mail (2.1077)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Cc: SIP HTTP Subscription Package <>
Subject: Re: [sip-http-events] HTTP Subscribe: Remaining Open Issue
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP HTTP Events <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Nov 2009 08:35:47 -0000

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


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: [] 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:
> /a
> _______________________________________________
> sip-http-events mailing list