Re: Last Calls

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

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

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


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

Cheers,

Hervé


On 28/11/15 10:20, Julian Reschke wrote:
> Hi there!
>
> I'd like to remind everybody that we have a number of Last Calls ending
> in a few days where I have seen little feedback (to say it politely...).
>
> 1) HTTP WG LC: <https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-09>
>
> 2) In IETF LC:
> <https://tools.ietf.org/html/draft-ietf-httpbis-legally-restricted-status-04>
>
>
> and, also HTTP related:
>
> 3) in IETF LC:
> <https://tools.ietf.org/html/draft-ietf-appsawg-http-problem-01>
>
> Best regards, Julian
>

Received on Friday, 4 December 2015 17:13:58 UTC