Hi Marc,
Thanks for your reply. Some further comments below.
On Thu, Oct 15, 2009 at 4:20 PM, Marc Petit-Huguenin
<marc(_at_)petit-huguenin(_dot_)org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Ted,
Thanks for reviewing this I-D. See my comments below.
Ted Hardie wrote:
Howdy,
I do not believe this document is ready for publication, as I believe
the URI scheme documentation needs work. As it stands now, the
scheme-specific processing required for this scheme is so great that I
believe a standard URI parser will not work with the scheme as it is
intended. Looking, for example, at the CPAN module PERL::URI, the
operation of the standard behavior for path and port seem likely to
work contrary to this scheme's intention.
The standard behavior for path does not apply in this case, because a TURN URI
is an opaque URI, not a hierarchical URI, as advised by RFC 4395[1]. As far
as
I understand PERL::URI, this should fall in the scheme specific support of
PERL::URI[2], like for SIP and MAILTO URIs.
RFC 3986 has the following text:
A parser of the generic URI syntax can parse any URI reference into
its major components. Once the scheme is determined, further
scheme-specific parsing can be performed on the components. In other
words, the URI generic syntax is a superset of the syntax of all URI
schemes.
When you re-use elements from RFC 3986 (as you do with port, to
take on example), I believe the general expectation will be that you
are using them in ways that would allow general parsing to occur
first, as per the text in RFC 3986. If you do not wish to have this
general parsing occur before scheme-specific behavior, I believe
that you would be better off not re-using the elements as you have done
here. Some further discussion on the URI list on exactly how to achieve
what you want might turn out to be appropriate.
I also could not follow the
details of how this would work in relation to a DDDS remote hosting
option, as mentioned in section 1, and I believe that more descriptive
text may be required.
The best would be to add another example for this usage:
<begin-text>
5. Examples
5.1. Multiple Protocols
With the DNS RRs in Figure 1 and an ordered TURN transport list of
{TLS, TCP, UDP}, the resolution algorithm will convert the "turn:
example.net" URI to the list of IP addresses, port and protocol
tuples in Table 2.
example.net.
IN NAPTR 100 10 "" "RELAY:turn.udp" "" datagram.example.net.
IN NAPTR 200 10 "" "RELAY:turn.tcp:turn.tls" "" stream.example.net.
datagram.example.net.
IN NAPTR 100 10 "S" "RELAY:turn.udp" "" _udp._turn.example.net.
stream.example.net.
IN NAPTR 100 10 "S" "RELAY:turn.tcp" "" _turn._tcp.example.net.
IN NAPTR 200 10 "A" "RELAY:turn.tls" "" a.example.net.
_turn._udp.example.net.
IN SRV 0 0 3478 a.example.net.
_turn._tcp.example.net.
IN SRV 0 0 5000 a.example.net.
a.example.net.
IN A 192.0.2.1
Figure 1
+-------+----------+------------+------+
| Order | Protocol | IP address | Port |
+-------+----------+------------+------+
| 1 | UDP | 192.0.2.1 | 3478 |
| 2 | TLS | 192.0.2.1 | 5349 |
| 3 | TCP | 192.0.2.1 | 5000 |
+-------+----------+------------+------+
Table 2
5.2. Remote Hosting
In the example in Figure 2, a VoIP provider (example.com) is using
the TURN servers managed by the administrators of the example.net
domain (defined in Figure 1). The resolution algorithm using the
ordered TURN transport list of {TLS, TCP, UDP} would convert the
"turn:example.com" URI to the list of IP addresses, port and protocol
tuples in Table 2.
example.com.
IN NAPTR 100 10 "" "RELAY:turn.udp:turn.tcp:turn.tls" "" example.net.
Figure 2
</end-text>
This is somewhat clearer, but the transport list ordering is still confusing
to me (for more, see below).
One area of particular concern is this:
"The URI resolution algorithm uses <scheme>, <host>, <port> and
<transport> as input. It also uses as input a list ordered by
preference of TURN transports (UDP, TCP, TLS) supported by the
application using the TURN client. The output of the algorithm is a
list of {IP address, transport, port} tuples that a TURN client can
try in order to create an allocation on a TURN server."
Having a URI resolution method rely on a preference order associated
with a calling application seems very fragile. There seems to be no way
to guarantee that the information on calling application would be preserved
in
passing the URI to a parser. If this input list is required, I suspect that
that it must be noted within a URI parameter to avoid unexpected or incorrect
results.
I am not sure to fully understand the concern here. The preference order is
used so the resolver can choose in case of a tie. There is 3 different
sources
of data that are processed by the resolution algorithm to generate the list of
{IP address, port, protocol} tuples to try:
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.
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.
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.
regards,
Ted Hardie
Since this mechanism involves a fairly distinctive URI resolution
mechanism, I suggest that this document also be reviewed by the URI
mailing list, in addition to URI-review. It seems more likely to be
able to discuss how to best meet the requirements expressed within a
URI syntax more likely to be handled correctly by parsers already
deployed.
regards,
Ted Hardie
On Thu, Oct 15, 2009 at 7:58 AM, Magnus Westerlund
<magnus(_dot_)westerlund(_at_)ericsson(_dot_)com> wrote:
Hi,
As responsible AD I would really appreciate an URI review of the two
proposed URI schemes.
[1] http://www.ietf.org/mail-archive/web/behave/current/msg06537.html
[2] http://search.cpan.org/~gaas/URI-1.40/URI.pm#SCHEME-SPECIFIC_SUPPORT
- --
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkrXrjIACgkQ9RoMZyVa61cM7wCgn+57/Rab0lg1jQCMASabTPx/
2lAAoKr/ntOzbchDJj8SHZSOLrl/chgg
=OIPz
-----END PGP SIGNATURE-----
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf