Subject: p2: Considerations for new headers

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Apr 2013 18:03:07 +1000

We should consider adding the following to the laundry list of considerations in p2 8.3.1:

* Whether the field should be stored by origin servers that understand it upon a PUT request.

Furthermore, I think we should change:

* How the header field might interact with caching (see [Part6]).

to:

* When the header is used in requests and affects response selection [ref], it is good practice to advise listing that header in the Vary response header [ref].

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?

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Apr 2013 10:06:39 +0200

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

Sounds good to me.

Best regards, Julian

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 24 Apr 2013 09:20:38 +0100

Looks good to me as well.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Apr 2013 16:41:46 +0200

>> * Whether the field should be stored by origin servers that understand

<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2227>

>> * When the header is used in requests and affects response selection
>> [ref], it is good practice to advise listing that header in the Vary
>> response header [ref].

<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2227> (slightly 
rephrased).

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

---

From: James M Snell <[email-masked]>
Date: Thu, 25 Apr 2013 08:38:48 -0700

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 <[email-masked]> wrote:
[snip]
> - 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...).
>