- From: Dan Wing <dwing@cisco.com>
- Date: Tue, 31 Mar 2009 09:43:58 -0700
- To: "'Barry Leiba'" <barryleiba@computer.org>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
> -----Original Message----- > From: ietf-http-wg-request@w3.org > [mailto:ietf-http-wg-request@w3.org] 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 > > > 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? 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
Received on Tuesday, 31 March 2009 16:44:40 UTC