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

From: Adam Roach <[email-masked]>
Date: Wed, 25 Nov 2009 15:12:35 -0600

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 <[email-masked]>
To: 	[email-masked]

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.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 30 Nov 2009 16:42:53 +0100

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: [email-masked] 
> [mailto:[email-masked]] 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:
> 
> From: 	IETF I-D Submission Tool 
> <[email-masked]> <mailto:[email-masked]> 	
> To: 	[email-masked]	
> 
> 
> 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.
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 30 Nov 2009 11:17:15 -0600

John:

Thanks for the review. Responses inline.

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

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

> 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 "bo…

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

> 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 Roach <[email-masked]>
Date: Mon, 30 Nov 2009 13:12:22 -0600

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:
>> 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 
>> 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"?
>
> 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 
> 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.
>
> The SIP message body is an HTTP message. The HTTP message also 
> contains a message-body.
>
> (I also made a sweep of the use of "body" and "bodies" elsewhere in 
> the document to make sure they are consistent).
>
> 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...
>
> _______________________________________________
> sip-http-events mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-http-events

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 30 Nov 2009 21:43:52 +0100

Adam,

Thanks. I checked the diff and it seems you have addressed all my concerns.

John 

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 30 November 2009 17:17
> To: Elwell, John
> Cc: SIP HTTP Subscription Package
> Subject: Re: [sip-http-events] Fwd: New Version Notification 
> for draft-roach-sip-http-subscribe-03
> 
> John:
> 
> > To justify the wording in Abstract I would expect more than 
> this. I would propose deletion of the words in Abstract.
> >    
> 
> > 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"?
> >    
>