Re: [Uri-review] URI scheme registration request

[Graham Klyne <[e-mail]>]

FWIW, opining here as as designated scheme reviewer for IANA:

Ted is right about the low bar to encourage provisional registration.  But I'm 
noting the discussion and am minded to request a note added to the registration 
(when it happens) to the effect that the multiplicity of URI scheme names is not 
without controversy, and that this should be noted if there is a subsequent 
request to advance to permanent registration of the schemes.

I hope that the submitter will note the comments made here and consider the 
extent to which the multiple schemes are needed to serve the goals of longer 
term interoperability of systems that use them.

#g
--


On 02/12/2015 16:39, Ted Hardie wrote:
> On Tue, Dec 1, 2015 at 1:12 PM, Roy T. Fielding <[e-mail]> wrote:
>
>>
>>
>> I still don't see what the purpose is for all these new schemes.  Yes,
>> provisional should have a low bar, but there
>> should at least be an indication that each scheme being registered
>> provides new identifiers.
>>
>>
> ​Roy, I understand your preference, but using different schemes to indicate
> different protocol mechanics instead of different identifiers has certainly
> been done in the past; RFC 3981 is one example.
>
> Given that we're trying to encourage provisional registration by making it
> a low bar, I don't think blocking on something that we've done in standards
> track documents is appropriate.​  There's certainly nothing in RFC 7595's
> guidelines for provisional registrations that would suggest we should block
> on this.
>
> If this is intended to be an interim step toward permanent registration,
> then I'm sure the feedback will be considered.
>
> regards,
>
> Ted
>
>
>
>
>
>> For example, the +ws(s) identifiers appear to just be an alias of ws and
>> wss.  Aliases are bad.
>> rr and rr+cloud are being defined as aliases = VERY BAD.  There is no
>> reason to do that.
>>
>> *TCP Transport*
>>
>> ·         rr+tcp – Standard TCP communication
>> ·         rrs+tcp – TLS TCP communication
>>
>> The TCP Transport operates by connecting to a remote port and then using
>> the Robot Raconteur protocol to communicate.  The official listen port is
>> 48653.  The path must be “/” or empty. The first handshake contains the
>> target nodeid and/or nodename to identify which node should be connected.
>>   Both can be blank to connect to the default node on the endpoint.  The
>> communication can be wrapped in TLS using Start TLS semantics.  The first
>> message contains the target nodeid and/or nodename and a flag to start
>> using TLS.  The server node then provides a certificate signed by Wason
>> Technology, LLC issued to the UUID (nodeid) of the node.  The client can
>> also provide a signed certificate to provide certificate based
>> authentication.
>>
>> Discovery for TCP is accomplished through UDP packets that are broadcast
>> periodically on port 48653.  The packets contain the nodeid, nodename,
>> the connection URI, and some additional metadata to help identify the
>> capabilities.  The information is generally only used to connect to the
>> “Service Index” that runs on all nodes.  This index provides detailed
>> information about the services available and how to connect.  The clients
>> will interrogate the nodes through the Service Index to determine if the
>> node matches the search criteria.  During this process it will also
>> verify the TLS certificates if appropriate.
>>
>>
>> Okay, it sounds like you have two identifiers: one for the service index
>> and one for the node within that service.
>> Why don't you use two URIs: one for identifying the service index (defines
>> the protocols necessary to get there)
>> and one for a single rr scheme that identifies the rr node ("/" being the
>> index itself)?
>>
>> Also, TLS implies TCP.  For most schemes, the bare name is TCP and {name}s
>> is TLS.  So, rr and rrs, or
>> raconteur and raconteurs if you want to be more descriptive.  Using plain
>> rr to indicate the WebRTC
>> transport is very odd.
>>
>> *WebSocket Transport*
>>
>> The WebSocket transport is an extension to the TCP transport and in the
>> software is directly integrated into the TCP transport.  It works by
>> wrapping the TCP transport data into WebSocket binary frames. The frame
>> boundaries are ignored as the stream is reassembled on the receiving end.
>>   The frames however shall be equal to or less than 4 KB of data per frame.
>>
>>
>> The transport also implements the HTTP handshake to start the WebSocket
>> protocol using the subprotocol “robotraconteur”. The URI contains the path
>> to the WebSocket and query information, both of which are passed unmodified
>> to the server. The URI must contain a query parameter named “service” to
>> identify the name of the service to connect.
>>
>> All nodes that listen for TCP connections shall also be capable of
>> detecting and accepting an HTTP WebSocket connection to the root file path
>> “/” on the same port that listens for standard Robot Raconteur connections.
>> This allows for standard web browsers to connect without additional
>> plugins. (Note that HTTPS (wss) is not possible in this configuration. See
>> below.)
>>
>> TLS is somewhat complicated with WebSockets due to the handshake behavior.
>>    There are four flavors of WebSocket connections:
>>
>> ·         rr+ws – No encryption (HTTP)
>> ·         rrs+ws – Encryption using the TLS Robot Raconteur transport.  This
>> does not encrypt the HTTP handshake.  For local network use connecting to
>> a device this should be sufficient as the handshake only contains the
>> target nodeid/service information which is not considered secret data. Just
>> after the handshake the Robot Raconteur TLS layer is activated protecting
>> any secret data. (HTTP)
>> ·         rr+wss – Encrypted HTTPS transport but no Robot Raconteur
>> encryption.  Not recommended because the target node identity is not
>> verified. (HTTPS)
>> ·         rrs+wss – Encryption HTTPS transport and TLS Robot Raconteur
>> transport.  This will encrypt the HTTP handshake and allow for identity
>> verification of the node.  Note that this is only possible when the
>> target node has an official HTTPS certificate which is not available for
>> IoT type devices.  In those cases rrs+ws should be used as it is designed
>> for such scenarios. rrs+wss should only be used when it is determined to be
>> truly necessary.
>>
>>
>> This just describes several access mechanism which will (after accessing)
>> make use of rr identifiers.
>> You don't need new schemes for this.
>>
>>
>> *Local Transport*
>>
>> ·         rr+local
>>
>> The local transport uses UNIX sockets or Named Pipes to communicate
>> between nodes on the same machine.  The nodeid and/or nodename are used
>> to identify the target nodes.  The host is always “localhost”.  A
>> username can be used to specify which user owns the desired node, ie
>> “username@localhost”.  The port is never used and must be left out of the
>> URI. Access control is accomplished through file permissions and standard
>> username/credential access control. Untrusted software shall not be allow
>> local transport access. The path must be “/” or empty.
>>
>>
>> Likewise, not an identifier. You don't need an identifier for every local
>> configuration option.
>>
>> *Hardware Transport*
>>
>> ·         rr+usb
>> ·         rr+pci
>>
>> Hardware device drivers are implemented through a userspace daemon service.
>>    This service provides UNIX socket / Named Pipe connections that allow
>> nodes to access the devices.  Access control is accomplished through file
>> permissions.  Generally only admin or equivalent users are given access.
>> Untrusted software shall not be allow local transport access. The path must
>> be “/” or empty.
>>
>>
>> Likewise, not an identifier.
>>
>> *Cloud Transport*
>>
>> ·         rr
>> ·         rr+cloud
>>
>> The cloud transport is a transport based on WebRTC.  The signaling as
>> accomplished through the Robot Raconteur server.  Nodes are identified by
>> the Robot Raconteur username and nodeid/nodname pair.  The hostname for
>> each user is “username.cloud.robotraconteur.com”, where username is
>> replaced with the registered username.  For instance, “
>> johnw.cloud.robotraconteur.com” would be the hostname “johnw”. The port
>> must not be included. Nodes connecting to the cloud service must all have
>> issued certificates tied to the uuid of the node (nodeid). This
>> communication is always secured through DTLS at the WebRTC layer.  Security
>> of the overall cloud is managed by the Robot Raconteur server. The
>> hostnames for each user are only relevant within the signaling server and
>> do not have any general use DNS meaning. “rr” and “rr+cloud” are
>> equivalent. The path must be “/” or empty.
>>
>>
>> If this is consistent with WebRTC, then use webrtc's identifiers.
>>
>> In other words, what you are defining here is an identifier space for rr
>> nodes and then a
>> bunch of proxy mechanisms for obtaining access to those identified nodes.
>> We don't do that
>> by multiplying schemes!  We do it by sending two identifiers: one for the
>> proxy and one for
>> the resource to access.  The proxy mechanisms already have defined
>> identifier schemes.
>>
>> ....Roy
>>
>>
>> _______________________________________________
>> Uri-review mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/uri-review
>>
>>
>
>
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>