Re: Moving forward with HTTP/2.0: proposed charter

Embedded systems is easier stated than direct reference or incorporation of
all listed areas. It made sense for highly scalar processors where each
core unit has its own vectors. In that sense we can then specify at which
level remains stateless or how that paradigm shifts.

On Saturday, August 4, 2012, Mike Belshe wrote:

>
>
> On Sat, Aug 4, 2012 at 1:22 PM, Henrik Frystyk Nielsen <
> henrikn@microsoft.com <javascript:_e({}, 'cvml',
> 'henrikn@microsoft.com');>> wrote:
>
>> Mark
>>
>> Thanks for sending this out! Based on the discussion at the Vancouver
>> meeting and on the mailing list I think there are four items that need
>> explicitly to be clarified in the proposed charter:
>>
>> 1) Clarify the relationship to SPDY, especially the ongoing work on SPDY
>> 3 and the upcoming 4. We don't want to get in a situation with dueling
>> specifications so we have to be clear on there the WG and the SPDY
>> community stand on this. My sense is that as the SPDY spec is used as a
>> starting point we have to roll all new development in under HTTP/2.0 as
>> otherwise we don't know where we stand.
>>
>> 2) Clarify the point made during the WG meeting in Vancouver that because
>> something is in the starting point it doesn't mean that there is consensus
>> around it. That is, there shouldn't be a perception that because something
>> is in that we have to argue whether it should be taken out. It is just as
>> much an argument as to whether something should say in.
>>
>> 3) Clarify that it is the intent of HTTP/2.0 to function as a functional
>> replacement of HTTP/1.1, part 1. That is, it should be possible (in
>> practical and realistic, not theoretical terms) to use HTTP/2.0 in the same
>> scenarios where HTTP/1.1 (and HTTP/1.0) is used today. One group that is
>> missing from the below is embedded systems in which HTTP has a huge role.
>>
>> 4) State that, while not part of the deliverables, given the focus on
>> performance, the WG will continue work on performance evaluation so that we
>> can determine whether something actually improves performance and by how
>> much within the scenarios we are looking at.
>>
>> I have appended comments to clarify these issue in the below text (look
>> for text between $...$)
>
>
>> Thanks,
>>
>> Henrik
>>
>> HTTP/2.0
>> --------
>>
>> There is emerging implementation experience and interest in a protocol
>> that retains the semantics of HTTP without the legacy of HTTP/1.x message
>> framing and syntax, which have been identified as hampering performance and
>> encouraging misuse of the underlying transport.
>>
>> The Working Group will produce a specification of a new expression of
>> HTTP's current semantics in ordered, bi-directional streams. As with
>> HTTP/1.x, the primary target transport is TCP, but it should be possible to
>> use other transports.
>>
>> Work will begin using draft-mbelshe-httpbis-spdy-00 as a starting point;
>> proposals are to be expressed in terms of changes to that document. Note
>> that consensus is required both for changes to the document and anything
>> that remains in the document.
>>
>> $Because something is in the initial document does not imply that there
>> is consensus around the feature or how it is specified.$
>>
>
> I think this was already covered by "consensus is required both for
> changes to the document and anything that remains in the document".
>
>
>>
>> $The outcome of this WG is HTTP/2.0, not SPDY. It is important that there
>> is no confusion about the relationship between HTTP/2.0 and SPDY as we do
>> not want to have dueling specifications in this area.$
>>
>
> There are no dueling specifications.  This working group is working on
> HTTP/2.0.  We can say it again, but it probably doesn't decrease the
> paranoia ;-)
>
>
>>
>> As part of that work, the following issues are explicitly called out for
>> discussion:
>> * A negotiation mechanism that is capable of not only choosing between
>>  HTTP/1.x and HTTP/2.x, but also for bindings of HTTP URLs to other
>>  transports (for example).
>> * Header compression (which may encompass header encoding or tokenisation)
>> * Server push (which may encompass pull or other techniques)
>>
>> $Note that this doesn't mean that no other issues should be brought up.
>> The discussion can and should cover the entire HTTP/2.0 spec$
>>
>
> I think Mark was trying to confine our goals more than this.   Of course
> it is true that things will come up as we go, but it is better if we can
> identify the areas to work on up front.
>
>
>>
>> It is expected that HTTP/2.0 will:
>> * Substantially and measurably improve end-user perceived latency in most
>>  cases, over HTTP/1.1 using TCP.
>> * Address the "head of line blocking" problem in HTTP.
>> * Not require multiple connections to a server to enable parallelism,
>> thus  improving its use of TCP, especially regarding congestion control.
>> * Retain the semantics of HTTP/1.1, leveraging existing documentation
>> (see  above), including (but not limited to) HTTP methods, status codes,
>> URIs, and  where appropriate, header fields.
>> * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in
>>  intermediaries (both 2->1 and 1->2).
>> * Clearly identify any new extensibility points and policy for their
>>  appropriate use.
>>
>> The resulting specification(s) are expected to be meet these goals for
>> common existing deployments of HTTP; in particular, Web browsing (desktop
>> and mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of
>> scales), and intermediation (by proxies, corporate firewalls, "reverse"
>> proxies and Content Delivery Networks).
>>
>> $as well as embedded systems$
>>
>
> I think you're looking for 'reasonableness' - such that HTTP/2.0 works
> with most existing systems.  I am too.
>
> I don't think we need to callout 'embedded systems', as it is already
> covered in "expected to meet these goals for common existing deployments of
> HTTP".  Embedded systems are common today and will naturally be a big part
> of HTTP/2.0.  If we call them out, do we need to start listing all the
> other common uses of HTTP? :-)
>
>
>
>
> Likewise, current and future semantic extensions to HTTP/1.x (e.g.,
> headers, methods, status codes, cache directives) should be supported in
> the new protocol.
>
> $That is, in functional terms, one should consider the goal of this work
> to address parts of HTTP/1.1 part 1 in terms of how the HTTP protocol is
> mapped to message structures as well as to the underlying transport.$
>
> Note that this does not include uses of HTTP where non-specified
> behaviours are relied upon (e.g., connection state such as timeouts or
> client affinity, and "interception" proxies); these uses may or may not be
> enabled by the final product.
>
> Explicitly out-of-scope items include:
> * Specifying the use of alternate transport-layer protocols. Note that it
>  is expected that the Working Group will define how the protocol is used
>  with the TLS Protocol.
> * Specifying how the HTTP protocol is to be used or presented in a
> specific  use case (e.g., in Web browsers).
>
> $While not a direct deliverable of the WG, given the focus on performance,
> it is critical that the WG evaluates how well the proposed features in
> HTTP/2.0 perform within a common set of scenarios. It is expected that the
> WG will take such data into consideration when discussing features.$
>
> The Working Group will coordinate this item with:
> * The TLS Working Group, regarding use of TLS.
> * The Transport Area, regarding impact on and interaction with transport
>  protocols.
> * The HYBI Working Group, regarding the possible future extension of
> HTTP/2.0  to carry WebSockets semantics.
>
> The Working Group will prioritize HTTP/1.1 work until it is complete.
>
> Other HTTP-Related Work
> -----------------------
>
> The Working Group may define additional extensions to HTTP as work items,
> provided that:
> * There is clear consensus to do so, and
> * It does not, in the judgement of the Chair(s), interfere with the work
>  described above, and
> * The Area Director(s) give consent, and add corresponding milestones.
>
> Additionally, the Working Group will not start work on any extensions that
> are specific to HTTP/2.0 until that work is completed.
>
>
> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: Friday, August 03, 2012 1:06 PM
> To: ietf-http-wg@w3.org Group
> Subject: Moving forward with HTTP/2.0: proposed charter
>
> In the second Vancouver session, we discussed the proposals, expressions
> of interest in them, and the proposed charter text sent to the list earlier.
>
> The result of those discussions has been captured in the charter proposal
> below.
>
> Please have a look and discuss, express your support or concern, and of
> course make proposals for any changes that you believe will be able to gain
> consensus. Barring serious problems, I'd like to get it to the ADs in the
> next week.
>
> ---8<---
>
> This Working Group is charged with maintaining and developing the "core"
> specifications for HTTP.
>
> The Working Group's specification deliverables are:
> * A document (or set of documents) that is suitable to supersede RFC 2616
> as  the definition of HTTP/1.1 and move RFC 2817 to Historic status
> * A document cataloguing the security properties of HTTP/1.1
> * A document (or set of documents) that specifies HTTP/2.0, an improved
>  binding of HTTP's semantics to an underlying transport.
>
> HTTP/1.1
> --------
>
> HTTP/1.1 is one of the most successful and widely-used protocols on the
> Internet today. However, its specification has several editorial issues.
> Additionally, after years of implementation and extension, several
> ambiguities have become evident, impairing interoperability and the ability
> to easily implement and use HTTP.
>
> The working group will refine RFC2616 to:
> * Incorporate errata and updates (e.g., references, IANA registries, ABNF)
> * Fix editorial problems which have led to misunderstandings of the
>  specification
> * Clarify conformance requirements
> * Remove known ambiguities where they affect interoperability
> * Clarify existing methods of extensibility
> * Remove or deprecate those features that are not widely implemented and
>  also unduly affect interoperability
> * Where necessary, add implementation advice
> * Document the security properties of HTTP and its associated mechanisms
>  (e.g., Basic and Digest authentication, cookies, TLS) for common
>  applications
>
> It will also incorporate the generic authentication framework from RFC
> 2617, without obsoleting or updating that specification's definition of the
> Basic and Digest schemes.
>
> Finally, it will incorporate relev
>
>
>