Subject: NEW ISSUE: isolate TCP-specific aspects of HTTP

From: Mark Nottingham <[email-masked]>
Date: Tue, 31 Mar 2009 11:22:48 +1100

There's a growing amount of interest in running HTTP in ways other  
than the way it's described as using TCP in RFC2616. This includes the  
ongoing discussion of HTTP-over-SCTP as well as more radical  
approaches such as "reverse HTTP."

To make the specification of such mechanisms easier and less prone to  
error, p1 should be arranged so that TCP-specific connection details  
be isolated from the rest of the specification. An alternate approach  
would be to factor such aspects into a separate draft, but this is  
probably not necessary (i.e., as long as it's easy to identify which  
parts of p1 are overridden, that should be enough).

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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 30 Mar 2009 23:19:29 -0400

> To make the specification of such mechanisms easier and less prone to error,
> p1 should be arranged so that TCP-specific connection details be isolated
> from the rest of the specification. An alternate approach would be to factor
> such aspects into a separate draft, but this is probably not necessary
> (i.e., as long as it's easy to identify which parts of p1 are overridden,
> that should be enough).

I strongly agree with doing this, and I agree that keeping it in the
base doc is fine.  Something like this would work:

== Section [n] - TCP Considerations ==
At the time of this writing, HTTP is used exclusively over TCP [ref].
That need not be the case in future, and implementations SHOULD be
adaptable to other transport-layer protocols underneath HTTP.

When TCP is used, the following apply:
...etc...

== end of Section [n] ==

Yes/no?

Barry

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Mar 2009 09:43:58 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Monday, March 30, 2009 8:19 PM
> To: HTTP Working Group
> Subject: Re: NEW ISSUE: isolate TCP-specific aspects of HTTP
> 

Can we say anything more than "SHOULD be adaptable"?  I don't know it might
mean.

Let's say, for example, my implementation supports running HTTP over SCTP --
what should my implementation do in order to meet that SHOULD?

-d

---

From: Barry Leiba <[email-masked]>
Date: Tue, 31 Mar 2009 13:03:35 -0400

> what should my implementation do in order to meet that SHOULD?

Well, I was just giving a sketch.  The SHOULD be adaptable means --
and perhaps it'd be good to say this more explicitly -- that the
implementation shouldn't be so tied to TCP that it can't accommodate
anything else.  Just as we're trying to isolate the TCP-specific
pieces in the document, the implementations should isolate the
TCP-specific pieces there.

Of course, what you have to do to run over SCTP... would be in an
"SCTP Considerations" section of the document, or in a separate
document that addresses HTTP over SCTP.  I think of the TCP section
being included in the base doc as an acknowledgement that it's the
"mandatory to implement" version, at least for now.

Barry