- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 20 Jan 2017 10:59:57 +1300
- To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
- Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP working group mailing list <ietf-http-wg@w3.org>
On 19 January 2017 at 23:00, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
> Is it correct to interpret this statement to say that Mike's definition of the v parameter (or whatever it turns to be called) is a specialisation of the general case and it's "ordered list" processing is implemented at the required level.
Mike's definition of v= in the quic documents defines the semantics
for a field in a specific context. That definition, in addition to
specifying semantics, can also require that the list form be
understood by implementations.
Another definition for a different tuple of header field and parameter
could also insist in a different definition: maybe that multiple
instances of the same name result in an error of some sort.
It would be good if the common syntax established what is possible.
I'm thinking:
1. multiple values are possible
2. a definition for a specific parameter may forbid the use of
multiple values, (noting further that a sender might not be able to
guarantee that the receiver knows of these rules without some sort of
prior indication that the semantics are known)
3. order {is significant|is not significant|has significance as
defined by the field semantics}
4. where multiple values are accepted specific rules should be
described for handling errors caused by a single parameter, this could
render many different things invalid: just that parameter, all
parameters with the same name, the affected header field value (there
could be multiple comma-separated values), or the entire header field.
By default, only the parameter value is affected.
Or something like that. I might have missed something.
Received on Thursday, 19 January 2017 22:00:30 UTC