Re: [sip-http-events] Draft comments

[Adam Roach <[e-mail]>]

Thanks for the review! Responses inline.

Here's the new version incorporating my proposed changes:

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

And the diffs are here:

   http://tools.ietf.org/rfcdiff?url2=draft-roach-sip-http-subscribe-05


On 12/2/09 12:27 AM, Thomson, Martin wrote:
> Discussion of the new "monitor" relation type is noticeably absent from the initial discussion on links.  Can you make this clearer in paragraph 2 of Section 3?  Maybe something like:
>
> OLD:
>     This document defines behavior for SIP and SIPS URIs in such link relations.
> NEW:
>     This document defines a "monitor" link relation type and a method for using a sip: or sips: URI that is included in a link relation of this type.
>    

Changed to:

       This document defines two new link relation types ("monitor"
       and "monitor-group") for this purpose, and specifies behavior
       for SIP and SIPS URIs in link relations of these types.

> This also addresses my second concern. That is, the original text seems to claim a method of use for SIP URIs in all types of link relations.
>    

The use of the word "such" in the phrase "...in such link relations..." 
was intended to scope it down to discovering changes to the resource. 
But I think the new phrasing (based on your proposal) makes it even clearer.

> Also in Section 3, this paragraph uses the phrase "types of link relations" in a confusing manner:
>
>     Clients making use of the mechanism described in this document MUST
>     support the HTTP Link:<snip>... These requirements are not intended to
>     preclude the use of any other types of link relations.
>    

Thanks. On re-reading that, it sounds like it's talking about link 
relation types, not means of conveying link relations. Changed to: 
"These requirements are not intended to preclude the use of any other 
means of conveying link relations."

> Regarding the "body" parameter, does the NOTIFY include the decision of the server with respect to the body in the Event/Subscription-State header?
>    

Not in the SIP headers, but the information is conveyed trivially. You 
examine the message/http. If it contains a message-body, the server has 
decided to send HTTP message-bodies. Otherwise, the server has decided 
not to send HTTP message-bodies. ;-)

> Also regarding the "body" parameter, why not instead change this to select the method used: and have:
>
>       method-event-param = "method" EQUAL ( "head" / "get" )
>
> The default being method=head.  method=get is optionally supported by the server in the same way that body=true is.  Or does this go too far?  (method=trace!)  Does this lead to parameters like accept-content=text/plain ?
>    

It certainly does give implementors a lot more rope to hang themselves 
with. We don't want to imply that shenanigans like "method=post" would 
have any reasonable semantic associated with them. I don't want to 
feature creep ourselves into fully tunneling the HTTP protocol over SIP.

> That does raise a point - there is no way of knowing that the headers received in the notification would match those you would receive by doing your own HEAD request.  This might be worth mentioning - the server can choose any set of request headers it sees fit to use, which might not match the needs of a user.

Ah, that's true. It's not necessarily the whole response; it can be a 
subset. I've changed the intro of 4.5.1 to read:

               The message/http NOTIFY message bodies used in the
               HTTP monitor event package reflect a subset of the
               response that would be returned if the client performed
               an HTTP HEAD operation on the HTTP resource.

And then, immediately after the paragraph following the example message:

               Except for the foregoing normative requirements,
               The decision regarding which HTTP header fields to
               include is at the discretion of the notifier.

> For one, content negotiation is not an option.  And then, maybe that's a good thing ;)  A note that explains this limitation might be helpful.
>    

So, it's not "not an option" per se. It's just not done in the SIP 
mechanism. When you get a "monitor" or "monitor-group" link relation 
from an HTTP server, it's scoped to the entity 
(draft-nottingham-http-link-header defines it as an entity-header field).

For example, an HTTP server may return the following when content 
negotiation results in an English document:

   Link: <sip:[e-mail]>; rel="monitor"
   Content-Language: en

While, for the same resource, it would return the following when content 
negotiation results in a French document:

   Link: <sip:[e-mail]>; rel="monitor"
   Content-Language: fr

Absent this kind of scoping, including "Content-MD5" in the HTTP headers 
would be rather nonsensical.

I'll admit that this ends up being a bit confusing if you're not a 
hardcore HTTP nerd. I've added the following text to the end of section 3:

       These link relations are scoped to a single HTTP entity.  When
       an HTTP resource is associated with multiple entities (for
       example, to facilitate content negotiation), the "monitor"
       and "monitor-group" link relations will generally be different
       for each entity.

> ETag: strong or w/weak?  w/weak isn't of much use
>    

I certainly can see value in using weak tags here. It makes sense to 
leave it up to the application to decide whether to retrieve an entity 
when it is syntactically different from, but semantically equivalent to, 
the previous entity version. For example, a web page editor would care 
about that kind of thing. A simple web browser probably would not.

I'm not sure we really need to say anything about this. I'd like to 
defer as much definition of HTTP stuff to the HTTP spec as possible.

> (but then you use SHOULD, so...)

The change from "MUST" to "SHOULD" was at the request of one of the HTTP 
gurus (Mark Nottingham, if my memory serves). I'm not comfortable enough 
in my HTTP knowledge to push back.

> Nits (ignore as you like):
>
> Despite the mess it makes of sentences, I prefer to talk about sip: URIs and sips: URIs, maybe "sip:" URIs.  Alternatively, talk about SIP URIs to cover both cases.  SIPS URIs implies that there is an acronym "SIPS".
>    

The terminology comes from RFC 3261; section 4 defines: "SIP also 
provides a secure URI, called a SIPS URI."  There are 137 additional 
uses of the terms "SIPS" in 3261.

/a