Re: [Uri-review] URI scheme registration request
John Wason <wason@wasontech.com> Sat, 21 November 2015 04:20 UTC
Return-Path: <wason@wasontech.com>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F311A6F0E for <uri-review@ietfa.amsl.com>; Fri, 20 Nov 2015 20:20:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_32=0.6, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_28WIJtTWMM for <uri-review@ietfa.amsl.com>; Fri, 20 Nov 2015 20:20:11 -0800 (PST)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417241A6EFB for <uri-review@ietf.org>; Fri, 20 Nov 2015 20:20:11 -0800 (PST)
Received: by qgea14 with SMTP id a14so85679699qge.0 for <uri-review@ietf.org>; Fri, 20 Nov 2015 20:20:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wasontech-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=ObWiNpIs5DplXK035kEzxyGslBS4/axrwCOykKV/xt4=; b=l3qCbMtpbQkq7mDVM6KqXCTBEASELPHFpunt1jJAbykV2hL1LBQQ7NJH6wGu69vsZ4 LjIQ3XJwCTB2HkZ4BNlh7Z21HzjQB/ACQFNRomKQ5BVfL0hSGzuxHp1b7RNn5SRF1Pit dimBqkpDpfT7sk/9OiaA1gTefBXcmy+KTu2Y7pOF0AYdEAhFe8ZawTroG1/VdLEDFl2J 0+nP5xsypI1PqmC2Gu35Hj19GES94o7lksnwJ/q1dp7gAjlB5Ld5ni5FcCH3quS85SoL iFGSxh8XA/f5Hm65evl1bVkKZWpouCF5ingMlBF/BPbHdzFHP56CzVRBE+gqxjYN0CCr q4eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=ObWiNpIs5DplXK035kEzxyGslBS4/axrwCOykKV/xt4=; b=O5Yl1PusRCqoi79fhGZY0wQCSF1k7JP3YFoprAHxLSn9GSqzMo19fdVJKTPxBZYtYY PgxEbS0SCIrVYjPhLTvjRomsMbOzJj150EAPvXBV93h3LWZLi02336r8roCz2pIwWlDV xbYzMC66hAphIBnTKjL8n6jGjTBsB3CdTdl7n1i5zpg3uEMBN00Ehd59NKDYvDIjJjXS lswWC9x+c0Lrmt7mCBegCIk6upWAtCkgWl6cnQzbKIohzQRyElmBxvw7cWA/SoiRc7LN G48UG+fpWHAuF57+Fhhtdd9ghJ9Ti10TIm8n/PIhpsk+wzo9Z/Mc0PUpuy+FHUu5RUgg Xo8w==
X-Gm-Message-State: ALoCoQmJ5yQptkGcEjunNVqMY/0ijDK7h1BiAQQpIAVoNH8AavUZbWVjqMkXYJ3YIOT+cJky0ghm
X-Received: by 10.140.91.135 with SMTP id z7mr16454462qgd.91.1448079610084; Fri, 20 Nov 2015 20:20:10 -0800 (PST)
Received: from [192.168.1.94] (ool-44c6b4b5.dyn.optonline.net. [68.198.180.181]) by smtp.googlemail.com with ESMTPSA id 76sm619869qgo.32.2015.11.20.20.20.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Nov 2015 20:20:09 -0800 (PST)
To: Dave Thaler <dthaler@microsoft.com>
References: <564531FC.7000606@wasontech.com> <2D58682309E75147BB3B286C815CAC7E2ACD0A184B@AUSX7MCPS308.AMER.DELL.COM> <5646C765.4050907@wasontech.com> <E3443077-C4D8-496E-BCD0-661F387831E3@gbiv.com> <BY2PR03MB412048F8332055735B3CFFDA3100@BY2PR03MB412.namprd03.prod.outlook.com> <5647B3D1.6000608@wasontech.com> <BY2PR03MB4126303C398BA1771C297F3A3100@BY2PR03MB412.namprd03.prod.outlook.com>
From: John Wason <wason@wasontech.com>
Message-ID: <564FF0F6.8020008@wasontech.com>
Date: Fri, 20 Nov 2015 23:20:06 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <BY2PR03MB4126303C398BA1771C297F3A3100@BY2PR03MB412.namprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------010706050508000809080405"
Archived-At: <http://mailarchive.ietf.org/arch/msg/uri-review/778B1Zfr694rzGUjgPUhuqsiXZU>
X-Mailman-Approved-At: Sat, 21 Nov 2015 00:27:34 -0800
Cc: "uri-review@ietf.org" <uri-review@ietf.org>
Subject: Re: [Uri-review] URI scheme registration request
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review/>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Nov 2015 04:20:16 -0000
I have prepared a more detailed description of the transports and URI request. Please let me know if you need further specific details: Robot Raconteur URI Scheme Improvement John Wason Wason Technology, LLC wason@wasontech.com 11/20/15 *Introduction* Robot Raconteur is being improved to better comply with web standards by adding support for WebSocket transports and implementing a new URI scheme that can be registered with IANA.The URIs for Robot Raconteur use the following basic format: rr+transport://hostname:port/path/to/endpoint?service=servicename&nodename=targetnodename&nodeid=targetnodeuuid The scheme is “rr”, “+”, and then the transport type.For instance for TCP the scheme is “rr+tcp”. If TLS is used, “rr” is replaced with “rrs” to indicate the extra security.For TCP a secure transport would use the scheme “rrs+tcp”. The following schemes are used and will each be discussed in detail in the following sections: ·rr+tcp ·rrs+tcp ·rr+local ·rr+usb ·rr+pci ·rr ·rr+cloud ·rr+ws ·rrs+ws ·rr+wss ·rrs+wss Each of these schemes corresponds to a different selection of transports and security options. The hostname and port correspond to the hostname and port of the target machine.If no port is specified the default is used.For rr+local, rr+tcp, rr+usb, rr+pci, rr, and rr+cloud the port must not be included as these do not use ports to find the target. The absolute path (/path/to/endpoint) in the example is only used for WebSockets with HTTP to identify the WebSocket target and must be empty or “/” for all other transport types. The query contains the name of the service to connect to.It may also contain the nodeid and nodename if desired to help find the node.The same endpoint can provide connection to multiple nodes so this provides a way to select the target node. The query string can also be used to pass extra parameters to the WebSocket HTTP server if desired.The query string is passed unmodified to the server. All nodes can be secured with username and credential pairs. A functional example of a Robot Raconteur URI is: rr+tcp://192.168.2.3:48653/?nodeid= a7aa5f85-dfa7-41fe-89a1-1ebff43b9580&service=create The following sections will describe the exact transports and how they create connections to the target nodes. *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. *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. *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. *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. *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. On 11/14/2015 6:37 PM, Dave Thaler wrote: > > Short answer: unfortunately no > > This was the subject of issue #16: > > http://trac.tools.ietf.org/wg/appsawg/trac/ticket/16 > > It was discussed at IETF 89 and then again at IETF 90. In both cases, > and as confirmed on the list, > > the consensus of the WG was to not allow a notion of wildcards. > Instead you have to individually > > register each such scheme. I see “svn+ssh” is not currently > registered, but it sounds like it ought to be. > > Dave > > *From:*John Wason [mailto:wason@wasontech.com] > *Sent:* Saturday, November 14, 2015 2:21 PM > *To:* Dave Thaler <dthaler@microsoft.com>; Roy T. Fielding > <fielding@gbiv.com> > *Cc:* uri-review@ietf.org > *Subject:* Re: [Uri-review] URI scheme registration request > > Is it possible to register a "wildcard" or have an understanding that > the scheme can be appended with the transport type? Subversion uses > "svn+ssh" to specify an ssh tunnel. This format seems to be used > occasionally in practice. Because the different transports can point > to completely different resources on the same host I am not sure > having the transport in the query portion is the correct solution. > > On 11/14/2015 3:07 PM, Dave Thaler wrote: > > Roy T. Fielding wrote: > > >A URI scheme should define what it names and how that naming maps > to the URI syntax. > > >There is nothing wrong with using separate schemes for different > transports if those transports > > >are essential parts of the name (e.g., if something named Fred at > TCP:80 is different from something > > >named Fred at UDP:89898). (I prefer using dots, like rr.tcp and > rr.udp and rr.tcp.tls.) > > Careful… RFC 7595 states: > > Furthermore, to prevent collisions with private-use scheme > names, new > > scheme names registered MUST NOT contain a "." unless actually > > constructed from a reversed domain name. > > So rr.tcp should only be done if you register rr as a TLD, and > since rr is 2 letters, it’s reserved for a country code. > > Dave > > > > > -- > John Wason, Ph.D. > Wason Technology, LLC > PO Box 669 > Tuxedo, NY 10987 > (518) 279-6234 > wason@wasontech.com <mailto:wason@wasontech.com> -- John Wason, Ph.D. Wason Technology, LLC PO Box 669 Tuxedo, NY 10987 (518) 279-6234 wason@wasontech.com
- [Uri-review] URI scheme registration request John Wason
- Re: [Uri-review] URI scheme registration request Daniel R. Tobias
- Re: [Uri-review] URI scheme registration request John Wason
- Re: [Uri-review] URI scheme registration request David_Warden
- Re: [Uri-review] URI scheme registration request John Wason
- Re: [Uri-review] URI scheme registration request Roy T. Fielding
- Re: [Uri-review] URI scheme registration request David_Warden
- Re: [Uri-review] URI scheme registration request Dave Thaler
- Re: [Uri-review] URI scheme registration request John Wason
- Re: [Uri-review] URI scheme registration request Dave Thaler
- Re: [Uri-review] URI scheme registration request John Wason
- Re: [Uri-review] URI scheme registration request John Wason
- Re: [Uri-review] URI scheme registration request John Wason
- Re: [Uri-review] URI scheme registration request Ted Hardie
- Re: [Uri-review] URI scheme registration request Dave Thaler
- Re: [Uri-review] URI scheme registration request Roy T. Fielding
- Re: [Uri-review] URI scheme registration request John Wason
- Re: [Uri-review] URI scheme registration request Roy T. Fielding
- Re: [Uri-review] URI scheme registration request John Wason
- Re: [Uri-review] URI scheme registration request David_Warden
- Re: [Uri-review] URI scheme registration request Ted Hardie
- Re: [Uri-review] URI scheme registration request Graham Klyne
- Re: [Uri-review] URI scheme registration request John Wason