- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 6 Mar 2014 11:19:45 +0000
- To: "Julian F. Reschke" <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
What do other folks think about this? Personally, I’m OK either way, although it may be more expedient to keep it separate (i.e., only move over the frame type and other HTTP/2 specific bits). Thanks for the offer Julian, I may take you up on that. Or, should I say, MAY. Cheers, On 6 Mar 2014, at 10:59 am, Julian Reschke <julian.reschke@gmx.de> wrote: > 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 > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 6 March 2014 11:20:10 UTC