-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Hadriel, Note that the STUN URIs design is based on the TURN URI design, which was discussed back in 2008-2009. See my answers below. On 08/15/2013 07:01 AM, Hadriel Kaplan wrote: > > Some comments on this STUN draft and the TURN one: > > 1) The ABNF in these drafts leaves no room for future extension such as > adding parameters. Was that intentional? Yes. There is two very different kind of parameters in an URI: 1. Parameters that are used to guide the selection of the resource (basically parameters that are input to RFC 5766 and RFC 5928). The BEHAVE WG decided in Dublin to not support this[1] (i.e. to not have either URI parameters or their counterpart in the DNS). 2. Other parameters that are not used to guide the selection but that are used by the protocol, e.g. "username", "password", etc... "password" was removed for security reasons. It was decided (although I cannot find exactly when) that these non-guiding parameters should not be part of a TURN URI, so "username" was removed too, as was the "auth" parameter proposed recently (i.e. all these parameters should be part of the WebRTC RTCIceServer dictionary). Not supporting extensibility (i.e. not being able to add these parameters later) was agreed by default also in Dublin (see slide 5 of [2]). IIRC, extensibility for the first kind of parameters was found too difficult (how implementation reacts to a new parameter?). Extensibility for the second type of parameters would create less issues, but as they were rejected anyway on principle, there was no point of having a way to add them later. For the record, I still disagree with the decision of not supporting the first kind of parameters (RFC 5928 was even designed to support TWIST ;-) ), but that was the consensus at the time. I still agree with not supporting the second kind of parameters. Note that only the second type of parameters would apply to STUN URIs, but they were not permitted in STUN for symmetry with the TURN URIs. [1] https://www.ietf.org/proceedings/72/minutes/behave.txt [2] https://www.ietf.org/proceedings/72/slides/behave-0.pdf > > 2) Why do both of these docs repeat a lot of ABNF from RFC 3986, instead > of just referencing it? It says in the appendix some ABNF was repeated > because RFC 3986 "are for hierarchical URIs". I'm not exactly sure what > that means other than you don't have a path component, but as far as I can > tell the copied ABNF components in these STUN/TRUN drafts are verbatim > copies of RFC 3986, all the way down to their final expansion. > > For example, 'IP-literal' and all of its sub-defined parts ('IPv6address', > 'IPvFuture', 'h16', 'ls32') appear identical to those in RFC 3986. In > fact, so is 'stun-host' and 'turn-host' - it's just RFC 3986 'host' by > another name. Am I missing something? > > Why not just have this: stunURI = scheme ":" stun-host [ ":" > stun-port ] scheme = "stun" / "stuns" stun-host = host ;see > section 3.2.2 of [RFC3986] stun-port = port ;see section 3.2.3 of > [RFC3986] > > Not a big deal, but it just seems simpler and cleaner to me to not repeat > ABNF from other RFCs, especially when the RFC in question is the one for > general URI syntax and you're defining a specific URI syntax based on it. This was done back in 2009 during the first uri-review of the TURN URI, following a comment by Ted Hardie. The problem is that the TURN and STUN uris are opaque URIs, but using these ABNF productions make them look like hierarchical URIs, because these productions are defined in RFC 3986 only for hierarchical URIs. So the point was that developers may misinterpreting this as meaning that TURN and STUN URIs can be parsed by a generic hierarchical parser, which would be a very bad idea (as username and password would then be parsed). Version -06 will contain a more complete design note about this (we decided that the design notes will stay in the RFC), here's the current version: "o The ABNF in this document duplicates the <IP-literal>, <IPv4address>, and <reg-name> productions and other dependent productions from [RFC3986], instead of referencing them. This is because the definitions in RFC 3986 are for hierarchical URIs, so using these references in an opaque URI made reviewers think that a hierarchical URI parser could be used to parse the URIs defined in this document." - -- Marc Petit-Huguenin Email: marc@xxxxxxxxxxxxxxxxxx Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJSDj0WAAoJECnERZXWan7EbJwQAOIQJjxl2JtZM8oFcvSevFCG aulKCWtmX9P067JvyeUHMBp5w3bP+piY6pKYVuBtbjhflKCW+k24cIK7vXyJ9w0N 0VjrubNIrtHYc8ORHGyASxx+92zoIHU8cssIPS/fXjho6u1tGJaJCghGlG5f9UiQ JicqpdWagzL6KNmvpG3jOW+kXr+acSjGWJg/flwuK8SRiNlK4hWNAtzye8cPaSly KkRrNS4ZJSDDDO7hWcKS7KgOXeyue5Vmh3OngIuOXOgpJeyITgI0F+EXnb0ius5z i6TFrpa4HlUaaE59D9ho86fc1M9RTM81cxaj4onJeUTSpcvWSIxmOECmqPzlowzG LlmW5qCljVG9+63j0q3ddEZXqujoL2V/5IwXg3MO6hj7/a4dcyiPLlZt0QRqO3F4 u27IyRAQBtboZzSDfpuVizIDJh4ied1RSNkJtJRI0liv3mPJYJVCUSWdLbLS9ptV GKv9byvVYZVxLUerTfbvzGOnjogdb9jZb1FT5GDlv8jaHcqam/Z+y3t7d8piWIz2 NwOPeEftPro8UvsH2SiDOTGzEZfHH3n+V+ymvbaLJib2Z8G3VWtoWAyozt9/hj1v YWC2QaiUHjKjHGWdldLh5h+EGI7SIILNW6GDsnfxvrkAD/Cksr6asGaXVdjus71C Urdaqp5q7e9n5y6f+3J/ =zZ4a -----END PGP SIGNATURE-----