W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

alt-svc WG Last Call comments

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 10 Dec 2015 12:58:06 +0100
To: Hervé Ruellan <herve.ruellan@crf.canon.fr>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <566968CE.6020204@gmx.de>
On 2015-12-04 18:13, Hervé Ruellan wrote:
> Hi,
>
> I just read through AltSVC. I found that overall the spec is clear and
> easy to follow.
>
> I've got a few comments over it.
>
> In 2.4, the third paragraphs says that a client can become aware of
> multiple alternative services, citing: "or, an alternative service might
> itself advertise an alternative".
>
> However, due to the invalidation rule, if an alternative service
> advertise an alternative, this new alternative invalidates the previous
> list of alternatives.

...because the response from first alternative service is to be handled 
as if it came from the origin.

> So if you have Origin -> alt1 -> alt2, then you keep only alt2 and don't
> have a list.
> I therefore propose to remove the "or, an alternative service might
> itself advertise an alternative".

Sounds right to me. What do the others think?

> Section 3.1 defines the rule for invalidation. However, in my sense it
> is not crystal clear that it applies also to alternatives discovered
> through the ALTSVC frame.
> I'd suggest adding that the ALTSVC frame is just another way of
> transmitting an Alt-SVC header field, and therefore all the rules
> applying to the header field also apply to the frame.
> We may want to go a step further and say the rules defined for the
> Alt-SVC header field apply to any other possibility of discovering
> alternative services (including those not supported).

Sounds right as well. Any concrete suggestion about what exactly to say 
and where to put it?

> Last, I'd think that an example of frame in section 4 would be useful.

How about an example that's equivalent to the first one in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-alt-svc-latest.html#rfc.section.3.1>?

> I've also sent a few editorial nits as a pull request.

I've processed most of these, except 
<https://github.com/hruellan/http-extensions/commit/fabd0943cde7e8af07f20b74acc2e48ac16e5f3e> 
which affects a normative statement (thus should get more review).

Everybody: we're almost done - please follow up so that we can get this 
to IETF LC as soon as possible.

Best regards, Julian
Received on Thursday, 10 December 2015 11:58:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC