Re: Multiple Alt-Svc parameters of the same type

[Martin Thomson <[e-mail]>]

I didn't mention this earlier, but I was wondering if it would be
easier all around if we just renamed this from "v" to "quic" and made
the semantics clearer.

I don't much like Mike's proposal with its multiple variant encodings
either.  I proposed a simple numeric value (I chose hex, but decimal
works fine), which is adequate.  I was concerned about the complexity
of the encoding, but now we have two encodings, one of which is
complex.

As far as multiple parameters go, it doesn't matter what the generic
rules are as long as the specific ones are correct.

On 17 January 2017 at 05:48, Lucas Pardue <[e-mail]> wrote:
> Hello all,
>
> The “v” Alt-Svc parameter has seen some use in the wild, namely Google services offering the “quic” alternative service. To date this parameter was not defined anywhere but took the form of a comma-separated list of numbers e.g.
>
> Alt-Svc: quic=":443”; v="35,34"
>
> Mike Bishop is giving an official definition of the Alt-Svc “v” parameter, as part of https://tools.ietf.org/html/draft-ietf-quic-http-01#section-2.1, which is different than Google’s previous usage.
>
>> When multiple versions are supported, the "v" parameter MAY be
>> repeated multiple times in a single Alt-Svc entry.  For example, if a
>> server supported both version "Q034" and version 0x00000001, it would
>> specify the following header:
>
>> Alt-Svc: hq=":443";v="x1";v="cQ034"
>
>> Where multiple versions are listed, the order of the values reflects
>> the server's preference (with the first value being the most
>> preferred version).
>
> This got me thinking, RFC 7838 doesn’t seem to give any direction on the handling of multiple parameters of the same type. For example, is it OK for a server to generate multiple “persist” parameters perhaps with different values, how should a client deal with that? Perhaps I’m worrying too much.
>
> I wondered if the Alt-Svc parameter IANA registry could use some new columns to define the allowed multiplicity of each parameter, and an indication of how to treat the ordering. Any thoughts?
>
> Regards
> Lucas
>
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------