Subject: Re: Last Calls

From: Hervé Ruellan <[email-masked]>
Date: Fri, 4 Dec 2015 18:13:27 +0100

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
>

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 9 Dec 2015 11:34:27 +0000

On 04 December 2015 17:13, Hervé Ruellan wrote:

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

It is not clear to me if you have an issue with the invalidation and alternative service offering alternative(s), or just the location of the phrase in 2.4, paragraph 3. I agree it seems odd in the example context but I think that regardless of the invalidation. In certain use cases the invalidation may well be required, so I would prefer to keep it. If the list has some importance, the alternate could/should continue to offer such a list.

> I've also sent a few editorial nits as a pull request.
I've seen this PR (looks good) but not seen a PR about the above suggested removal.

Lucas

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Dec 2015 12:58:06 +0100

> advertise an alternative, this new alternative invalidates the previous

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

> itself advertise an alternative".

Sounds right to me. What do the others think?

> 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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Dec 2015 08:24:32 +1100

> Sounds right to me. What do the others think?

I agree, the context for the statement is wrong, so it becomes misleading.

I think that the intent of the statement is important to preserve
somehow.  Just looking, the second paragraph of 2.4 might be a better
home:

Therefore, if a client becomes aware of an alternative service, the
client SHOULD use that alternative service for all requests to the
associated origin as soon as it is available, provided the alternative
service information is fresh (Section 2.2) and the security properties
of the alternative service protocol are desirable, as compared to the
existing connection.

ADD: An viable alternative service is then treated in every way as the
origin; this includes the ability to advertise alternative services.

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

Section 4 seems right:

An ALTSVC frame is semantically equivalent to receiving an Alt-Svc
header field.  As a result, the ALTSVC frame causes alternative
services for the corresponding origin to be replaced.

Or something like that.  I note that this introduces the question of
ordering guarantees: a header field carried in a HEADERS frame might
not be strictly ordered in relation to the ALTSVC frame that appears
on Stream 0, HTTP/2 being as it is.  That implies a race condition.  I
don't think that it's an important one - anyone who advertises in this
fashion gets what they deserve - but it's something to ponder.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 13 Dec 2015 18:33:11 +0100

On 2015-12-10 22:24, Martin Thomson wrote:
> ...

Sounds good. See <https://github.com/httpwg/http-extensions/issues/125> 
and 
<https://github.com/httpwg/http-extensions/commit/c7aea292e319ad9a110a7d1b5c812035e960880c>.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 13 Dec 2015 18:41:44 +0100

> fashion gets what they deserve - but it's something to ponder.

Now tracked as <https://github.com/httpwg/http-extensions/issues/126>.

Maybe:

"Receiving an ALTSVC frame is semantically equivalent to receiving an 
Alt-Svc header field. As a result, the ALTSVC frame causes alternative
services for the corresponding origin to be replaced. Note that it would 
be unwise to mix use of Alt-Svc header fields with the use of ALTSVC 
frames, as the sequence of receipt might be hard to predict."

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 13 Dec 2015 18:47:11 +0100

> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-alt-svc-latest.html#rfc.section.3.1>?

I note that we do not have frame examples in the HTTP/2 spec, either, 
thus I now lean towards not adding one here (but I'd probably take a 
pull request :-)

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Dec 2015 08:29:18 +1100

On 14 December 2015 at 04:41, Julian Reschke <[email-masked]> wrote:
> services for the corresponding origin to be replaced. Note that it would be
> unwise to mix use of Alt-Svc header fields with the use of ALTSVC frames, as
> the sequence of receipt might be hard to predict."

WFM

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Dec 2015 09:11:53 +0100

>> the sequence of receipt might be hard to predict."

-> 
<https://github.com/httpwg/http-extensions/commit/62a1b0dd6f0a1985ff3691317c260568b1b3fd7a>