Re: [tae] [tsv-area] Transport negotiation

[Bryan Ford <[e-mail]>]

On Dec 8, 2008, at 1:56 PM, Lloyd Wood wrote:
> I'm interested in a parseable way to pass that information down from  
> a URI and the program handling the URI.
>
> Right now, we can explicitly state 'http' or 'https'. These are  
> presumed to live over TCP, and IP - whether to use v4 or v6 is  
> usually determined directly by giving an address or by DNS. But,  
> oddly enough, we can also explicitly specify the port number, which  
> defaults to 80. So, even though http lives on port 80 (and https on  
> 443), that can be overridden in the URI.
>
> Similarly, though http is expected to live over TCP, being able to  
> explicitly override it in the URI if desired has merit in some  
> cases. That is, 'http' would be the same as writing 'http-tcp'.  
> 'http-sctp', for the work outlined in:
> http://tools.ietf.org/html/draft-natarajan-http-over-sctp
> means use a different transport - SCTP instead of TCP.

I don't think transport protocol names belong in URLs, because  
transports are ultimately just tools that application protocols use to  
get stuff from point A to point B; the user doesn't usually and  
shouldn't have to care which tools the application uses to get its job  
done.  Why should the user care whether his web browser is downloading  
his web page via HTTP-over-TCP or HTTP-over-SCTP?  If the point of  
using SCTP is that it makes the parallel HTTP transfers go faster,  
then the behavior you want is that the client and server use SCTP  
whenever both client and server support it, and fall back to TCP  
otherwise.  That behavior should be completely transparent to the end  
user - just like the negotiation of HTTP 1.0 versus HTTP 1.1 is - and  
should have no bearing on what an object is named.  If you start  
encoding SCTP into URLs in web pages, then (as Iljitsch pointed out)  
things quickly start breaking as soon as the "http-over-sctp" URL  
reaches a client that doesn't support SCTP.

While I'm not sure I would necessarly defend the "http" versus "https"  
distinction on architectural grounds, at least that distinction does  
have a direct bearing on the user - i.e., users often do care whether  
they're accessing a particular web site over a "secure" connection or  
not, and the "https" gives them a nice bit of warm fuzzy reassurance  
that they are.  We might have already outgrown this approach, however,  
given that modern web browsers now much more loudly proclaim the  
secure/insecure status of web connections by changing the color of the  
URL bar and adding other fancy ornamentation; they could certainly  
still do those other things to tell the user whether the connection is  
secure or not, even if HTTP and HTTP-over-TLS actually shared the same  
URL scheme name and just negotiated security purely dynamically.

> Doesn't it strike you as odd that we can, at a high uri level,  
> specify the low-level port number, but not the details of the  
> layering to be used for that port? By adding explicit detail in the  
> URI, we are removing ambiguity.

This fact makes perverse sense when we keep in mind the historical  
reality that, as Joe Touch pointed out, the "http" scheme always in  
practice meant specifically "HTTP-(over-no-TLS-because-TLS-wasn't- 
there-yet)-over-TCP" - then it's clear what the port number means.   
But that doesn't mean we necessarily have to accept this state of  
affairs as the architectural Ten Commandments to apply for all time.   
If we try to move forward toward an architectural viewpoint where the  
"http:" scheme name means "HTTP-over-some-unknown-dynamically- 
negotiated-protocol-stack", it indeed becomes a little less obvious  
what exactly the attached "port number" field should mean.   But we  
could envision generalizing it to be a transport-independent "service  
number" of some kind - or even, dare I say, a "service name"?

Cheers,
Bryan

> L.
>
>
> On 8 Dec 2008, at 06:08, Joe Touch wrote:
>>
>> Lloyd Wood wrote:
>>>
>>> On 3 Dec 2008, at 21:07, Stuart Cheshire wrote:
>>>>
>>>> I think the whole notion of "transport negotiation" is flawed.
>>>
>>> agreed. And moving negotiation to 'asking DNS what to do' is just
>>> shifting the problem around.
>>>
>>> At the least, it should be possible to explicitly say 'this is how I
>>> will send' and presume the other end is similarly explicitly  
>>> configured.
>>> No negotiation, period.
>>
>> Isn't that exactly what happens when I send a TCP over IPv4 SYN  
>> segment?
>> I'm saying "I want to use IPv4, using TCP, with the indicated  
>> options,
>> on the given port".
>>
>> The trouble ensues when the initiator is ambiguous about what it  
>> wants -
>> for whatever reason (e.g., to enable alternates at differently- 
>> capable
>> receivers).
>>
>> Joe
>
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
> <http://info.surrey.ac.uk/Personal/L.Wood/><[e-mail]>
>
>
>
>
>
> _______________________________________________
> tae mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tae

_______________________________________________
tae mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tae