Re: [Uri-review] URI scheme registration request

[John Wason <[e-mail]>]

I think for now I will continue the request as it stands for the 
provisional registration.  My goal at the moment is to prevent 
conflict.  A formal standard is far enough off in the future due to IP 
issues that I don't think it is that important to worry about now.

On 12/2/2015 3:40 PM, Graham Klyne wrote:
> 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
>>


-- 
John Wason, Ph.D.
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
[phone]
[e-mail]