Subject: Re: [hybi] Retitled: Use of Schemes (was: RE: Binary/Text Distinction)

From: "Bob Gezelter" <[email-masked]>
Date: Tue, 23 Aug 2011 07:03:06 -0700

Inaki,

With regards to be supremacy of TCP, that may or may not be so.

One of the factors buttressing TCP is the inertia factor and the
difficulty of migration. If there are significant advantages to a
different underlying protocol, and adoption of the other protocol is a
simple matter of providing an additional DNS record, but no (or minimal)
applications-level changes, it is a different story.

It is often the risk of adoption versus the payoff, as well as the risk
if one is wrong. The attractiveness of what I propose is the
minimization of the costs and the risks. Defining the scheme as a
parameter (or a DNS query) has little real cost, and immense potential
payoffs.

- Bob Gezelter, http://www.rlgsc.com

> -------- Original Message --------
> Subject: Re: Retitled: Use of Schemes (was: RE: [hybi] Binary/Text
> Distinction)
> From: Iñaki_Baz_Castillo <[email-masked]>
> Date: Tue, August 23, 2011 6:28 am
> To: Bob Gezelter <[email-masked]>
> Cc: Brian <[email-masked]>, "[email-masked]" <[email-masked]>, 
> Bjoern Hoehrmann <[email-masked]>, Tobias Oberstein
> <[email-masked]>
> 
> 
> 2011/8/23 Bob Gezelter <[email-masked]>:
> > Inaki,
> >
> > With all due respect, I disagree.
> >
> > The URI RFC (RFC 2396) defines "scheme". There are several relevant
> > passages, but one in particular is in section 1.2, to wit:
> >
> >  " ... Although many URL schemes are named after protocols, this does
> > not
> >   imply that the only way to access the URL's resource is via the named
> >   protocol.  Gateways, proxies, caches, and name resolution services
> >   might be used to access some resources, independent of the protocol
> >   of their origin, and the resolution of some URL may require the use
> >   of more than one protocol (e.g., both DNS and HTTP are typically used
> >   to access an "http" URL's resource when it can't be found in a local
> >   cache). ..."
> 
> It changes nothing (IMHO). Imagine the case in which you send, via
> SMTP/SIP/XMPP/whatever-protocol, a WS request with RURI
> wsc://domain.org, or a WS request with RURI
> ws://domain.org?transport=sctp (assuming both are valid).
> 
> In both cases the server (acting as a really exotic gateway) should
> route the request using WebSocket under SCTP. What I mean is that the
> usage of the URI schema or an URI transport is not the key as the
> result would be the very same.
> 
> Anyhow, I've realized that in HTTP / WS URI's there are not "URI
> params", but just "URI headers", and such headers seem to belong to
> the application level so it would be a bad place for setting such a
> transport indicator.
> 
> 
> > My point was that using the URI scheme to indicate the underlying
> > transport used by a WebSocket protocol connection is very low impact.
> > The actual choice of scheme name is, frankly an irrelevancy. If the
> > trailing "s" has esthetic benefits, one can easily use "wcs:/wcss:" or
> > "wssctp:/wssctps:"; there is no downside to an even longer scheme name
> > (e.g., "websocket-sctp:/websocket-sctp-s:"; note, I do not recall if RFC
> > 2396 permits hyphens, but the point is made regardless).
> 
> > A change in the scheme also permits the least impact on the code that
> > parses inbound URIs at the application level.
> 
> Sure. Even more in HTTP URI's where URI headers (
> ?lalala=foo&lololo=baz ) are "application" data rather than URI's
> properties.
> 
> 
> Anyhow, given the fact that WS is purely oriented to TCP and
> JavaScript, I strongly expect that nobody will care about another
> layer 4 transport for WebSocket within next 20 years.
> 
> 
> Regards.
> 
> 
> -- 
> Iñaki Baz Castillo
> <[email-masked]>