ietf
[Top] [All Lists]

Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-ietf-behave-turn-uri (Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers) to Proposed Standard]

2009-10-16 16:03:02
-----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(_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

<Prev in Thread] Current Thread [Next in Thread>