Subject: Multiple Alt-Svc parameters of the same type

From: Lucas Pardue <[email-masked]>
Date: Mon, 16 Jan 2017 16:48:49 +0000

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.

---------------------

---

From: Kari Hurtta <[email-masked]>
Date: Mon, 16 Jan 2017 20:18:23 +0200 (EET)

> 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.

Bad example, I think.

https://tools.ietf.org/html/rfc7838#section-3.1

|   This specification only defines a single value for "persist".
|   Clients MUST ignore "persist" parameters with values other than "1".

I think that 
	persist=1 
and 
	persist=1;persist=1

are equivalent. And all other persists values are ignored.

( Although it also make sense treat that same way than unknown 
  parameter values. )

But betetr question is, what client should do
when there is several "ma" paramater values.

https://tools.ietf.org/html/rfc7838#section-3.1

|   Syntax:
|
|   ma = delta-seconds; see [RFC7234], Section 1.2.1
|
|   The delta-seconds value indicates the number of seconds since the
|   response was generated for which the alternative service is
|   considered fresh.

There is only

|   This specification defines two parameters: "ma" and "persist",
|   defined in Section 3.1.  Unknown parameters MUST be ignored.  That
|   is, the values (alt-value) they appear in MUST be processed as if the
|   unknown parameter was not present.

Because this is not defined all of these make sense

∙ Pick first value
∙ Pick last value
∙ Pick smallest "ma" value
∙ Pick largest "ma" value
∙ Treate that as unknown parameter
∙ Consider alternative service as invalid because 
  max-age is unclear

/ Kari Hurtta

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 16 Jan 2017 18:31:20 +0000

Hi Kari,

Thanks for spotting the obvious mistake on my part. Your "ma" examples much better illustrate my thoughts on this.

Lucas

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Kari Hurtta
> Sent: 16 January 2017 18:18
> To: Lucas Pardue <[email-masked]>
> Cc: HTTP working group mailing list <[email-masked]>; Kari Hurtta
> <[email-masked]>
> Subject: Re: Multiple Alt-Svc parameters of the same type
> 
> > parameters perhaps with different values, how should a client deal
> > with that? Perhaps I’m worrying too much.
> 
> Bad example, I think.
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Jan 2017 11:59:30 +1300

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.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Jan 2017 12:04:26 +1300

> ∙ Consider alternative service as invalid because

That would seem to be a problem with all header definitions.  I opened
an issue on this point a while back here:
https://github.com/httpwg/http-extensions/issues/281

In this specific case, I don't know what the answer is.  Yay.

---

From: Mike Bishop <[email-masked]>
Date: Mon, 16 Jan 2017 23:39:50 +0000

Certainly open to suggestions on how to simplify.  The "complex" encoding simply allows for things which can be represented in four characters instead of eight to do so.  It just feels a little unwieldy to make things like Q034 render as "51303334".

However, looking at it again, I note that while the *text* says no percent-encoding, the commend in the ABNF still says it's there.  Fixed that.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, January 16, 2017 3:00 PM
To: Lucas Pardue <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: Multiple Alt-Svc parameters of the same type

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.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Jan 2017 13:36:48 +1300

On 17 January 2017 at 12:39, Mike Bishop <[email-masked]> wrote:
> It just feels a little unwieldy to make things like Q034 render as "51303334".

It depends on what you think is more unwieldy, having code to identify
and switch on cQ034 or the extra octets for non-standard versions.
Keep in mind that the ultimate version we're going to ship will just
be "1".

Note also, you probably don't need the quotes either.  Quoting is nice
if you have odd characters, but none of the forms have it.  I think
that we're supposed to accept them and strip them off because that's
the generic syntax, but that's really unclear.

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 19 Jan 2017 10:00:20 +0000

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

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.

In a subsequent email,

> That would seem to be a problem with all header definitions.  I opened an
> issue on this point a while back here:

It looks like my concern is not "new", it is good to see that there is already an issue capturing this.

In separate GitHub discussion, I saw you recommend that we move away from the style v="35,34" as that requires a micro-syntax definition for each parameter. I agree and it would seem to be better to address the issue in a more reusable way.

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.
-----------------------------

---

From: Martin Thomson <[email-masked]>
Date: Fri, 20 Jan 2017 10:59:57 +1300

> 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" proces…

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.