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