Re: ext#7 / ext#8: multiple alt-svc

On Wed, Jul 2, 2014 at 7:02 PM, Martin Thomson <>
> On 1 July 2014 23:22, Mark Nottingham <> wrote:
>> Martin opened two similar issues:
>> <>
>> <>
>> ... regarding how to handle multiple advertised alternative services.
>> Personally, I'm not sure we need to specify this (see my comments in the
>> What do others think? Martin, any further thoughts?
> I think that we probably need to have text to clarify what each means,
> but it should be relatively simple:
> In both cases, I think that we can say that each advertisement of an
> alternative service adds a new alternative to the set of alternatives
> that is known to the client/recipient.
> Then, when multiple alternatives are present, we let the client choose
> the alternative it likes best.
> Existing alternatives can have properties altered by selecting based
> on the tuple [protocol, host, port] and providing new values for other
> attributes. Here I'm thinking that we enable forcibly expiring an
> alternative by adjusting max-age.
> I'm happy to provide a PR (or three) to this effect.

To me this sounds like a step back compared to DNS SRV records, which offer
priority, weight and ttl. suggests extending by
adding a "q=" parameter. IMHO that proposal is useful.
The selection algorithm can then be specified pretty simply: clients SHOULD
choose randomly one alternate server but it MUST be among the pool having
the highest-priority value.

It can be debated whether clients can retry to a different server requests
not having any side effects, but in that case the algorithm should be
pretty much the same as in the first round, after invalidating the failed

I would not overload max-age however with this task however. If a "q="
parameter can be added, it should be possible to add a "max-age=" parameter
as well, isn't it? Unless the proposal is to define some mechanism to clear
the list of altsvc regardless of any other expiry information.


Received on Thursday, 3 July 2014 05:03:20 UTC