Re: [sip-http-events] Fwd: New Version Notification for draft-roach-sip-http-subscribe-03
Shida Schubert <shida@ntt-at.com> Tue, 01 December 2009 09:29 UTC
Return-Path: <shida@ntt-at.com>
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 9D9CA3A6A06 for <sip-http-events@core3.amsl.com>; Tue, 1 Dec 2009 01:29:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.165
X-Spam-Level:
X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 ja+gcr64GSFi for <sip-http-events@core3.amsl.com>; Tue, 1 Dec 2009 01:29:46 -0800 (PST)
Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.52.26]) by core3.amsl.com (Postfix) with SMTP id 8EF1E3A69FF for <sip-http-events@ietf.org>; Tue, 1 Dec 2009 01:29:46 -0800 (PST)
Received: (qmail 5542 invoked from network); 1 Dec 2009 09:42:44 -0000
Received: from gator465.hostgator.com (69.56.174.130) by gateway03.websitewelcome.com with SMTP; 1 Dec 2009 09:42:44 -0000
Received: from fl1-118-109-66-179.tky.mesh.ad.jp ([118.109.66.179]:64372 helo=[192.168.1.5]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from <shida@ntt-at.com>) id 1NFP3A-0001FM-Do; Tue, 01 Dec 2009 03:29:37 -0600
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Shida Schubert <shida@ntt-at.com>
In-Reply-To: <4B141916.3070904@nostrum.com>
Date: Tue, 01 Dec 2009 18:29:36 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <839A9D89-DD1C-470F-8C5C-993069D5C1DC@ntt-at.com>
References: <4B0D9DC3.8030202@nostrum.com> <A444A0F8084434499206E78C106220CA43A2E6C9@MCHP058A.global-ad.net> <4B13FE1B.3000804@nostrum.com> <4B141916.3070904@nostrum.com>
To: Adam Roach <adam@nostrum.com>
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 <sip-http-events@ietf.org>
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 <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: Tue, 01 Dec 2009 09:29:47 -0000
Adam, Just reviewed the 04 version of the draft. Beside the few nits indicated below, the draft looked solid. Thanks for working on this. Section 3.1/Last sentence of last paragraph : "section Section 4" Section 4.5.1/Last Paragraph : "contain a the same" Regards Shida On Dec 1, 2009, at 4:12 AM, Adam Roach wrote: > 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 > > _______________________________________________ > sip-http-events mailing list > sip-http-events@ietf.org > https://www.ietf.org/mailman/listinfo/sip-http-events
- [sip-http-events] Fwd: New Version Notification f… Adam Roach
- Re: [sip-http-events] Fwd: New Version Notificati… Elwell, John
- Re: [sip-http-events] Fwd: New Version Notificati… Adam Roach
- Re: [sip-http-events] Fwd: New Version Notificati… Adam Roach
- Re: [sip-http-events] Fwd: New Version Notificati… Elwell, John
- Re: [sip-http-events] Fwd: New Version Notificati… Shida Schubert
- Re: [sip-http-events] Fwd: New Version Notificati… Adam Roach