Charter revision

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Charter revision

Mark Nottingham-2
Based on the feedback I've seen on-list and discussions with folks about it, I've revised the proposal for our new charter; see below. Please provide timely feedback; I'd like to get this to the IESG soon.

One we get it in place, I'll put out a call for proposals. I'll also publish a review form for people to fill out; it isn't required that people use it, but doing so will help me judge consensus and move forward.

As mentioned before, I've requested two sessions in Paris; one to discuss BIS, and one to discuss this new work. Suitable topics for the latter will be discussing the scope of the work, and any proposals that may have been made by then.

Finally - although it's great to see such interest in the work, we need to focus on the charter now, not specific technology decisions. That will come in time, and we still need to focus on the BIS work. So, please limit this discussion to the charter for the time being.

Thanks,

------8<---------

Hypertext Transfer Protocol Bis (httpbis)
=========================================

 Charter
 Last Modified: 2012-01-28

 Current Status: Active Working Group

 Chair(s):
     Mark Nottingham  <[hidden email]>

 Applications Area Director(s):
     Pete Resnick  <[hidden email]>
     Peter Saint-Andre  <[hidden email]>

 Applications Area Advisor:
     Peter Saint-Andre  <[hidden email]>

 Mailing Lists:
     General Discussion:[hidden email]
     To Subscribe:      [hidden email]
         In Body:       subscribe
     Archive:           http://lists.w3.org/Archives/Public/ietf-http-wg/

Description of Working Group
----------------------------

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 (HTTP/1.1) and move RFC 2817 to Historic status
* A document cataloguing the security properties of HTTP/1.1
* A document that specifies HTTP/2.0 an improved binding of HTTP's semantics
  to the underlying transport.

### HTTP/1.1

HTTP 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 relevant portions of RFC 2817 (in
particular, the CONNECT method and advice on the use of Upgrade), so
that that specification can be moved to Historic status.

In doing so, it should consider:
* Implementer experience
* Demonstrated use of HTTP
* Impact on existing implementations and deployments

### 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.

As such, there is an opportunity to create a new major (non-wire-compatible)
version of HTTP.

To do this, the Working Group will solicit candidates for this work from
the community, to be submitted as Internet-Drafts. Expected focus areas for
candidates include:

* Significantly improved perceived performance in common use cases
  (e.g., browsers, mobile)
* More efficient use of network resources; in particular, reducing the
  need to use multiple TCP connections
* Ability to be deployed on today's Internet, using IPv4 and IPv6, in the
  presence of NATs
* Maintaining HTTP's ease of deployment
* Reflecting modern security requirements and practices

