-----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(_at_)petit-huguenin(_dot_)org
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-----