Extensions to mapped fields

[mnot]

[ This has been discussed in various other places, but it seemed like a good idea to step back and look at the underlying issue distinctly ]

Consider a future application which relies on structured fields -- let's say an alternative encoding of SF, like BSF.

Each mapped field needs to be translated into a SF by the sending implementation, and (potentially) unmapped into a string representation by the receiving implementation (eg, if it needs to forward it to something that doesn't understand the alternative encoding).

For many mapped fields, this is straightforward; each party just looks up the mapping. However, if the syntax allows future extensions -- for example, Cookie and Set-Cookie -- they may encounter extensions that they don't know how to encode/decode.

A naive strategy for handling this might be to fall back to encoding any extension the sender isn't aware of as a String (for example). However, the recipient may not be aware of the extension, leading to a situation where it doesn't know how to unmap that value back correctly. While in theory the recipient could communicate the extensions it supports to the sender, this is unlikely to be workable in deployment.

To address that concern, I see two possible approaches:

1. Encode all extensions in a manner that is compatible with the existing syntax (e.g., as a String, or Binary). That is not great, in that it removes much of the benefit of SF for those values.
2. Specify that future extensions are required to have valid SF syntax, so that a recieving implementation knows how to unmap them to the correct value. E.g., all future cookie parameters must be specified with SF types.

I suspect that the second strategy is more appropriate when there is a high degree of alignment regarding the use of the extension point, but as it gets more diverse, the first is probably best.

There are three places that this impacts, AFAICT:

1. Cookie/Set-Cookie -- I've had an informal chat with @mikewest and @sbingler (IIRC) about constraining future extensions, but we should reflect that in RFC6265bis explicitly, or change the retrofit approach to Cookies.
2. Authorization/WWW-Authenticate (#2280) -- In Yokohama, we talked about what effectively amounts to the second strategy, but I suspect we should take the first.
3. Link-Template, which is effectively a retrofit for Link -- https://github.com/ietf-wg-httpapi/link-template already requires parameters to be Strings.

Thoughts? Is there another strategy we can take?

cc @reschke @martinthomson

[mnot]

Also this might interest you @davidben

[mnot]

Ping? Anyone?

[reschke]

I believe for http auth, the mapping is complete (or can be made complete), because it only allows token and quoted-string. There's no extension point here.