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

"Thomson, Martin" <Martin.Thomson@andrew.com> Wed, 02 December 2009 23:41 UTC

Return-Path: <Martin.Thomson@andrew.com>
X-Original-To: sip-http-events@core3.amsl.com
Delivered-To: sip-http-events@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3ED3A68FF for <sip-http-events@core3.amsl.com>; Wed, 2 Dec 2009 15:41:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.442
X-Spam-Level:
X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqSC5DZwx0PK for <sip-http-events@core3.amsl.com>; Wed, 2 Dec 2009 15:41:11 -0800 (PST)
Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 08F3E3A68D9 for <sip-http-events@ietf.org>; Wed, 2 Dec 2009 15:41:07 -0800 (PST)
Received: from [10.86.20.102] ([10.86.20.102]:53565 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S117449AbZLBXk6 (ORCPT <rfc822; sip-http-events@ietf.org>); Wed, 2 Dec 2009 17:40:58 -0600
Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 2 Dec 2009 17:40:57 -0600
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 3 Dec 2009 07:40:56 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: Adam Roach <adam@nostrum.com>, Mark Nottingham <mnot@mnot.net>
Date: Thu, 3 Dec 2009 07:41:38 +0800
Thread-Topic: Draft comments: entity-header
Thread-Index: Acpzb3mBI34k3oUKS6OZFdUvTAYEnAANkO7A
Message-ID: <8B0A9FCBB9832F43971E38010638454F01D656C8D0@SISPE7MB1.commscope.com>
References: <8B0A9FCBB9832F43971E38010638454F01D656C7EB@SISPE7MB1.commscope.com> <4B169AA8.5020208@nostrum.com>
In-Reply-To: <4B169AA8.5020208@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
Cc: "sip-http-events@ietf.org" <sip-http-events@ietf.org>
Subject: Re: [sip-http-events] Draft comments: entity-header
X-BeenThere: sip-http-events@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP HTTP Events <sip-http-events.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip-http-events>, <mailto:sip-http-events-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-http-events>
List-Post: <mailto:sip-http-events@ietf.org>
List-Help: <mailto:sip-http-events-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-http-events>, <mailto:sip-http-events-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2009 23:41:11 -0000

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:monitor-this-page-in-english@example.com>; 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