W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: p2: Considerations for new headers

From: James M Snell <jasnell@gmail.com>
Date: Thu, 25 Apr 2013 08:38:48 -0700
Message-ID: <CABP7RbeVBRN1qSD2mhJvBXZ41BwnrAkN5VnChV4tOdqvA7MMtA@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
FWIW, I'm comfortable with Mark's suggested text. I think it gets the
point across ok, although it's not entirely clear what "understand a
header field" means. Perhaps it would be better to say that the mere
presence of a new header field cannot compel implementations to take
any specific action. Either way, tho, I can live with Mark's wording.

On Thu, Apr 25, 2013 at 7:41 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
[snip]
>>> Finally, we should add (near the top of the section):
>>>
>>> """
>>> New header fields cannot change the semantics of a message in an
>>> incompatible fashion. That is, it is not possible to require
>>> recipients to understand a header field through its mere presence.
>>> However, new methods and status codes can require the presence of
>>> headers in their definitions, in the scope of the message they occur
>>> within.
>>> """
>>>
>>> Make sense?
>>
>> ...
>
>
> I think the consequences of the first sentence are not totally clear.
>
> - you can set a new header field on a message, but you can not rely on the
> recipient looking at it (because it's "must ignore")
>
> - you could require the presence of a new header field on a request using a
> new method, or on a response using a new status code
>
> ...but then, you could require it in other cases as well (think a new auth
> scheme, a successful upgrade, an applied Preference...).
>
> Not sure how to explain this better...
>
> Best regards, Julian
>
>
>
Received on Thursday, 25 April 2013 15:39:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:12 UTC