RE: FW: New Version Notification for draft-bishop-decomposing-http-00.txt

That’s an interesting question, and a great example of why I’m trying to illustrate the lines!  The dedication of one stream to header data for all other streams, and then sending HEADERS frames on that stream to describe other streams initially felt very odd to me.  Why would you have HEADERS frames within a separate QUIC stream, and thereby introduce a second framing layer?  But when I started picking the pieces apart, I realized that was just a part of the mapping of HTTP to QUIC, and it feels more comfortable now.

My intent was to talk about QUIC-as-transport in that section, though QUIC-as-HTTP-mapping gets referenced a lot in other places.  I’d appreciate suggestions on how to clarify that.  I listed it that way because I presume that’s not part of the QUIC that would be available as a generic transport.  That “feels” like a part of the mapping, HTTP over QUIC, especially given the use of HPACK – but I also recognize that’s a very artificial line, given that QUIC currently is an HTTP mapping onto UDP.

Do you think the metadata capability will be generic when carrying non-HTTP traffic?  If so, I’d be happy to update the table – but the use of a separate HEADERS stream (rather than metadata frames on each stream) makes me suspect not.

From: Ryan Hamilton [mailto:rch@google.com]
Sent: Saturday, August 22, 2015 7:37 AM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: ietf-http-wg@w3.org
Subject: Re: FW: New Version Notification for draft-bishop-decomposing-http-00.txt

One quick comment. In section 3, where you enumerate the HTTP semantics provided (or not) by the various HTTP over UDP mappings, QUIC is listed as not supporting separate metadata and payload. But QUIC actually sends HTTP/2 HEADERS frames distinct from the message body. Would you mind updating the table accordingly?

On Fri, Aug 21, 2015 at 4:33 PM, Mike Bishop <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>> wrote:
I started writing this on the way home from Munster, and have incorporated some feedback from a few other folks.  The goal is really to understand the lines between the HTTP semantic layer, the transport, and the "goo" that makes it possible to carry one over the other.  The goal is not merely layering for architectural purity's sake, but modularity.  As we discuss the possibility of layering HTTP over new transports, I think it's useful to understand what parts of the equation are "really" HTTP, and which ones are there simply to provide a service HTTP needs that's missing from the transport.

Feedback, issues, pull requests, etc. are welcome at https://github.com/MikeBishop/http-layering.


-----Original Message-----
From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>]
Sent: Friday, August 21, 2015 4:12 PM
To: Mike Bishop <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>>; Mike Bishop <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>>
Subject: New Version Notification for draft-bishop-decomposing-http-00.txt


A new version of I-D, draft-bishop-decomposing-http-00.txt
has been successfully submitted by Mike Bishop and posted to the IETF repository.

Name:           draft-bishop-decomposing-http
Revision:       00
Title:          Decomposing the Hypertext Transfer Protocol
Document date:  2015-08-21
Group:          Individual Submission
Pages:          12
URL:            https://www.ietf.org/internet-drafts/draft-bishop-decomposing-http-00.txt

Status:         https://datatracker.ietf.org/doc/draft-bishop-decomposing-http/

Htmlized:       https://tools.ietf.org/html/draft-bishop-decomposing-http-00



Abstract:
   The Hypertext Transfer Protocol in its various versions combines
   concepts of both an application and transport-layer protocol.  As
   this group contemplates employing alternate transport protocols
   underneath HTTP, this document attempts to delineate the boundaries
   between these functions to define a shared vocabulary in discussing
   the revision and/or replacement of one or more of these components.




Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat