From adam@nostrum.com Mon Nov 23 09:03:38 2009 Return-Path: X-Original-To: sip-http-events@core3.amsl.com Delivered-To: sip-http-events@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C453A6806 for ; 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-Level: 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXyd42kt2pGE for ; 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 ; Mon, 23 Nov 2009 09:03:36 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (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 ; 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 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 MIME-Version: 1.0 To: SIP HTTP Subscription Package Content-Type: multipart/alternative; boundary="------------020604070604000103030608" Received-SPF: pass (nostrum.com: 75.53.54.121 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:03:38 -0000 This is a multi-part message in MIME format. --------------020604070604000103030608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------020604070604000103030608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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
--------------020604070604000103030608-- From john.elwell@siemens-enterprise.com Mon Nov 23 09:43:07 2009 Return-Path: X-Original-To: sip-http-events@core3.amsl.com Delivered-To: sip-http-events@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A137D3A6ABB for ; Mon, 23 Nov 2009 09:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5qmxem80Kp5 for ; Mon, 23 Nov 2009 09:43:06 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 52C893A6907 for ; Mon, 23 Nov 2009 09:43:06 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-98531; Mon, 23 Nov 2009 18:43:01 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4BFDD23F01D4; Mon, 23 Nov 2009 18:43:01 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 23 Nov 2009 18:43:01 +0100 From: "Elwell, John" To: Adam Roach , SIP HTTP Subscription Package Date: Mon, 23 Nov 2009 18:42:57 +0100 Thread-Topic: [sip-http-events] HTTP Subscribe: Remaining Open Issue Thread-Index: AcpsXucb98A5Smx/TJml0TOYj4zkLgABRUxA Message-ID: References: <4B0AC057.5040703@nostrum.com> In-Reply-To: <4B0AC057.5040703@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A444A0F8084434499206E78C106220CA1CFA49A7MCHP058Aglobala_" MIME-Version: 1.0 Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:43:07 -0000 --_000_A444A0F8084434499206E78C106220CA1CFA49A7MCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For the UA config application I would not see a need for this option, becau= se data could potentially be rather large. Although for the BLISS applicati= on there might be a marginal benefit in having this option, in the interest= s 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-r= oach-sip-http-subscribe ready for publication. I have a couple of open item= s myself (mostly, generation of example messages), but there is one open it= em 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 c= hanges don't include the actual resource state -- although it leaves open t= he 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=3Dtrue") that would request that event state changes= include the new resource state. I *suspect* this would be a very straightf= orward 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 roun= d-trip. On the other hand, the prospect of pushing large HTTP documents thr= ough the SIP network may prove problematic. (If we define this mechanism, I= would definitely propose that including this in a SUBSCRIBE is simply a re= quest, 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 --_000_A444A0F8084434499206E78C106220CA1CFA49A7MCHP058Aglobala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
For the UA config application I would not see a ne= ed for=20 this option, because data could potentially be rather large. Although for t= he=20 BLISS application there might be a marginal benefit in having this option, = in=20 the interests of simplicity I have a slight leaning towards omitting the=20 option.
 
John
 


From: sip-http-events-bounces@ietf.or= g=20 [mailto:sip-http-events-bounces@ietf.org] On Behalf Of Adam=20 Roach
Sent: 23 November 2009 17:03
To: SIP HTTP=20 Subscription Package
Subject: [sip-http-events] HTTP Subscribe:= =20 Remaining Open Issue

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

Currently, the package mentions that notifications of HT= TP=20 resource state changes don't include the actual resource state -- althoug= h it=20 leaves open the possibility that someone may define an extension to do so= in=20 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=20 filter parameter (e.g., "body=3Dtrue") that would request that event stat= e=20 changes include the new resource state. I *suspect* this would be a very= =20 straightforward thing to define, and it may be quite useful for certain u= sages=20 (e.g., some of the proposed BLISS applications have very, very small docu= ments=20 -- on the order of 4 to 40 characters or so), as it would save the HTTP=20 round-trip. On the other hand, the prospect of pushing large HTTP documen= ts=20 through the SIP network may prove problematic. (If we define this mechani= sm, I=20 would definitely propose that including this in a SUBSCRIBE is simply a=20 request, and give the server the option of declining to honor it).
If=20 you have an opinion one way or another about this topic, please post is t= o the=20 list.

The current version of the document is here:

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

/a
= --_000_A444A0F8084434499206E78C106220CA1CFA49A7MCHP058Aglobala_-- From theo@crazygreek.co.uk Mon Nov 23 22:48:27 2009 Return-Path: X-Original-To: sip-http-events@core3.amsl.com Delivered-To: sip-http-events@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A6D28C0D7 for ; Mon, 23 Nov 2009 22:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGAMmnMSUNgL for ; Mon, 23 Nov 2009 22:48:27 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with SMTP id DA72F3A6809 for ; Mon, 23 Nov 2009 22:48:26 -0800 (PST) Received: from source ([209.85.223.176]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSwuBtr2Eabwks3o92/pLTcAs1P7qbk8+@postini.com; Mon, 23 Nov 2009 22:48:23 PST Received: by iwn6 with SMTP id 6so269074iwn.15 for ; Mon, 23 Nov 2009 22:48:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.170.201 with SMTP id e9mr1038502ibz.17.1259045302342; Mon, 23 Nov 2009 22:48:22 -0800 (PST) In-Reply-To: <4B0AC057.5040703@nostrum.com> References: <4B0AC057.5040703@nostrum.com> From: Theo Zourzouvillys Date: Tue, 24 Nov 2009 17:48:02 +1100 Message-ID: <167dfb9b0911232248j6e3f54acged489f40ea881921@mail.gmail.com> To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Cc: SIP HTTP Subscription Package Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 06:48:27 -0000 On Tue, Nov 24, 2009 at 4:03 AM, Adam Roach wrote: > If you have an opinion one way or another about this topic, please post is > to the list. The filter parameter sounds good to me - I certainly see the use for it... ~ Theo -- Sent from Sydney, Nsw, Australia From shida@ntt-at.com Tue Nov 24 00:35:47 2009 Return-Path: X-Original-To: sip-http-events@core3.amsl.com Delivered-To: sip-http-events@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05AAA3A62C1 for ; Tue, 24 Nov 2009 00:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2OUFmAjd6lN for ; Tue, 24 Nov 2009 00:35:46 -0800 (PST) Received: from gateway10.websitewelcome.com (gateway10.websitewelcome.com [67.18.22.69]) by core3.amsl.com (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 gator465.hostgator.com (69.56.174.130) by gateway10.websitewelcome.com with SMTP; 24 Nov 2009 08:49:04 -0000 Received: from fl1-118-109-66-179.tky.mesh.ad.jp ([118.109.66.179]:49866 helo=[192.168.1.5]) by gator465.hostgator.com 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: <4B0AC057.5040703@nostrum.com> 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 - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: SIP HTTP Subscription Package Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 08:35:47 -0000 --Apple-Mail-2--575818865 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I generally agree with John to keep things simple but I don't=20 think adding the filter to say "no body" or "with body" will complicate=20= things more and I actually see use for such filter. For example HTTP resource a cell-phone subscribes to may be a=20 service that monitors multiple HTTP resources (stock price,=20 friends location in relation to you etc.) on behalf of the user and when=20= resources monitored is changed, it would send the URI of the=20 resource in question in body of NOTIFY. Application may then be=20 launched to fetch those resources (financial application when=20 stock changes etc.).. Having the ability to send body in such=20 scenario I believe is useful.. =20 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. > =20 > John > =20 >=20 > 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 >=20 > 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. >=20 > 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. >=20 > In section 3.2, we ask whether this document should define a simple = filter parameter (e.g., "body=3Dtrue") 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). >=20 > If you have an opinion one way or another about this topic, please = post is to the list. >=20 > The current version of the document is here: >=20 > http://tools.ietf.org/html/draft-roach-sip-http-subscribe-02 >=20 > /a > _______________________________________________ > sip-http-events mailing list > sip-http-events@ietf.org > https://www.ietf.org/mailman/listinfo/sip-http-events --Apple-Mail-2--575818865 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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=20 this option, because data could potentially be rather large. Although = for the=20 BLISS application there might be a marginal benefit in having this = option, in=20 the interests of simplicity I have a slight leaning towards omitting the=20= option.
 
John
 

=

From: sip-http-events-bounces@i= etf.org=20 [mailto:sip-http-events-bounces@ietf.org] On Behalf Of Adam=20 Roach
Sent: 23 November 2009 17:03
To: SIP HTTP=20 Subscription Package
Subject: [sip-http-events] HTTP = Subscribe:=20 Remaining Open Issue

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

Currently, the package mentions that notifications of = HTTP=20 resource state changes don't include the actual resource state -- = although it=20 leaves open the possibility that someone may define an extension to do = so in=20 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=20 filter parameter (e.g., "body=3Dtrue") that would request that event = state=20 changes include the new resource state. I *suspect* this would be a = very=20 straightforward thing to define, and it may be quite useful for = certain usages=20 (e.g., some of the proposed BLISS applications have very, very small = documents=20 -- on the order of 4 to 40 characters or so), as it would save the = HTTP=20 round-trip. On the other hand, the prospect of pushing large HTTP = documents=20 through the SIP network may prove problematic. (If we define this = mechanism, I=20 would definitely propose that including this in a SUBSCRIBE is simply = a=20 request, and give the server the option of declining to honor = it).

If=20 you have an opinion one way or another about this topic, please post = is to the=20 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
h= ttps://www.ietf.org/mailman/listinfo/sip-http-events

= --Apple-Mail-2--575818865-- From andrew.hutton@siemens-enterprise.com Tue Nov 24 00:41:19 2009 Return-Path: X-Original-To: sip-http-events@core3.amsl.com Delivered-To: sip-http-events@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7B53A68F1 for ; Tue, 24 Nov 2009 00:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+QkyQmxQB4M for ; Tue, 24 Nov 2009 00:41:18 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5F60B3A685E for ; Tue, 24 Nov 2009 00:41:17 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-104485; Tue, 24 Nov 2009 09:41:12 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id BCC691EB81F0; Tue, 24 Nov 2009 09:41:12 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 24 Nov 2009 09:41:12 +0100 From: "Hutton, Andrew" To: Adam Roach , SIP HTTP Subscription Package Date: Tue, 24 Nov 2009 09:41:13 +0100 Thread-Topic: [sip-http-events] HTTP Subscribe: Remaining Open Issue Thread-Index: AcpsXucb98A5Smx/TJml0TOYj4zkLgAgFciA Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30672CA70F3@MCHP058A.global-ad.net> References: <4B0AC057.5040703@nostrum.com> In-Reply-To: <4B0AC057.5040703@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_101C6067BEC68246B0C3F6843BCCC1E30672CA70F3MCHP058Agloba_" MIME-Version: 1.0 Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 08:41:19 -0000 --_000_101C6067BEC68246B0C3F6843BCCC1E30672CA70F3MCHP058Agloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 ________________________________ 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-r= oach-sip-http-subscribe ready for publication. I have a couple of open item= s myself (mostly, generation of example messages), but there is one open it= em 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 c= hanges don't include the actual resource state -- although it leaves open t= he 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=3Dtrue") that would request that event state changes= include the new resource state. I *suspect* this would be a very straightf= orward 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 roun= d-trip. On the other hand, the prospect of pushing large HTTP documents thr= ough the SIP network may prove problematic. (If we define this mechanism, I= would definitely propose that including this in a SUBSCRIBE is simply a re= quest, 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 --_000_101C6067BEC68246B0C3F6843BCCC1E30672CA70F3MCHP058Agloba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Adam,
 
I like that the filter mechanism will be useful fo= r this=20 event package and I agree with your proposal that it should be a request wh= ich=20 the server can decline.
 
My=20 personal preference would be to include this simple filter in the draft I d= on't=20 think it should cause too much complexity.
 
Regards
Andy


From: sip-http-events-bounces@ietf.org= =20 [mailto:sip-http-events-bounces@ietf.org] On Behalf Of Adam=20 Roach
Sent: 23 November 2009 17:03
To: SIP HTTP Subscri= ption=20 Package
Subject: [sip-http-events] HTTP Subscribe: Remaining Open= =20 Issue

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

Curren= tly,=20 the package mentions that notifications of HTTP resource state changes don'= t=20 include the actual resource state -- although it leaves open the possibilit= y=20 that someone may define an extension to do so in the future; the relevant t= ext=20 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 f= ilter=20 parameter (e.g., "body=3Dtrue") that would request that event state changes= =20 include the new resource state. I *suspect* this would be a very straightfo= rward=20 thing to define, and it may be quite useful for certain usages (e.g., some = of=20 the proposed BLISS applications have very, very small documents -- on the o= rder=20 of 4 to 40 characters or so), as it would save the HTTP round-trip. On the = other=20 hand, the prospect of pushing large HTTP documents through the SIP network = may=20 prove problematic. (If we define this mechanism, I would definitely propose= that=20 including this in a SUBSCRIBE is simply a request, and give the server the= =20 option of declining to honor it).

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

The current ve= rsion=20 of the document is here:

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

/a
--_000_101C6067BEC68246B0C3F6843BCCC1E30672CA70F3MCHP058Agloba_-- From salvatore.loreto@ericsson.com Tue Nov 24 00:55:28 2009 Return-Path: X-Original-To: sip-http-events@core3.amsl.com Delivered-To: sip-http-events@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D153A6892 for ; Tue, 24 Nov 2009 00:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqB20Dt8bnJE for ; Tue, 24 Nov 2009 00:55:27 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9D0E73A62C1 for ; Tue, 24 Nov 2009 00:55:26 -0800 (PST) X-AuditID: c1b4fb3e-b7b90ae000005e1e-9d-4b0b9f78f648 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id BA.B4.24094.97F9B0B4; Tue, 24 Nov 2009 09:55:21 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 09:55:20 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 09:55:20 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6043725C8; Tue, 24 Nov 2009 10:55:20 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 24EAF21A21; Tue, 24 Nov 2009 10:55:20 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C7E8121923; Tue, 24 Nov 2009 10:55:19 +0200 (EET) Message-ID: <4B0B9F77.2060103@ericsson.com> Date: Tue, 24 Nov 2009 10:55:19 +0200 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Adam Roach References: <4B0AC057.5040703@nostrum.com> In-Reply-To: <4B0AC057.5040703@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 24 Nov 2009 08:55:20.0617 (UTC) FILETIME=[DA1CB190:01CA6CE3] X-Brightmail-Tracker: AAAAAA== Cc: SIP HTTP Subscription Package Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 08:55:28 -0000 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: > 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 > From adam@nostrum.com Tue Nov 24 14:05:07 2009 Return-Path: X-Original-To: sip-http-events@core3.amsl.com Delivered-To: sip-http-events@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C523A67AA for ; Tue, 24 Nov 2009 14:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il6HlHYSPnWK for ; Tue, 24 Nov 2009 14:05:04 -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 80F223A6405 for ; Tue, 24 Nov 2009 14:05:04 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAOM4v1E088862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Nov 2009 16:04:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B0C5889.8050401@nostrum.com> Date: Tue, 24 Nov 2009 16:04:57 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 MIME-Version: 1.0 To: SIP HTTP Subscription Package Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sip-http-events] SIP HTTP Event Package: Path Forward X-BeenThere: sip-http-events@ietf.org 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 22:05:07 -0000 To give everyone an overview of how I plan to progress this document: Alexy Melnikov (APPS AD) has agreed to sponsor this document for publication. I plan to spend next week finalizing the areas of the document that are known to be unfinished (the open issue that I posted about yesterday, plus finishing the examples and IANA sections, and adding a security considerations section). After this, I'll call for a final two-week final comment period (think of it kind of like a WGLC) on this mailing list. Pending resolution of any comments raised, I will hand it off to Alexy for review and publication. It is possible that this could happen in mid-December, but the upcoming holidays make it far more likely that this hand-off will occur early in January. That said, the preponderance of the mechanism is well-documented (in my opinion, at least), and is definitely ready for review today. As an interested party, you have some impact on how quickly this progresses. Earlier comments means earlier resolution to issues. Also, substantial review of the document serves as a useful gauge to me regarding how urgently I should treat this document: no review tells me that there is no serious interest. If you have any stake in seeing this published sooner rather than later, it is in your interest to review and comment as soon as possible. /a From adam@nostrum.com Wed Nov 25 13:12:45 2009 Return-Path: X-Original-To: sip-http-events@core3.amsl.com Delivered-To: sip-http-events@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B913A6955 for ; Wed, 25 Nov 2009 13:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVAvAbQSzukh for ; Wed, 25 Nov 2009 13:12:43 -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 A9E163A6B5C for ; Wed, 25 Nov 2009 13:12:42 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAPLCZ09018073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Nov 2009 15:12:35 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B0D9DC3.8030202@nostrum.com> Date: Wed, 25 Nov 2009 15:12:35 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 MIME-Version: 1.0 To: SIP HTTP Subscription Package Content-Type: multipart/alternative; boundary="------------030407050303030708060306" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sip-http-events] Fwd: New Version Notification for draft-roach-sip-http-subscribe-03 X-BeenThere: sip-http-events@ietf.org 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: Wed, 25 Nov 2009 21:12:46 -0000 This is a multi-part message in MIME format. --------------030407050303030708060306 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I was able to add in all the relevant information (including a security section) to cover the previously unfinished portions of the SIP HTTP Subscription draft. This is the version that I will be asking for final comments on in the upcoming weeks: http://www.ietf.org/id/draft-roach-sip-http-subscribe-03.txt Please provide any comments you may have on this version. Thanks. /a -------- Original Message -------- Subject: New Version Notification for draft-roach-sip-http-subscribe-03 Date: Wed, 25 Nov 2009 13:08:08 -0800 (PST) From: IETF I-D Submission Tool To: adam@nostrum.com A new version of I-D, draft-roach-sip-http-subscribe-03.txt has been successfuly submitted by Adam Roach and posted to the IETF repository. Filename: draft-roach-sip-http-subscribe Revision: 03 Title: A SIP Event Package for Subscribing to Changes to an HTTP Resource Creation_date: 2009-11-25 WG ID: Independent Submission Number_of_pages: 18 Abstract: The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near-real- time, when a specific HTTP resource is created, changed, or deleted. This document proposes a mechanism, based on the SIP events framework, for doing so. This document further proposes that the HTTP work necessary to make such a mechanism work be extensible to support protocols other than SIP for monitoring HTTP resources. The IETF Secretariat. --------------030407050303030708060306 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I was able to add in all the relevant information (including a security section) to cover the previously unfinished portions of the SIP HTTP Subscription draft. This is the version that I will be asking for final comments on in the upcoming weeks:

  http://www.ietf.org/id/draft-roach-sip-http-subscribe-03.txt

Please provide any comments you may have on this version. Thanks.

/a

-------- Original Message --------
Subject: New Version Notification for draft-roach-sip-http-subscribe-03
Date: Wed, 25 Nov 2009 13:08:08 -0800 (PST)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: adam@nostrum.com


A new version of I-D, draft-roach-sip-http-subscribe-03.txt has been successfuly submitted by Adam Roach and posted to the IETF repository.

Filename:	 draft-roach-sip-http-subscribe
Revision:	 03
Title:		 A SIP Event Package for Subscribing to Changes to an HTTP Resource
Creation_date:	 2009-11-25
WG ID:		 Independent Submission
Number_of_pages: 18

Abstract:
The Session Initiation Protocol (SIP) is increasingly being used in
systems that are tightly coupled with Hypertext Transport Protocol
(HTTP) servers for a variety of reasons.  In many of these cases,
applications can benefit from being able to discover, in near-real-
time, when a specific HTTP resource is created, changed, or deleted.
This document proposes a mechanism, based on the SIP events
framework, for doing so.

This document further proposes that the HTTP work necessary to make
such a mechanism work be extensible to support protocols other than
SIP for monitoring HTTP resources.
                                                                                  


The IETF Secretariat.


--------------030407050303030708060306-- From adam@nostrum.com Wed Nov 25 13:30:20 2009 Return-Path: X-Original-To: sip-http-events@core3.amsl.com Delivered-To: sip-http-events@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 627F43A6B54 for ; Wed, 25 Nov 2009 13:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDIcOtM6xKxY for ; Wed, 25 Nov 2009 13:30:19 -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 E82B23A6820 for ; Wed, 25 Nov 2009 13:30:18 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAPLUBR1019337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Nov 2009 15:30:11 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B0DA1E3.4070304@nostrum.com> Date: Wed, 25 Nov 2009 15:30:11 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 MIME-Version: 1.0 To: SIP HTTP Subscription Package References: <4B0AC057.5040703@nostrum.com> In-Reply-To: <4B0AC057.5040703@nostrum.com> Content-Type: multipart/alternative; boundary="------------080502080707010406020805" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 21:30:20 -0000 This is a multi-part message in MIME format. --------------080502080707010406020805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 On 11/23/09 11:03 AM, Adam Roach wrote: > 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 > --------------080502080707010406020805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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

On 11/23/09 11:03 AM, Adam Roach wrote:
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

--------------080502080707010406020805-- From john.elwell@siemens-enterprise.com Mon Nov 30 07:43:25 2009 Return-Path: X-Original-To: sip-http-events@core3.amsl.com Delivered-To: sip-http-events@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9413A63EB for ; Mon, 30 Nov 2009 07:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mrqySTmK1Mw for ; Mon, 30 Nov 2009 07:43:24 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 0EE1F3A67A5 for ; Mon, 30 Nov 2009 07:43:23 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-158530; Mon, 30 Nov 2009 16:42:55 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 066B423F01F6; Mon, 30 Nov 2009 16:42:55 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 30 Nov 2009 16:42:54 +0100 From: "Elwell, John" To: Adam Roach , SIP HTTP Subscription Package Date: Mon, 30 Nov 2009 16:42:53 +0100 Thread-Topic: [sip-http-events] Fwd: New Version Notification for draft-roach-sip-http-subscribe-03 Thread-Index: AcpuFAiJBneQO6uASCmqDFmFFjkrggDmnR+Q Message-ID: References: <4B0D9DC3.8030202@nostrum.com> In-Reply-To: <4B0D9DC3.8030202@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sip-http-events] Fwd: New Version Notification for draft-roach-sip-http-subscribe-03 X-BeenThere: sip-http-events@ietf.org 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: Mon, 30 Nov 2009 15:43:25 -0000 Adam, I reviewed this again and it looks almost ready to go. Just a few comments: - In Abstract: "This document further proposes that the HTTP work necessary= to make such a mechanism work be extensible to support protocols other than SIP for monitoring HTTP resources."=20 The only further mention of this seems to be in section 3 "Handling for other URI schemes is out of scope for the current document, although we expect future specifications to define procedures for monitoring via other protocols." To justify the wording in Abstract I would expect more than this. I would p= ropose deletion of the words in Abstract. - In section 1: "Such subscriptions do not carry the content associated wit= h the resource -- the HTTP protocol is still used to transfer the contents of HTTP resources." With the addition of the body=3D parameter, this isn't always true. - In section 4..2: "this parameter indicates to the server that the client wishes to receive a message- body component in the message/http bodies sent in NOTIFY messages." The terminology used here ("message body component", "bodies") seems to be = inconsistent with terminology used in SIP in general and RFC 5621 in partic= ular, i.e., a "message body" (singular) and "body parts". In fact this inco= nsistency in terminology occurs in other sections, which I haven't pulled o= ut specifically. In the particular case of the sentence above, shouldn't it= say something like "wishes to receive message/http body part(s) in NOTIFY = messages"? - In section 4.7 "In the case that the NOTIFIER has insufficient informatio= n to return any useful information about the underlying HTTP resource, it may return a body that is zero bytes long." What motivated this? Would termination of the subscription be an alternativ= e possibility? Some nits: - In section 3: "the the" - In 4.4: "other can change" - change to "others can change " - There is one instance each of "NOTIFIER" and "SUBSCRIBER" (in 4.7 and 4.9= ) - these should not be capitalized. - In 4.8: "subscriber should" - changed to "the subscriber should" John > -----Original Message----- > From: sip-http-events-bounces@ietf.org=20 > [mailto:sip-http-events-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 25 November 2009 21:13 > To: SIP HTTP Subscription Package > Subject: [sip-http-events] Fwd: New Version Notification for=20 > draft-roach-sip-http-subscribe-03 >=20 > I was able to add in all the relevant information (including=20 > a security section) to cover the previously unfinished=20 > portions of the SIP HTTP Subscription draft. This is the=20 > version that I will be asking for final comments on in the=20 > upcoming weeks: >=20 > http://www.ietf.org/id/draft-roach-sip-http-subscribe-03.txt >=20 > Please provide any comments you may have on this version. Thanks. >=20 > /a >=20 > -------- Original Message --------=20 > Subject: New Version Notification for=20 > draft-roach-sip-http-subscribe-03=09 > Date: Wed, 25 Nov 2009 13:08:08 -0800 (PST)=09 > From: IETF I-D Submission Tool=20 > =09 > To: adam@nostrum.com=09 >=20 >=20 > A new version of I-D, draft-roach-sip-http-subscribe-03.txt=20 > has been successfuly submitted by Adam Roach and posted to=20 > the IETF repository. >=20 > Filename: draft-roach-sip-http-subscribe > Revision: 03 > Title: A SIP Event Package for Subscribing to=20 > Changes to an HTTP Resource > Creation_date: 2009-11-25 > WG ID: Independent Submission > Number_of_pages: 18 >=20 > Abstract: > The Session Initiation Protocol (SIP) is increasingly being used in > systems that are tightly coupled with Hypertext Transport Protocol > (HTTP) servers for a variety of reasons. In many of these cases, > applications can benefit from being able to discover, in near-real- > time, when a specific HTTP resource is created, changed, or deleted. > This document proposes a mechanism, based on the SIP events > framework, for doing so. >=20 > This document further proposes that the HTTP work necessary to make > such a mechanism work be extensible to support protocols other than > SIP for monitoring HTTP resources. > =20 > =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 > = From adam@nostrum.com Mon Nov 30 09:17:26 2009 Return-Path: X-Original-To: sip-http-events@core3.amsl.com Delivered-To: sip-http-events@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A643A680B for ; Mon, 30 Nov 2009 09:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6Vc6yDRExBW for ; Mon, 30 Nov 2009 09:17:25 -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 47E5B3A6926 for ; Mon, 30 Nov 2009 09:17:24 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAUHHFkR033973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Nov 2009 11:17:16 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B13FE1B.3000804@nostrum.com> Date: Mon, 30 Nov 2009 11:17:15 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 MIME-Version: 1.0 To: "Elwell, John" References: <4B0D9DC3.8030202@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIP HTTP Subscription Package Subject: Re: [sip-http-events] Fwd: New Version Notification for draft-roach-sip-http-subscribe-03 X-BeenThere: sip-http-events@ietf.org 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: Mon, 30 Nov 2009 17:17:26 -0000 John: Thanks for the review. Responses inline. On 11/30/09 9:42 AM, Elwell, John wrote: > Adam, > > I reviewed this again and it looks almost ready to go. Just a few comments: > > - In Abstract: "This document further proposes that the HTTP work necessary to make > such a mechanism work be extensible to support protocols other than > SIP for monitoring HTTP resources." > The only further mention of this seems to be in section 3 "Handling for > other URI schemes is out of scope for the current document, although > we expect future specifications to define procedures for monitoring > via other protocols." > To justify the wording in Abstract I would expect more than this. I would propose deletion of the words in Abstract. > I've deleted them. I had originally intended to say more on this topic, and wanted to make sure that this aspect of the "monitor" link association was as externally visible as possible. But I agree that it doesn't make much sense, given the current content of the document. > - In section 1: "Such subscriptions do not carry the content associated with > the resource -- the HTTP protocol is still used to transfer the > contents of HTTP resources." > With the addition of the body= parameter, this isn't always true. > I propose changing this to: Such subscriptions do not necessarily carry the content associated with the resource. In the cases that the content is not conveyed, the HTTP protocol is still used to transfer the contents of HTTP resources. > - In section 4..2: "this parameter > indicates to the server that the client wishes to receive a message- > body component in the message/http bodies sent in NOTIFY messages." > > The terminology used here ("message body component", "bodies") seems to be inconsistent with terminology used in SIP in general and RFC 5621 in particular, i.e., a "message body" (singular) and "body parts". In fact this inconsistency in terminology occurs in other sections, which I haven't pulled out specifically. In the particular case of the sentence above, shouldn't it say something like "wishes to receive message/http body part(s) in NOTIFY messages"? > If your objection is the use of "message bodies" instead of "body parts," then I think you're conflating two things. "Body parts" is exclusively a MIME multipart term, not a SIP term. In the sip-http-subscribe document, we're not talking about multiple MIME body parts on a single NOTIFY message (which would be "body parts"). We're talking about multiple NOTIFY messages, and the respective single message body associated with each of them. It's a one-to-one relationship, without the use of MIME multipart mechanisms. The rest of the prose you quote is slightly awkward because this is a rather confusing concept that I'm having a hard time putting into prose. We're talking about two different kinds of messages that use the same terminology. There is a SIP message. It contains a message body. The SIP message body is an HTTP message. The HTTP message also contains a message-body. The parameter is trying to talk about the HTTP body part, not the SIP body part. I've tried to clean this section up; does this sound right to you? If present and set to "true" in a SUBSCRIBE request, this parameter indicates to the server that the client wishes to receive a message-body component in the message/http message bodies sent in NOTIFY messages. If a server receives a SUBSCRIBE message with a "Event" header field "body" parameter set to "true", it MAY choose to include a message-body component in the message/http message bodies that it sends in NOTIFY messages. Alternatively, it MAY decline to send such message-bodies, even when this parameter is present, based on local policy. In particular, it would be quite reasonable for servers to have a policy of not including HTTP message-bodies larger than a relatively small number of bytes. (I also made a sweep of the use of "body" and "bodies" elsewhere in the document to make sure they are consistent). > - In section 4.7 "In the case that the NOTIFIER has insufficient information to return > any useful information about the underlying HTTP resource, it may > return a body that is zero bytes long." > What motivated this? Would termination of the subscription be an alternative possibility? > This would generally be a temporary condition. Imagine that the notifier has to perform an asynchronous operation -- such as a back-end subscription -- to obtain the information about the HTTP resource. > Some nits... > Thanks; I've fixed these. /a From adam@nostrum.com Mon Nov 30 11:12:38 2009 Return-Path: X-Original-To: sip-http-events@core3.amsl.com Delivered-To: sip-http-events@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2373A67F1 for ; Mon, 30 Nov 2009 11:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7QzeATk7YZv for ; Mon, 30 Nov 2009 11:12: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 25F3D28C10C for ; Mon, 30 Nov 2009 11:12:35 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAUJCMVk042544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Nov 2009 13:12:22 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B141916.3070904@nostrum.com> Date: Mon, 30 Nov 2009 13:12:22 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 MIME-Version: 1.0 To: "Elwell, John" References: <4B0D9DC3.8030202@nostrum.com> <4B13FE1B.3000804@nostrum.com> In-Reply-To: <4B13FE1B.3000804@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIP HTTP Subscription Package Subject: Re: [sip-http-events] Fwd: New Version Notification for draft-roach-sip-http-subscribe-03 X-BeenThere: sip-http-events@ietf.org 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: Mon, 30 Nov 2009 19:12:38 -0000 I've produced a new version of the document incorporating these changes. See the diff here: http://tools.ietf.org/rfcdiff?url2=draft-roach-sip-http-subscribe-04.txt /a On 11/30/09 11:17 AM, Adam Roach wrote: > John: > > Thanks for the review. Responses inline. > > > On 11/30/09 9:42 AM, Elwell, John wrote: >> Adam, >> >> I reviewed this again and it looks almost ready to go. Just a few >> comments: >> >> - In Abstract: "This document further proposes that the HTTP work >> necessary to make >> such a mechanism work be extensible to support protocols other than >> SIP for monitoring HTTP resources." >> The only further mention of this seems to be in section 3 "Handling for >> other URI schemes is out of scope for the current document, although >> we expect future specifications to define procedures for monitoring >> via other protocols." >> To justify the wording in Abstract I would expect more than this. I >> would propose deletion of the words in Abstract. > > I've deleted them. I had originally intended to say more on this > topic, and wanted to make sure that this aspect of the "monitor" link > association was as externally visible as possible. But I agree that it > doesn't make much sense, given the current content of the document. > >> - In section 1: "Such subscriptions do not carry the content >> associated with >> the resource -- the HTTP protocol is still used to transfer the >> contents of HTTP resources." >> With the addition of the body= parameter, this isn't always true. > > I propose changing this to: > > Such subscriptions do not necessarily carry the content > associated with the resource. In the cases that the content > is not conveyed, the HTTP protocol is still used to transfer > the contents of HTTP resources. > > >> - In section 4..2: "this parameter >> indicates to the server that the client wishes to receive a message- >> body component in the message/http bodies sent in NOTIFY messages." >> >> The terminology used here ("message body component", "bodies") seems >> to be inconsistent with terminology used in SIP in general and RFC >> 5621 in particular, i.e., a "message body" (singular) and "body >> parts". In fact this inconsistency in terminology occurs in other >> sections, which I haven't pulled out specifically. In the particular >> case of the sentence above, shouldn't it say something like "wishes >> to receive message/http body part(s) in NOTIFY messages"? > > If your objection is the use of "message bodies" instead of "body > parts," then I think you're conflating two things. "Body parts" is > exclusively a MIME multipart term, not a SIP term. In the > sip-http-subscribe document, we're not talking about multiple MIME > body parts on a single NOTIFY message (which would be "body parts"). > We're talking about multiple NOTIFY messages, and the respective > single message body associated with each of them. It's a one-to-one > relationship, without the use of MIME multipart mechanisms. > > The rest of the prose you quote is slightly awkward because this is a > rather confusing concept that I'm having a hard time putting into > prose. We're talking about two different kinds of messages that use > the same terminology. > > There is a SIP message. It contains a message body. > The SIP message body is an HTTP message. The HTTP message also > contains a message-body. > > The parameter is trying to talk about the HTTP body part, not the SIP > body part. > > I've tried to clean this section up; does this sound right to you? > > If present and set to "true" in a SUBSCRIBE request, > this parameter indicates to the server that the client > wishes to receive a message-body component in the > message/http message bodies sent in NOTIFY messages. > > If a server receives a SUBSCRIBE message with a "Event" > header field "body" parameter set to "true", it MAY > choose to include a message-body component in the > message/http message bodies that it sends in NOTIFY > messages. Alternatively, it MAY decline to send such > message-bodies, even when this parameter is present, > based on local policy. In particular, it would be quite > reasonable for servers to have a policy of not including > HTTP message-bodies larger than a relatively small > number of bytes. > > (I also made a sweep of the use of "body" and "bodies" elsewhere in > the document to make sure they are consistent). > >> - In section 4.7 "In the case that the NOTIFIER has insufficient >> information to return >> any useful information about the underlying HTTP resource, it may >> return a body that is zero bytes long." >> What motivated this? Would termination of the subscription be an >> alternative possibility? > > This would generally be a temporary condition. Imagine that the > notifier has to perform an asynchronous operation -- such as a > back-end subscription -- to obtain the information about the HTTP > resource. > >> Some nits... > > Thanks; I've fixed these. > > /a > _______________________________________________ > sip-http-events mailing list > sip-http-events@ietf.org > https://www.ietf.org/mailman/listinfo/sip-http-events From john.elwell@siemens-enterprise.com Mon Nov 30 12:44:03 2009 Return-Path: X-Original-To: sip-http-events@core3.amsl.com Delivered-To: sip-http-events@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7566E3A699C for ; Mon, 30 Nov 2009 12:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4fZKg5oWiO0 for ; Mon, 30 Nov 2009 12:44:02 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 1AEA53A6995 for ; Mon, 30 Nov 2009 12:44:01 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-161531; Mon, 30 Nov 2009 21:43:54 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 49E8823F01F6; Mon, 30 Nov 2009 21:43:54 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 30 Nov 2009 21:43:54 +0100 From: "Elwell, John" To: Adam Roach Date: Mon, 30 Nov 2009 21:43:52 +0100 Thread-Topic: [sip-http-events] Fwd: New Version Notification for draft-roach-sip-http-subscribe-03 Thread-Index: Acpx4PnlCuFLYXOAThaS+WpDIuvQuwAG8nGQ Message-ID: References: <4B0D9DC3.8030202@nostrum.com> <4B13FE1B.3000804@nostrum.com> In-Reply-To: <4B13FE1B.3000804@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP HTTP Subscription Package Subject: Re: [sip-http-events] Fwd: New Version Notification for draft-roach-sip-http-subscribe-03 X-BeenThere: sip-http-events@ietf.org 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: Mon, 30 Nov 2009 20:44:03 -0000 Adam, Thanks. I checked the diff and it seems you have addressed all my concerns. John=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 30 November 2009 17:17 > To: Elwell, John > Cc: SIP HTTP Subscription Package > Subject: Re: [sip-http-events] Fwd: New Version Notification=20 > for draft-roach-sip-http-subscribe-03 >=20 > John: >=20 > Thanks for the review. Responses inline. >=20 >=20 > On 11/30/09 9:42 AM, Elwell, John wrote: > > Adam, > > > > I reviewed this again and it looks almost ready to go. Just=20 > a few comments: > > > > - In Abstract: "This document further proposes that the=20 > HTTP work necessary to make > > such a mechanism work be extensible to support=20 > protocols other than > > SIP for monitoring HTTP resources." > > The only further mention of this seems to be in section 3=20 > "Handling for > > other URI schemes is out of scope for the current=20 > document, although > > we expect future specifications to define procedures=20 > for monitoring > > via other protocols." > > To justify the wording in Abstract I would expect more than=20 > this. I would propose deletion of the words in Abstract. > > =20 >=20 > I've deleted them. I had originally intended to say more on=20 > this topic,=20 > and wanted to make sure that this aspect of the "monitor" link=20 > association was as externally visible as possible. But I=20 > agree that it=20 > doesn't make much sense, given the current content of the document. >=20 > > - In section 1: "Such subscriptions do not carry the=20 > content associated with > > the resource -- the HTTP protocol is still used to transfer the > > contents of HTTP resources." > > With the addition of the body=3D parameter, this isn't always true. > > =20 >=20 > I propose changing this to: >=20 > Such subscriptions do not necessarily carry the content > associated with the resource. In the cases that the content > is not conveyed, the HTTP protocol is still used to transfer > the contents of HTTP resources. >=20 >=20 > > - In section 4..2: "this parameter > > indicates to the server that the client wishes to=20 > receive a message- > > body component in the message/http bodies sent in=20 > NOTIFY messages." > > > > The terminology used here ("message body component",=20 > "bodies") seems to be inconsistent with terminology used in=20 > SIP in general and RFC 5621 in particular, i.e., a "message=20 > body" (singular) and "body parts". In fact this inconsistency=20 > in terminology occurs in other sections, which I haven't=20 > pulled out specifically. In the particular case of the=20 > sentence above, shouldn't it say something like "wishes to=20 > receive message/http body part(s) in NOTIFY messages"? > > =20 >=20 > If your objection is the use of "message bodies" instead of "body=20 > parts," then I think you're conflating two things. "Body parts" is=20 > exclusively a MIME multipart term, not a SIP term. In the=20 > sip-http-subscribe document, we're not talking about multiple=20 > MIME body=20 > parts on a single NOTIFY message (which would be "body parts"). We're=20 > talking about multiple NOTIFY messages, and the respective single=20 > message body associated with each of them. It's a one-to-one=20 > relationship, without the use of MIME multipart mechanisms. >=20 > The rest of the prose you quote is slightly awkward because this is a=20 > rather confusing concept that I'm having a hard time putting=20 > into prose.=20 > We're talking about two different kinds of messages that use the same=20 > terminology. >=20 > There is a SIP message. It contains a message body. > The SIP message body is an HTTP message. The HTTP message=20 > also contains=20 > a message-body. >=20 > The parameter is trying to talk about the HTTP body part, not the SIP=20 > body part. >=20 > I've tried to clean this section up; does this sound right to you? >=20 > If present and set to "true" in a SUBSCRIBE request, > this parameter indicates to the server that the client > wishes to receive a message-body component in the > message/http message bodies sent in NOTIFY messages. >=20 > If a server receives a SUBSCRIBE message with a "Event" > header field "body" parameter set to "true", it MAY > choose to include a message-body component in the > message/http message bodies that it sends in NOTIFY > messages. Alternatively, it MAY decline to send such > message-bodies, even when this parameter is present, > based on local policy. In particular, it would be quite > reasonable for servers to have a policy of not including > HTTP message-bodies larger than a relatively small > number of bytes. >=20 > (I also made a sweep of the use of "body" and "bodies"=20 > elsewhere in the=20 > document to make sure they are consistent). >=20 > > - In section 4.7 "In the case that the NOTIFIER has=20 > insufficient information to return > > any useful information about the underlying HTTP=20 > resource, it may > > return a body that is zero bytes long." > > What motivated this? Would termination of the subscription=20 > be an alternative possibility? > > =20 >=20 > This would generally be a temporary condition. Imagine that=20 > the notifier=20 > has to perform an asynchronous operation -- such as a back-end=20 > subscription -- to obtain the information about the HTTP resource. >=20 > > Some nits... > > =20 >=20 > Thanks; I've fixed these. >=20 > /a > =