- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 06 Mar 2014 11:59:05 +0100
- To: HTTP Working Group <ietf-http-wg@w3.org>
Looks good to me.
If we need this in HTTP/2 we better adopt this as WG work item ASAP.
It seems to me that having the framework + the HTTP header field in a
stand-alone document makes sense (even if that doc normatively refs
HTTP/2 and vice-versa). I volunteer to help editing that document if needed.
Editorial nits:
in some places: s/header/header field/
3.1. Proposal: Alternate Services
NOTE: This section can be incorporated into HTTP/2 directly, or it
can be published as a standalone specification. However, if
Section 3.3 is accepted, it will need to be included or referenced
from the spec, since frame type extensibility has been ruled out.
This specification defines a new concept in HTTP, the "alternate
service." When an origin (see [RFC6454] has resources are accessible
s/service."/service"./
s/[6454]/[6454])/
s/has resources are/has resources that/
Therefore, if a client becomes aware of an alternate service, the
client SHOULD use that alternate service for all requests to the
associated origin as soon as it is available, provided that the
security properties of the alternate service protocol are desirable,
as compared to the existing connection.
"is optional" and "SHOULD use" is kind of inconsistent...
Best regards, Julian
Received on Thursday, 6 March 2014 10:59:34 UTC