HTTP Alternative Services
RFC 7838

Note: This ballot was opened for revision 12 and is now closed.

(Ben Campbell) Yes

Comment (2016-03-01 for -13)
No email
send info
Just a few minor comments:

= Substantive =

- 2.2, last paragraph:

Why might a client choose not to to remove non-persistent alternatives from cache on a network change? (i.e., why not MUST)?

- 2.4, first 2 paragraphs:

These paragraphs seem to be equivalent to saying “Clients MAY use alternative services; also they SHOULD.”  Or is the intent that, if a client uses alternative services, it SHOULD do so under these conditions?

= Editorial =

- 2.3, first paragraph:
I find "MUST only" constructions to be confusing and sometimes ambiguous due to the implied NOT. I suggest making that explicit:
OLD
   A client MUST only use a TLS-based alternative service if the client also supports TLS Server Name Indication (SNI).
NEW
   A client MUST NOT use a TLS-based alternative service unless the client supports TLS Server Name Indication (SNI).

Alissa Cooper Yes

Comment (2016-02-25 for -12)
No email
send info
Couple of places where the language used was confusing for me:

= Sec 2.4 =

s/it can be used until the alternative connection is established./the existing connection can be used until the alternative connection is established./

= Sec 3.1 =

OLD
Unknown parameters MUST be ignored, that is
   the values (alt-value) they appear in MUST be processed as if the
   unknown parameter was not present.

NEW
Unknown parameters MUST be ignored. That is,
   the values (alt-value) in which they appear MUST be processed as if the
   unknown parameters were not present.

(Spencer Dawkins) Yes

Comment (2016-03-02 for -13)
No email
send info
A couple of very nitty nits.

In this text

   When the protocol does not explicitly carry the scheme (e.g., as is
   usually the case for HTTP/1.1 over TLS, servers can mitigate this
                                         ^
I think there's a missing closing parenthesis right around here.

If there's not, I'm having trouble parsing the sentence.
                                         
   risk by either assuming that all requests have an insecure context,
   or by refraining from advertising alternative services for insecure
   schemes (such as HTTP).
   
If there was an obvious reference for SPDY in this text

   The Alt-Svc header field was influenced by the design of the
   Alternate-Protocol header field in SPDY.
   
that might be useful to include.

Barry Leiba Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Comment (2016-03-03 for -13)
No email
send info
A clear sentence such as this one would have helped me:
OLD:
   This specification defines a new concept in HTTP, "Alternative
   Services", that allows an origin server to nominate additional means
   of interacting with it on the network.  
NEW:
   This specification defines a new concept in HTTP, "Alternative
   Services", applicable to both HTTP 1.1 and HTTP 2.0, that allows 
   an origin server to nominate additional means of interacting with 
   it on the network.  

I overlooked this info in the following sentence, i.e. the fact that HTTP header = HTTP 1.1:

   It defines a general
   framework for this in Section 2, along with specific mechanisms for
   advertising their existence using HTTP header fields (Section 3) or
   HTTP/2 frames (Section 4), plus a way to indicate that an alternative
   service was used (Section 5).

(Stephen Farrell) No Objection

Comment (2016-03-01 for -12)
No email
send info
- If TLS1.3 continues to have 0rtt replayable early-data,
could that interact badly with Alt-Svc? Or what about
false-start? For example, if such a combination meant that an
otherwise functional replay detection scheme would fail to
spot a replay that would be bad. This is not a DISCUSS, as
neither TLS1.3 nor false-start are formally "done" so blocking
this for that reason would be "odd";-) However, both are
implemented or will be, so I would love to chat about it and
that might lead to some new security considerations text, here
or in a TLS document.

- Does this still all work for opportunistic security for
HTTP? If not, why not? Note: I'm not asking if the WG have
reached consensus on oppo, rather I'd like to be reassured
that if they do, this will still work for that. I think that's
all ok, though, right?

- section 3: with "clear" you say alternatives are to be
invalidated. Does that mean anything about cached resources? I
assume not, but just checking.

- section 5: I wondered why you didn't include the ALPN
identifier here?

- 9.2: What does "might also choose" mean and which "other
requirements" have you in mind? That's very vague.

- 9.5: What are you telling me with the last para?

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Terry Manderson) No Objection

Alvaro Retana No Objection

(Martin Stiemerling) No Objection