-----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.
> 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>
>
> 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:
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.
>
> 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.westerlund@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx
Professional email: petithug@xxxxxxx
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf