Re: p2: Considerations for new headers

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