Although proposals are not required to meet all of these goals, it is
expected that the resulting work (if undertaken) will be chartered to meet
them (and therefore, selecting one that meets the majority of them as a
starting point is in everyone's interest).

The Working Group will then select a starting point for the new work based
upon the following criteria:

* Compatibility with HTTP/1.1 semantics; i.e., it must be possible to
  pass through a HTTP/1.1 message with reasonable fidelity
* Broad implementer interest (e.g., from Web browsers, "back-end"
  or "web api" uses of HTTP, servers, intermediaries, CDNs, etc.)

Changes to the existing semantics of HTTP are out of scope in order to
preserve the meaning of messages that might cross a 1.1 --> 2.0 --> 1.1
request chain. However, the resulting effort may define new semantics to
further the goals above, along with suitable extensibility mechanisms for
defining additional semantics.

If the Working Group forms consensus around a proposal, it is expected it will
re-charter to begin work on that document (or set of documents). The resulting
work will be known as "HTTP/2.0", unless the Working Group determines that
this isn't suitable (e.g., for interoperability).

Although work on this new version will begin in parallel with completion of
work on HTTP/1.1, the Working Group will prioritize HTTP/1.1 work until it is
complete.

Goals and Milestones
---------------------

   Done        First HTTP/1.1 Revision Internet Draft

   Done        First HTTP Security Properties Internet Draft

   Feb 2012    Working Group Last Call for HTTP/1.1 Revision

   Feb 2012    Working Group Last Call for HTTP Security Properties
   
   Feb 2012    Call for Proposals for HTTP/2.0

   Apr 2012    Submit HTTP/1.1 Revision to IESG for consideration as a
               Proposed Standard

   Apr 2012    Submit HTTP Security Properties to IESG for consideration as
               Informational RFC

   June 2012   Re-charter to work on HTTP/2.0
----->8----------


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




Reply | Threaded
Open this post in threaded view
|

Re: Charter revision

Robert Collins-3
On Fri, Feb 10, 2012 at 3:21 PM, Mark Nottingham <[hidden email]> wrote:

> Based on the feedback I've seen on-list and discussions with folks about it, I've revised the proposal for our new charter; see below. Please provide timely feedback; I'd like to get this to the IESG soon.
>
> One we get it in place, I'll put out a call for proposals. I'll also publish a review form for people to fill out; it isn't required that people use it, but doing so will help me judge consensus and move forward.
>
> As mentioned before, I've requested two sessions in Paris; one to discuss BIS, and one to discuss this new work. Suitable topics for the latter will be discussing the scope of the work, and any proposals that may have been made by then.
>
> Finally - although it's great to see such interest in the work, we need to focus on the charter now, not specific technology decisions. That will come in time, and we still need to focus on the BIS work. So, please limit this discussion to the charter for the time being.
>
> Thanks,
>
> ------8<---------
>
> Hypertext Transfer Protocol Bis (httpbis)
> =========================================
>
>  Charter
>  Last Modified: 2012-01-28
>
>  Current Status: Active Working Group
>
>  Chair(s):
...

+1

-Rob

Reply | Threaded
Open this post in threaded view
|

Re: Charter revision

Peter Saint-Andre-2
In reply to this post by Mark Nottingham-2
<hat type='AD'/>

On 2/9/12 7:21 PM, Mark Nottingham wrote:
> Based on the feedback I've seen on-list and discussions with folks about it, I've revised the proposal for our new charter; see below. Please provide timely feedback; I'd like to get this to the IESG soon.

In the interest of time, I have placed this on the agenda for the IESG
telechat next week. Naturally, discussion can continue here as well, but
I wanted to begin the process of engaging with the IESG.

Peter

--
Peter Saint-Andre
https://stpeter.im/



Reply | Threaded
Open this post in threaded view
|

Re: Charter revision

Amos Jeffries-2
In reply to this post by Mark Nottingham-2
On 10/02/2012 3:21 p.m., Mark Nottingham wrote:
> Based on the feedback I've seen on-list and discussions with folks about it, I've revised the proposal for our new charter; see below. Please provide timely feedback; I'd like to get this to the IESG soon.
>

+1.

AYJ

Reply | Threaded
Open this post in threaded view
|

Re: Charter revision

Willy Tarreau-3
In reply to this post by Mark Nottingham-2
On Fri, Feb 10, 2012 at 01:21:23PM +1100, Mark Nottingham wrote:
> Based on the feedback I've seen on-list and discussions with folks about it,
> I've revised the proposal for our new charter; see below. Please provide
> timely feedback; I'd like to get this to the IESG soon.
(...)

+1

Willy


Reply | Threaded
Open this post in threaded view
|

Re: Charter revision

Poul-Henning Kamp
In reply to this post by Mark Nottingham-2
In message <[hidden email]>, Mark Nottingham wri
tes:

>Based on the feedback I've seen on-list and discussions with folks about
>it, I've revised the proposal for our new charter; see below. Please
>provide timely feedback; I'd like to get this to the IESG soon.

Here is a counter-proposal, which takes a different approach:

    1. Define the minimal transport primitives all HTTP/2.0 transport
        protocols SHALL offer.

        Something like:
                Client sends request consisting of:
                        Primitive (GET/PUT/POST)
                        Content-metadata (headers)
                        Content-body (zero or more bytes)
                Server returns response consisting of:
                        Response (%03d)
                        Content-metadata (headers)
                        Content-body (zero or more bytes)

        This in effect turns a HTTP request into a high-level IP
        datagram giving the same fundamental advantage that every
        transport from HTTP-over-stone-tablets and up will work.

    2. Define how to deal with transport "value add"

        By "value-add" I'm thinking of stuff like:
           Indication of assumed Session-membership
           Indication of assumed Identity (X-Forward-for)
           Transparency Guarantee (ie: level of guarantee content is unmolested)
           Privacy Guarantee (ie: level of guarantee nobody saw the content)
           Authentification Guarantee (ie: level of guarantee we know who it is)
           Indicative delivery (ie: chunked encoding + optional final status)
           Bandwidth/RTT estimate
           Reverse transactions (server push) (This may need #1 text)
           etc.

        I would deal with these by:
        1) creating a registry for them,
        2) defining transport primitives to request, indicate and
           explore their availability end-to-end.  (TELNET's
           do/dont/will/wont model comes to mind)

    3. Publish "HTTP/2.0 Transport primitives" with the above definitions

    4. Draw a red line through the HTTP/1.1bis documents, to separate
        transport from semantics.

    5. Publish "HTTP/2.0 semantics" With the lefthand side of the red line.
        Possibly only as a document which "blackens out" the transport
        parts of HTTP/1.1bis by cross reference.

    6. Create a HTTP/2.0 transport protocol registry.

    7. Publish "HTTP/2.0 basic transport" which righthand side of the red line.
        This is the HTTP/1.1 style HTTP/2.0 transport, which SHALL be
        very easy to implement for any working HTTP/1.1 code base.
        This doc also defines how one upgrades a HTTP/1.1 TCP connection to
        any TCP based HTTP/2.0 transport protocol from the transport registry.

    6. Publish "HTTP/pre2 vs. HTTP/2.0 interoperability" which defines;

        a) how to move/map HTTP/1.1 content to HTTP/2.0 transports
        b) how to move/map HTTP/2.0 content to HTTP/1.1 transports

    7. Open the floodgates to standardizing other transport protocols.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Reply | Threaded
