[sip-http-events] Draft comments

["Thomson, Martin" <[e-mail]>]

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