Skip to main content

HTTP Alternative Services
RFC 7838

Yes

(Barry Leiba)

No Objection

Alvaro Retana
(Alia Atlas)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Terry Manderson)

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

Alvaro Retana
No Objection
Alissa Cooper Former IESG member
Yes
Yes (2016-02-25 for -12)
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.
Barry Leiba Former IESG member
Yes
Yes (for -12)

                            
Ben Campbell Former IESG member
Yes
Yes (2016-03-01 for -13)
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).
Spencer Dawkins Former IESG member
Yes
Yes (2016-03-02 for -13)
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.
Alia Atlas Former IESG member
No Objection
No Objection (for -13)

                            
Benoît Claise Former IESG member
No Objection
No Objection (2016-03-03 for -13)
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).
Brian Haberman Former IESG member
No Objection
No Objection (for -12)

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -12)

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -13)

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -13)

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -12)

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2016-03-01 for -12)
- 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?
Terry Manderson Former IESG member
No Objection
No Objection (for -13)