Open this post in threaded view
|

Re: Charter revision

Mark Nottingham-2
PHK,

This is a detailed work plan, not a way to find agreement on an approach (which is what many people -- including you -- have said they want).

If you have an approach that you think will gain consensus, you're welcome to submit it under the new charter.

Regards,


On 10/02/2012, at 8:10 PM, Poul-Henning Kamp wrote:

> In message <[hidden email]>, Mark Nottingham wri
> tes:
>
>> Based on the feedback I've seen on-list and discussions with folks about
>> it, I've revised the proposal for our new charter; see below. Please
>> provide timely feedback; I'd like to get this to the IESG soon.
>
> Here is a counter-proposal, which takes a different approach:
>
>    1. Define the minimal transport primitives all HTTP/2.0 transport
> protocols SHALL offer.
>
> Something like:
> Client sends request consisting of:
> Primitive (GET/PUT/POST)
> Content-metadata (headers)
> Content-body (zero or more bytes)
> Server returns response consisting of:
> Response (%03d)
> Content-metadata (headers)
> Content-body (zero or more bytes)
>
> This in effect turns a HTTP request into a high-level IP
> datagram giving the same fundamental advantage that every
> transport from HTTP-over-stone-tablets and up will work.
>
>    2. Define how to deal with transport "value add"
>
> By "value-add" I'm thinking of stuff like:
>   Indication of assumed Session-membership
>   Indication of assumed Identity (X-Forward-for)
>   Transparency Guarantee (ie: level of guarantee content is unmolested)
>   Privacy Guarantee (ie: level of guarantee nobody saw the content)
>   Authentification Guarantee (ie: level of guarantee we know who it is)
>   Indicative delivery (ie: chunked encoding + optional final status)
>   Bandwidth/RTT estimate
>   Reverse transactions (server push) (This may need #1 text)
>   etc.
>
> I would deal with these by:
> 1) creating a registry for them,
> 2) defining transport primitives to request, indicate and
>   explore their availability end-to-end.  (TELNET's
>   do/dont/will/wont model comes to mind)
>
>    3. Publish "HTTP/2.0 Transport primitives" with the above definitions
>
>    4. Draw a red line through the HTTP/1.1bis documents, to separate
> transport from semantics.
>
>    5. Publish "HTTP/2.0 semantics" With the lefthand side of the red line.
> Possibly only as a document which "blackens out" the transport
> parts of HTTP/1.1bis by cross reference.
>
>    6. Create a HTTP/2.0 transport protocol registry.
>
>    7. Publish "HTTP/2.0 basic transport" which righthand side of the red line.
> This is the HTTP/1.1 style HTTP/2.0 transport, which SHALL be
> very easy to implement for any working HTTP/1.1 code base.
> This doc also defines how one upgrades a HTTP/1.1 TCP connection to
> any TCP based HTTP/2.0 transport protocol from the transport registry.
>
>    6. Publish "HTTP/pre2 vs. HTTP/2.0 interoperability" which defines;
>
> a) how to move/map HTTP/1.1 content to HTTP/2.0 transports
> b) how to move/map HTTP/2.0 content to HTTP/1.1 transports
>
>    7. Open the floodgates to standardizing other transport protocols.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> [hidden email]         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.

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





