Re: [hybi] [Uri-review] ws: and wss: schemes

[Mark Nottingham <[e-mail]>]

I really hesitate to wade into what looks like another huge rat-hole.

Using HTTP for XRIs seemed like a good idea because XRI was trying to  
re-invent URIs, and not define a protocol; HTTP gave them a default  
protocol, as it were, in case you ever did want to interact with them.

WebSockets is defining a protocol, and so is a very different case. It  
is definitely not HTTP.

I can't help but feel that if we follow the arguments given in this  
thread, there won't be any need for FTP, or telnet, or any other URI  
schemes; all will be subsumed by HTTP, and eventually we won't need  
any URI schemes at all (because it's HTTP all the way down).

While that's one possible future, I suppose, I think it's pretty far  
off. Certainly, trading off in-URL metadata in the scheme for more in  
the path component (as proposed earlier in this thread) is an ugly  
hack at best. Other extra-URL metadata approaches need to be proven  
(especially around performance issues), as well as accepted by  
implementers, because what's really being proposed is an extra layer  
of protocol discovery on top of WebSockets using HTTP.

As it stands, URIs still have schemes, and we still have mechanisms  
for defining new ones. If folks want to argue that we shouldn't, the  
best way to do that would be to get a standards-track document that  
obsoletes the relevant RFCs, rather than blocking individual  
registrations.

Cheers,

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