Re: [sip-http-events] Draft comments: entity-header

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

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


(On weak ETags...)
> > (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.

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