- From: Kinkie <gkinkie@gmail.com>
- Date: Thu, 3 Jul 2014 07:02:52 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CA+Y8hcNbF23MCvTj5O4xyig_EjX0FD=qwK6oHsS42QbYq_EOng@mail.gmail.com>
On Wed, Jul 2, 2014 at 7:02 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 1 July 2014 23:22, Mark Nottingham <mnot@mnot.net> wrote: >> Martin opened two similar issues: >> <https://github.com/httpwg/http-extensions/issues/7> >> <https://github.com/httpwg/http-extensions/issues/8> >> >> ... regarding how to handle multiple advertised alternative services. >> >> Personally, I'm not sure we need to specify this (see my comments in the issues). >> >> 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. https://github.com/httpwg/http-extensions/issues/7 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 server(s). 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. -- Francesco
Received on Thursday, 3 July 2014 05:03:20 UTC