W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Ben Campbell's Yes on draft-ietf-httpbis-alt-svc-13: (with COMMENT)

From: Ben Campbell <ben@nostrum.com>
Date: Tue, 01 Mar 2016 19:20:58 -0800
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-httpbis-alt-svc@ietf.org, "Mike Bishop" <michael.bishop@microsoft.com>, httpbis-chairs@ietf.org, michael.bishop@microsoft.com, ietf-http-wg@w3.org
Message-ID: <20160302032058.20029.17891.idtracker@ietfa.amsl.com>
Ben Campbell has entered the following ballot position for
draft-ietf-httpbis-alt-svc-13: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-alt-svc/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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).
Received on Wednesday, 2 March 2016 03:21:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC