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

Adam Roach <adam@nostrum.com> Mon, 23 November 2009 17:03 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: sip-http-events@core3.amsl.com
Delivered-To: sip-http-events@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id F0C453A6806 for <sip-http-events@core3.amsl.com>; Mon, 23 Nov 2009 09:03:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id lXyd42kt2pGE for <sip-http-events@core3.amsl.com>; Mon, 23 Nov 2009 09:03:36 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 69B813A68DE for <sip-http-events@ietf.org>; Mon, 23 Nov 2009 09:03:36 -0800 (PST)
Received: from [] (vicuna-alt.estacado.net []) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nANH3Jkr091254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <sip-http-events@ietf.org>; Mon, 23 Nov 2009 11:03:26 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4B0AC057.5040703@nostrum.com>
Date: Mon, 23 Nov 2009 11:03:19 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20091121 Thunderbird/3.0
MIME-Version: 1.0
To: SIP HTTP Subscription Package <sip-http-events@ietf.org>
Content-Type: multipart/alternative; boundary="------------020604070604000103030608"
Received-SPF: pass (nostrum.com: is authenticated by a trusted mechanism)
Subject: [sip-http-events] HTTP Subscribe: Remaining Open Issue
X-BeenThere: sip-http-events@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP HTTP Events <sip-http-events.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip-http-events>, <mailto:sip-http-events-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-http-events>
List-Post: <mailto:sip-http-events@ietf.org>
List-Help: <mailto:sip-http-events-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-http-events>, <mailto:sip-http-events-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Nov 2009 17:03:38 -0000

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 

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: