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

From: "Bob Gezelter" <[email-masked]>
Date: Tue, 23 Aug 2011 04:47:46 -0700

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). ..."

Indeed, for many TCP-layered applications level protocols, the scheme
effectively implies (if not identifies) the protocol (e.g., telnet, ftp,
mail-to). The use of a trailing "s" to indicate "secure" is an
historical accident. HTTP/SSL (with the scheme designator https:) got
traction. There was a proposal for Secure HTTP (which, if I recall
correctly, was using the scheme designator "shttp:)

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. In my experience, the
scheme portion of the URI is almost universally ignored, having been
already processed by the client and having come through the designated
network pathway, it has served its purpose.

- Bob Gezelter, http://www.rlgsc.com 
> -------- Original Message --------
> Subject: Re: [hybi] Binary/Text Distinction
> From: Iñaki_Baz_Castillo <[email-masked]>
> Date: Tue, August 23, 2011 4:13 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]>:
> > With regards to SCTP, I have long ago noted that absent the
> > HTTP-specific handshaking and the discrete places where ports 80/443 and
> > their corresponding schemes are specified, there is no technical
> > connection or dependency on TCP (my article this past March noted that
> > one could easily and [emphasis] virtually transparently to the end user
> > [end emphasis] implement the WebSocket protocol over an SCTP transport
> > using a different scheme (e.g., "wsc:/wssc:" instead of "ws:/wss:"). In
> > that way, applications code would only need a small change in URLs
> > (which could be handled by DNS records or redirects), the meat of the
> > work would be in the WSAPI-level code.
> 
> I don't think the URI schema should represent the transport to use.
> When it ends in "s" (wss, sips, https) it means "use security" which
> is not a transport itself, but an extra layer (i.e. TLS) on top of a
> real transport protocol (i.e. TCP, SCTP).
> 
> In case of SIP, the transport is given in a URI parameter:
> 
> 
> 1) Use TCP to contact the destination:
> 
>   sip:[email-masked];transport=tcp
> 
> 
> 2) Use TLS over TCP to contact the destination:
> 
>   sips:[email-masked];transport=tcp
> 
> 
> 
> > With regards to XMPP, if there are assumptions about TCP delivery of
> > data other than a stream, the implementation is certainly severely
> > broken. One of the first things I learned about TCP connections is that
> > any resemblance between packets and the chunks that data is received
> > instantaneously is purely coincidence and cannot be relied upon.
> 
> Sure.
> 
> Regards.
> 
> 
> -- 
> Iñaki Baz Castillo
> <[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 23 Aug 2011 15:28:32 +0200

>   to access an "http" URL's resource when it can't be found in a local

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.

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