Subject: [sip-http-events] Draft comments

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 2 Dec 2009 14:27:46 +0800

Hi Adam,

This is my first reading of the draft, and I'm a recent subscriber to the list, so please excuse any stupid comments that have come before.

The draft seems reasonably complete to me.  You've covered most of the problems that I thought of.  I kept thinking of new problems, only to discover that they'd been addressed.

--

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.

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.

I doubt that sip: and sips: URIs would be used in other types of relation in the same fashion.  sip: and sips: cover a lot of ground.

It's probably best to be able to limit this specification to the one type of link relation so that this behaviour is only invoked where it is appropriate.  For example the "help" relation type might have a different semantic entirely - it could include a sip[s]: URI that could be used to place a call for user support (a terrible example, but I hope you catch my drift).

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.

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

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 ?

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

ETag: strong or w/weak?  w/weak isn't of much use (but then you use SHOULD, so...)

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

Cheers,
Martin

---

From: Adam Roach <[email-masked]>
Date: Wed, 02 Dec 2009 10:49:44 -0600

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

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

>     support the HTTP Link:<snip>... These requirements are not intended to

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

> 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 acc…

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

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

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 3 Dec 2009 07:41:38 +0800

Hi Adam,

Thanks for the update and the response.

I had missed the entity-header bit in the link-header draft.  It makes very little fuss about it.

Missing this, I had made the wrong assumption, particularly in light of comments like this:

   By default, the context of a link conveyed in the Link header field
   is the IRI of the requested resource.
         -- draft-nottingham-http-link-header, Section 5.

... which could be construed to imply the opposite, despite the fact that this paragraph is actually talking about the base URI (IRI).

Your suggested text below is useful, but I wonder if this isn't something that the link header draft also needs more on.  The term "entity-header" is used without fanfare, despite it being a critical part of the header definition.

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

>    Link: <sip:[email-masked]>; rel="monitor"
...
>        and "monitor-group" link relations will generally be different

(On weak ETags...)
> in my HTTP knowledge to push back.

SHOULD is absolutely correct.  2616 doesn't force a server to create an ETag.  A server doesn't always provide these, sometimes because it can't (or decides that it can't).  A weak ETag isn't as good as a strong one, but it's better than none.

--Martin