Hi Marc,
Thanks for your quick reply; a few notes in-line below.
Hmm, I see your point. Because I reuse definitions from RFC 3986, you think
that these definitions should be used in the same exact way that they are used
in RFC 3986, where in fact I merely use them as a short cut to not have to
copy
them (especially for <host>).
This is part of the issue, and probably the main part. As it stands,
reusing those elements appears to put portions of the URI into an
"authority section" model (go here to get the resource specified in
the path, or returned by the query) when they are really closer to a
query portion.
There was not many opaque URI defined in standard track since RFC 3986, but
the
IRIS URI (RFC 3981 section 7.1) looks like an opaque URI that reuse components
from RFC 2396 and RFC 2732.
Anyway, I can copy and rename the definitions that I need from RFC 3986 if it
is
what is needed.
IRIS is an interesting model here, as it is one of the few others to
really use S-NAPTR. I've cc'ed Andy on this message to ping him to
take a look at your draft. IRIS's complexity is pretty substantial on
a number of fronts, and the URI resolution is certainly
one of the areas where the complexity has daunted some of those
interested in the protocol. It's also noteworthy that IRIS created a
very rigid URI, with a very flexibile resolution mechanism. I'm not
sure, honestly, that approach was a success.
Where does it get the preference order? The document seems to imply that
the preference order is associated with an application using the URI, which
you have restated in 2. below. As stated above, this implies knowledge
of that preference order in the URI parser, without explicitly passing that
knowledge. If that is not correct, sorry, but that is how the document
reads
to me at the moment. If that is correct, it seems fragile.
The I-D talks about two separate things:
First a resolution mechanism, or algorithm, that take in input this 4
elements:
- A list of ordered TURN transport
- A domain or an IP address
- A port that can be empty
- A transport that can be empty
With this information and the RR retrieved from the network, it builds a list
of
{IP, port, transport} tuples.
The second thing described in the I-D is an URI that permit to conveniently
provide the 3 last elements in a unique character string. The URI parser (at
the difference of the resolution algorithm) does not care about which TURN
protocols are implemented or not, or which one is more efficient or more
secure
than the other (according to the implementer).
+------+ +----------+
TURN URI -->|Parser+--> domain/IP -->|Resolution+--> {IP, port, transport}
list
| +--> port ------->|mechanism |
| +--> transport--->| |
+------+ | |
TURN transport list----------------->| |
RRs--------------------------------->| |
+----------+
1. The NAPR/SRV/A/AAA RRs that express the preferences of the domain(s)
administrators.
2. The ordered list of TURN transports that express the preferences of the
application developers (i.e. the capabilities of the application - what
protocols are implemented - and in case the algorithm cannot decide, the
preferred protocol - the fastest implementation, or more secure, etc...).
3. The URI itself that express the preferences of the user of the application
(i.e. specific IP, specific port, specific transport or just the domain if
the
user does not care).
Moving the ordered list of TURN transports to the URI would prevent the
application to provide to the resolution algorithm its own capabilities and
preferences.
Let me know if you think that the current text does not reflect this
explanation, in which case I will try to add some text.
This is clearer; thanks. My own reading of the current text did not
reflect this understanding. Reading it, it seemed to me to imply that
the *URI resolution* relied on knowing the TURN preferences of the
calling application (your 2). Your text above notes that the URI
resolution does not depend on this at all; the URI resolution proceeds
and then the application logic is applied. Is that correct?
Honestly, I am increasingly confused about why it would not be
better to simply use the existing DNS URI scheme to point to
the NAPTR RRs, then apply all the post processing to what
is returned, without trying to do a portion of this within this scheme
structure. That's obviously a different set of trade-offs, but given
the extensive set of scheme-specific behavior this requires, I'm
not sure I understand the engineering choice here.
Let met know if after reading my explanation above you still think that the
DNS
URI is a solution to explore, and I will then answer that.
As I said before, I think it is a different set of trade-offs, and
last call is not really
a fair time to suggest a completely different road. What it gets you
is the ability
to separate the "get the RRs" step from all the other steps in the application
logic. If that would be useful, then by all means do explore it; if the working
group's conclusion is that the right approach is mint a single URI that both
retrieves the relevant NAPTR RRs and carries the other parameters needed to
identify the TURN server, then continuing to work on this may be the way to go.
What started me down the line of thinking that led to separating them was the
notion that at least some of the parameters (the application's preference order)
were already outside the URI.
regards,
Ted Hardie
Thanks.
--
Marc Petit-Huguenin
Personal email: marc(_at_)petit-huguenin(_dot_)org
Professional email: petithug(_at_)acm(_dot_)org
Blog: http://blog.marc.petit-huguenin.org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf