Subject: Martin Duke's Yes on draft-ietf-httpbis-semantics-16: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Thu, 10 Jun 2021 13:02:37 -0700

Martin Duke has entered the following ballot position for
draft-ietf-httpbis-semantics-16: 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 DISCUSS and COMMENT positions.

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

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

As someone who has learned HTTP via osmosis, it was very helpful to finally
read it all collected in one place. Thank you. I especially appreciate the
effort to document legacy undesirable behaviors, which implementers need to
account for in their work.

(7.6.3) Via

"If a port is not provided, a recipient MAY interpret that as meaning it was
received on the default TCP port, if any, for the received-protocol."

So if received-protocol is "3", it's a UDP port.

If received-protocol is "1" or "1.1", is the default port 80 or 443? IIUC the
scheme isn't included to determine this.

(7.7) Message Transformations

"A proxy that transforms the content of a 200 (OK) response can inform
downstream recipients that a transformation has been applied by changing the
response status code to 203 (Non-Authoritative Information)"

Why not an normative word, instead of "can"?

(12.5.3) Is it correct that "identity" and having no field value for
Accept-Encoding are synonymous?

"Servers that fail a request due to an unsupported content coding ought to
respond with a 415 (Unsupported Media Type) status"

Why not s/ought to/SHOULD ?

(14.3) Why can only origin servers send "Accept-Ranges: bytes"? Why not
intermediaries?

(15.3.7) "A sender that generates a 206 response with an If-Range header
field"... (13.1.5) leads me to believe that only clients can send If-Range. So
how can there be a response with If-Range?

(15.3.7.2) The last instance of THIS_STRING_SEPARATES has a trailing '--'. If
this is intentional, it ought to be explained.

(16.3.1) says field names SHOULD begin with a letter, but (16.3.2.1) says they
SHOULD begin with "an alphanumeric character". More broadly, the "Field name:"
description in (16.3.1) should probably refer to (16.3.2.1) unless I'm
misunderstanding the scope of these sections.

(17.13) s/TCP behavior/TCP or QUIC behavior

(B) It would be good to mention here that accept-ext has been removed in
(12.5.1), and accept-charset is deprecated in (12.5.2), if that is new to this
spec.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Jun 2021 09:37:34 +1000

I've broken this out into a separate issue because it's a bit subtle: <https://github.com/httpwg/http-core/issues/865>

There are two issues here:

1) The protocol-name doesn't reflect the scheme in use, for HTTPS, it's still 'HTTP'. The practical implication of that is that when HTTPS is used, the port needs to be explicit, even if it's the default for HTTPS. A clarifying note might help here.

2) HTTP/3 uses UDP, not TCP. Omitting 'TCP' from the MAY requirement might help.

Cheers,

> On 16 Jun 2021, at 8:19 am, Martin Duke <[email-masked]> wrote:
> 
> I understand that schemes match to ports, but I believe the via field does not contain the scheme info that would tell you this.
> 
> On Tue, Jun 15, 2021 at 2:35 PM John Scudder <[email-masked]> wrote:
> I think I found the answer to this during my own review. RFC 7230 Sections 2.7.1 and 2.7.2 define the http and https URI schemes, and specify that they have default ports of 80 and 443, respectively. 
> 
> $0.02,
> 
> —John
> 
> > On Jun 10, 2021, at 4:02 PM, Martin Duke via Datatracker <[email-masked]> wrote:
> > 
> > (7.6.3) Via
> > 

--
Mark Nottingham   https://www.mnot.net/