Reply | Threaded
Open this post in threaded view
|

Re: Charter revision

Poul-Henning Kamp
In message <[hidden email]>, Mark Nottingham wri
tes:

>This is a detailed work plan, not a way to find agreement on an approach
>(which is what many people -- including you -- have said they want).

It absolutely is, but I find that it is a much better idea to write
abstract based on concrete, than the other way around.

The reason why I responded with my list is that I did not read your
proposed charter as supporting getting from the A we have to the B
we, or at least I, want.

In particular there was no mention of formalizing the semantics/transport
split that gave me an indication that this was to even be a, and
certainly not *the*, major goal.

To me, your charter sounds like the httpbis WG will graft a single new
transport protocol onto HTTP/1.1bis and call it HTTP/2.0.

If I can read it that way, I leve to your imagination what headline
ComputerWorld will put on it.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Reply | Threaded
Open this post in threaded view
|

Re: Charter revision

Julian Reschke
On 2012-02-10 12:14, Poul-Henning Kamp wrote:

> In message<[hidden email]>, Mark Nottingham wri
> tes:
>
>> This is a detailed work plan, not a way to find agreement on an approach
>> (which is what many people -- including you -- have said they want).
>
> It absolutely is, but I find that it is a much better idea to write
> abstract based on concrete, than the other way around.
>
> The reason why I responded with my list is that I did not read your
> proposed charter as supporting getting from the A we have to the B
> we, or at least I, want.
>
> In particular there was no mention of formalizing the semantics/transport
> split that gave me an indication that this was to even be a, and
> certainly not *the*, major goal.
> ...

Actually, it is already a goal for HTTPbis; Parts 2..7 should be
independent of transport.

> To me, your charter sounds like the httpbis WG will graft a single new
> transport protocol onto HTTP/1.1bis and call it HTTP/2.0.
>
> If I can read it that way, I leve to your imagination what headline
> ComputerWorld will put on it.

I would be surprised if they care about technical details like that :-)


Reply | Threaded
Open this post in threaded view
|

Re: Charter revision

Poul-Henning Kamp
In message <[hidden email]>, Julian Reschke writes:
>On 2012-02-10 12:14, Poul-Henning Kamp wrote:

>> In particular there was no mention of formalizing the semantics/transport
>> split that gave me an indication that this was to even be a, and
>> certainly not *the*, major goal.
>> ...
>
>Actually, it is already a goal for HTTPbis; Parts 2..7 should be
>independent of transport.

Yes, and that is a good and nice first step.  But we need to
define the transport primitives to make that a usable reality.

>I would be surprised if they care about technical details like that :-)

You would be surprised if you had any idea how starved they are for
anything at all to publish a story on with a big headline.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Reply | Threaded
Open this post in threaded view
|

Re: Charter revision

Amos Jeffries-2
On 11/02/2012 12:26 a.m., Poul-Henning Kamp wrote:

> Julian Reschke writes:
>> On 2012-02-10 12:14, Poul-Henning Kamp wrote:
>>> In particular there was no mention of formalizing the semantics/transport
>>> split that gave me an indication that this was to even be a, and
>>> certainly not *the*, major goal.
>>> ...
>> Actually, it is already a goal for HTTPbis; Parts 2..7 should be
>> independent of transport.
> Yes, and that is a good and nice first step.  But we need to
> define the transport primitives to make that a usable reality.

Julians point AIUI being that the line is already drawn, the transport
fields already separated. If you disagree on what has been split off
that would be an issue with the bis drafts work.

The charter texts just point loosely at which parts are applicable for
further upgrades in the next cycle of work, and what the goal for fixing
them should be. The part defining transport syntax (part 1, maybe part
2) and making it more reliable+faster. In the other parts we could
change symbol names and maybe remove ABNF special casings, but that is all.

>
>> I would be surprised if they care about technical details like that :-)
> You would be surprised if you had any idea how starved they are for
> anything at all to publish a story on with a big headline.

If only 2.0 had been used instead of 1.1. We could be presenting them
with "engineers plan Web3.0 revolution" ;) . [that is pretty much what
will go to print anyway]

AYJ