- 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