Re: [sip-http-events] Fwd: New Version Notification for draft-roach-sip-http-subscribe-03

["Elwell, John" <[e-mail]>]

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.

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

- 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"?

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


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: [e-mail] 
> [mailto:[e-mail]] 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 
> draft-roach-sip-http-subscribe-03
> 
> 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 
> <[e-mail]> <mailto:[e-mail]> 	
> To: 	[e-mail]	
> 
> 
> 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.
> 
> 
> 
>