Re: HTTP -> Messages -> Transport factoring

Hi Mark,

On Thu, Apr 05, 2012 at 11:46:28AM -0500, Mark Nottingham wrote:
> 
> It seems like a set of deliverables for us could then be:
> 
> 1. A format for HTTP messages that shows how to get one into a set of bits, but doesn't show how to get those bits onto a transport protocol
> 2. A specification of how to get those messages across a reliable, in-order, not-multiplexed transport 
> 3. Details of #2 on TCP
> 
> leaving the specification of #2 on other suitable transports for future / other work, as well as leaving #1 on multiplexed transport for future / other work.
> 
> How do people feel about this? In particular, is the separation between #2
> and #3 necessary and good?

I was not sure I correctly parsed this question the first time :-)

The separation is useful but not mandatory. Right now HTTP is being used
a lot at least on UNIX stream sockets between processes on a same system,
because UNIX sockets work exactly like TCP sockets except you don't have
IP:port at each end, and they're much cheaper. I'm saying that the separation
is not mandatory because till now, HTTP was spec'd to run on top of TCP and
had no issue being ported to UNIX sockets, so I think that TCP is an appropriate
model for the target eventhough it will probably not be the only one in the
field.

Leaving #2 would be too hard an exercice for the first round in my opinion, but
should be kept in mind for future work.

> Does anyone want to attempt more in this WG (I'm hearing many people saying "no")?

I'd say "no", we already have enough work for a first draft here.

Regards,
Willy

Received on Thursday, 5 April 2012 19:35:03 UTC