RFC 7230 A transfer-parameter of q should not be allowed

[daurnimator]

Continuing from http://www.rfc-editor.org/errata/eid4683

In the current spec, nothing is said about how to handle transfer-parameters.
Notably, nothing is said about the case sensitivity of the parameter key.

This results in a conflict with the TE header: if you see a "q" token,
you cannot know if it is a transfer-parameter vs a t-ranking.

It is noted that the "q" token is case insensitive in section 4.3.

When multiple transfer codings are acceptable, the client MAY rank
the codings by preference using a case-insensitive "q" parameter

[reschke]

See https://www.rfc-editor.org/errata/eid4683

[reschke]

OK. An edge case of an edge case.

Note that among the currently registered transfer codings, none defines parameters.

Drastic options might be:

1. Disallow parameters on transfer codings (and thus also on content codings)
2. Remove quality values on transfer coding negotiation.

More realistic:

• in the registration procedure for content/transfer codings, note that a parameter "q" is discouraged (forbidden) due to the ambiguity in "TE".

Should I make a proposal for this?

[reschke]

Actually, we have a similar situation for Accept:; see https://greenbytes.de/tech/webdav/rfc7231.html#header.accept:

Note: Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters in Accept. Future media types are discouraged from registering any parameter named "q".

[daurnimator]

Not only "q" but also "Q": case sensitivity isn't mentioned for transfer parameters.