- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 25 Feb 2016 22:38:56 +0100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP WG <ietf-http-wg@w3.org>
On 2016-02-25 22:30, Mark Nottingham wrote: >>> Section 2., paragraph 11: >>> OLD: >>> >>> Alt-Svc MAY occur in any HTTP response message, regardless of the >>> status code. Note that recipients of Alt-Svc are free to ignore the >>> header field (and indeed need to in some situations; see Sections 2.1 >>> and 6). >>> >>> NEW: >>> >>> Alt-Svc MAY occur in any HTTP response message, regardless of the >>> status code. Note that recipients of Alt-Svc MAY ignore the header >>> field (and are required to in some situations; see Sections 2.1 and >>> 6). >> >> This should be reverted; the actual requirements are in Sections 2.1 and 6, and we should not have them in multiple places. > > Agreed. 200. >>> Section 4., paragraph 2: >>> OLD: >>> >>> The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints >>> that do not support this frame can safely ignore it. >>> >>> NEW: >>> >>> The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints >>> that do not support this frame MAY ignore it. >> >> This is IMHO misleading as it is true for any unknown frame. It just follows from <http://greenbytes.de/tech/webdav/rfc7540.html#rfc.section.4.1>: >> >> "Implementations MUST ignore and discard any frame that has a type that is unknown." > > Would adding "as per [RFC7540], Section 4.1" help? "Endpoints that do not support this frame *will* ignore it (as per thee extensibility rules defined in Section 4.1 of [RFC7540])." ? >>> Section 4., paragraph 13: >>> OLD: >>> >>> The ALTSVC frame is intended for receipt by clients; a server that >>> receives an ALTSVC frame can safely ignore it. >>> >>> NEW: >>> >>> The ALTSVC frame is intended for receipt by clients. A device acting >>> as a server MUST ignore it. >> >> I'm ok with this one (but wanted to highlight the new normative requirement). >> >> Best regards, Julian >> >> > > -- > Mark Nottingham https://www.mnot.net/ Best regards, Julian
Received on Thursday, 25 February 2016 21:39:28 UTC