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

From: Salvatore Loreto <[email-masked]>
Date: Wed, 01 Apr 2009 15:00:25 +0300

a solution could be include in a Transport Layer section all the 
TCP-specific connection details
and then in a separate document specifying a mechanism for usage of SCTP 
as the transport mechanism for
HTTP (similar to what has been done in SIP with RFC4168)

Sal

Barry Leiba wrote:
>> 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?
>>     
>
> 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
>
>

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 4 Apr 2009 04:21:10 +0100

Barry Leiba wrote:
> == Section [n] - TCP Considerations ==
> At the time of this writing, HTTP is used exclusively over TCP [ref].

Actually it isn't.  HTTP has been used over UDP, for UPNP for years,
and recently proposed for SOAP.

-- Jamie

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 Apr 2009 16:03:04 +1000

Now #156 (editorial):
   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/156

On 31/03/2009, at 11:22 AM, Mark Nottingham wrote:

> 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/
>
>

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