


Network Working Group                                  M. Petit-Huguenin
Internet-Draft                                            (Unaffiliated)
Intended status: Standards Track                       February 28, 2010
Expires: September 1, 2010


     Traversal Using Relays around NAT (TURN) Resolution Mechanism
                     draft-ietf-behave-turn-uri-10

Abstract

   This document defines a resolution mechanism to generate a list of
   server transport addresses that can be tried to create a Traversal
   Using Relays around NAT (TURN) allocation.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 1, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Petit-Huguenin          Expires September 1, 2010               [Page 1]

Internet-Draft               TURN Resolution               February 2010


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Resolution Mechanism . . . . . . . . . . . . . . . . . . . . .  3
   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Multiple Protocols . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Remote Hosting . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  Compatibility with TURN  . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  RELAY Application Service Tag Registration . . . . . . . .  9
     6.2.  turn.udp Application Protocol Tag Registration . . . . . .  9
     6.3.  turn.tcp Application Protocol Tag Registration . . . . . . 10
     6.4.  turn.tls Application Protocol Tag Registration . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Release notes . . . . . . . . . . . . . . . . . . . . 12
     A.1.  Modifications between ietf-10 and ietf-09  . . . . . . . . 12
     A.2.  Modifications between ietf-09 and ietf-08  . . . . . . . . 12
     A.3.  Modifications between ietf-08 and ietf-07  . . . . . . . . 12
     A.4.  Modifications between ietf-07 and ietf-06  . . . . . . . . 12
     A.5.  Modifications between ietf-06 and ietf-05  . . . . . . . . 12
     A.6.  Modifications between ietf-05 and ietf-04  . . . . . . . . 13
     A.7.  Modifications between ietf-04 and ietf-03  . . . . . . . . 13
     A.8.  Modifications between ietf-03 and ietf-02  . . . . . . . . 13
     A.9.  Modifications between ietf-02 and ietf-01  . . . . . . . . 13
     A.10. Modifications between ietf-01 and ietf-00  . . . . . . . . 13
     A.11. Modifications between ietf-00 and petithuguenin-03 . . . . 14
     A.12. Modifications between petithuguenin-03 and
           petithuguenin-02 . . . . . . . . . . . . . . . . . . . . . 14
     A.13. Modifications between petithuguenin-02 and
           petithuguenin-01 . . . . . . . . . . . . . . . . . . . . . 14
     A.14. Modifications between petithuguenin-01 and
           petithuguenin-00 . . . . . . . . . . . . . . . . . . . . . 14
     A.15. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15






Petit-Huguenin          Expires September 1, 2010               [Page 2]

Internet-Draft               TURN Resolution               February 2010


1.  Introduction

   The TURN specification [TURN] defines a process for a TURN client to
   find TURN servers by using DNS SRV resource records, but this process
   does not let the TURN server administrators provision the preferred
   TURN transport protocol between the client and the server and does
   not allow the TURN client to discover this preference.  This document
   defines an S-NAPTR application [RFC3958] for this purpose.  This
   application defines "RELAY" as an application service tag and
   "turn.udp", "turn.tcp", and "turn.tls" as application protocol tags.

   Another usage of the resolution mechanism described in this document
   would be Remote Hosting as described in [RFC3958] section 4.4.  For
   example a VoIP provider who does not want to deploy TURN servers
   could use the servers deployed by another company but could still
   want to provide configuration parameters to its customers without
   explicitly showing this relationship.  The mechanism permits one to
   implement this indirection, without preventing the company hosting
   the TURN servers from managing them as it sees fit.

   [TURN-URI] can be used as a convenient way of carrying the four
   components needed by the resolution mechanism described in this
   document.  A reference implementation is available [REF-IMPL].


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Resolution Mechanism

   The resolution mechanism is used only to create an allocation.  All
   other transactions use the IP address, transport and port used for a
   successful allocation creation.  The resolution mechanism only
   selects the transport used between the TURN client and the TURN
   server.  The transport used by the allocation itself is selected by
   the REQUESTED-TRANSPORT attribute as described in section 6.1 of
   [TURN].

   The resolution algorithm uses a boolean flag, <secure>; an IP address
   or domain name, <host>; a port number that can be empty, <port>; and
   a transport name that can be "udp", "tcp" or empty, <transport> as
   input.  This four parameters are part of the user configuration of
   the TURN client.  The resolution mechanism also uses as input a list
   ordered by preference of TURN transports (UDP, TCP, TLS) supported



Petit-Huguenin          Expires September 1, 2010               [Page 3]

Internet-Draft               TURN Resolution               February 2010


   that is provided by the application using the TURN client.  This list
   reflects the capabilities and preferences of the application code
   that is using the S-NAPTR resolver and TURN client, as opposed to the
   configuration parameters that reflect the preferences of the user of
   the application.  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.

   An Allocate error response as specified in section 6.4 of [TURN] is
   processed as a failure as specified by [RFC3958] section 2.2.4.  The
   resolution stops when a TURN client gets a successful Allocate
   response from a TURN server.  After an allocation succeeds or all the
   allocations fail, the resolution context MUST be discarded and the
   resolution algorithm MUST be restarted from the beginning for any
   subsequent allocation.  Servers blacklisted as described in section
   6.4 of [TURN] MUST NOT be used for the specified duration even if
   returned by a subsequent resolution.

   First the resolution algorithm checks that the parameters can be
   resolved with the list of TURN transports supported by the
   application:

   o  If <secure> is false and <transport> is defined as "udp" but the
      list of TURN transports supported by the application does not
      contain UDP then the resolution MUST stop with an error.
   o  If <secure> is false and <transport> is defined as "tcp" but the
      list of TURN transports supported by the application does not
      contain TCP then the resolution MUST stop with an error.
   o  If <secure> is true and <transport> is defined as "udp" then the
      algorithm MUST stop with an error.
   o  If <secure> is true and <transport> is defined as "tcp" but the
      list of TURN transports supported by the application does not
      contain TLS then the resolution MUST stop with an error.
   o  If <secure> is true and <transport> is not defined but the list of
      TURN transports supported by the application does not contain TLS
      then the resolution MUST stop with an error.
   o  If <transport> is defined but unknown then the resolution MUST
      stop with an error.

   After verifying the validity of the parameters, the algorithm filters
   the list of TURN transports supported by the application by removing
   the UDP and TCP TURN transport if <secure> is true.  If the list of
   TURN transports is empty after this filtering, the resolution MUST
   stop with an error.

   After filtering the list of TURN transports supported by the
   application, the algorithm applies the steps described below.  Note
   that in some steps, <secure> and <transport> have to be converted to



Petit-Huguenin          Expires September 1, 2010               [Page 4]

Internet-Draft               TURN Resolution               February 2010


   a TURN transport.  If <secure> is false and <transport> is defined as
   "udp" then the TURN UDP transport is used.  If <secure> is false and
   <transport> is defined as "tcp" then the TURN TCP transport is used.
   If <secure> is true and <transport> is defined as "tcp" then the TURN
   TLS transport is used.  This is summarized in Table 1.

                +----------+-------------+----------------+
                | <secure> | <transport> | TURN Transport |
                +----------+-------------+----------------+
                | false    | "udp"       | UDP            |
                | false    | "tcp"       | TCP            |
                | true     | "tcp"       | TLS            |
                +----------+-------------+----------------+

                                  Table 1

   1.  If <host> is an IP address, then it indicates the specific IP
       address to be used.  If <port> is not defined, the default port
       declared in [TURN] for the "turn" SRV service name if <secure> is
       false, or the "turns" SRV service name if <secure> is true MUST
       be used for contacting the TURN server.  If <transport> is
       defined then <secure> and <transport> are converted to a TURN
       transport as specified in Table 1.  If <transport> is not
       defined, the filtered TURN transports supported by the
       application are tried by preference order.  If the TURN client
       cannot contact a TURN server with this IP address and port on any
       of the transports supported by the application then the
       resolution MUST stop with an error.

   2.  If <host> is a domain name and <port> is defined, then <host> is
       resolved to a list of IP addresses via DNS A and AAAA queries.
       If <transport> is defined, then <secure> and <transport> are
       converted to a TURN transport as specified in Table 1.  If
       <transport> is not defined, the filtered TURN transports
       supported by the application are tried in preference order.  The
       TURN client can choose the order to contact the resolved IP
       addresses in any implementation-specific way.  If the TURN client
       cannot contact a TURN server with this port, the transport or
       list of transports, and the resolved IP addresses, then the
       resolution MUST stop with an error.

   3.  If <host> is a domain name and <port> is not defined but
       <transport> is defined, then the SRV algorithm defined in
       [RFC2782] is used to generate a list of IP address and port
       tuples. <host> is used as Name, a value of false for <secure> as
       "turn" for Service, a value of true for <secure> as "turns" for
       Service and <transport> as Protocol in the SRV algorithm.
       <secure> and <transport> are converted to a TURN transport as



Petit-Huguenin          Expires September 1, 2010               [Page 5]

Internet-Draft               TURN Resolution               February 2010


       specified in Table 1 and this transport is used with each tuple
       for contacting the TURN server.  The SRV algorithm recommends
       doing an A query if the SRV query returns an error or no SRV RR;
       in this case the default port declared in [TURN] for the "turn"
       SRV service name if <secure> is false, or the "turns" SRV service
       name if <secure> is true MUST be used for contacting the TURN
       server.  Also in this case, this specification modifies the SRV
       algorithm by recommending an A and AAAA query.  If the TURN
       client cannot contact a TURN server at any of the IP address and
       port tuples returned by the SRV algorithm with the transport
       converted from <secure> and <transport> then the resolution MUST
       stop with an error.

   4.  If <host> is a domain name and <port> and <transport> are not
       defined, then <host> is converted to an ordered list of IP
       address, port and transport tuples via the S-NAPTR algorithm
       defined in [RFC3958] by using <host> as the initial target domain
       name and "RELAY" as the Application Service Tag. The filtered
       list of TURN transports supported by the application are
       converted in Application Protocol Tags by using "turn.udp" if the
       TURN transport is UDP, "turn.tcp" if the TURN transport is TCP
       and "turn.tls" if the TURN transport is TLS.  The order to try
       the Application Protocol Tags is provided by the ranking of the
       first set of NAPTR records.  If multiple Application Protocol
       Tags have the same ranking, the preferred order set by the
       application is used.  If the first NAPTR query fails, the
       processing continues in step 5.  If the TURN client cannot
       contact a TURN server with any of the IP address, port and
       transport tuples returned by the S-NAPTR algorithm then the
       resolution MUST stop with an error.

   5.  If the first NAPTR query in the previous step does not return any
       result then the SRV algorithm defined in [RFC2782] is used to
       generate a list of IP address and port tuples.  The SRV algorithm
       is applied by using each transport in the filtered list of TURN
       transports supported by the application for the Protocol, <host>
       for the Name, "turn" for the Service if <secure> is false or
       "turns" for the Service if <secure> is true.  The same transport
       that was used to generate a list of tuples is used with each of
       these tuples for contacting the TURN server.  The SRV algorithm
       recommends doing an A query if the SRV query returns an error or
       no SRV RR; in this case the default port declared in [TURN] for
       the "turn" SRV service name if <secure> is false, or the "turns"
       SRV service name if <secure> is true MUST be used for contacting
       the TURN server.  Also in this case, this specification modifies
       the SRV algorithm by recommending an A and AAAA query.  If the
       TURN client cannot contact a TURN server at any of the IP address
       and port tuples returned by the SRV algorithm with the transports



Petit-Huguenin          Expires September 1, 2010               [Page 6]

Internet-Draft               TURN Resolution               February 2010


       from the filtered list then the resolution MUST stop with an
       error.


4.  Examples

4.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 parameters
   <secure> with a value of false, <host> with a value of "example.net"
   and <port> and <transport> been empty 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 "" _turn._udp.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





Petit-Huguenin          Expires September 1, 2010               [Page 7]

Internet-Draft               TURN Resolution               February 2010


4.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 same
   parameters than in the previous example but with the <host> parameter
   equal to "example.com" 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

4.3.  Compatibility with TURN

   In deployments where it is not possible to guarantee that all TURN
   clients will support the resolution mechanism described in this
   document, the DNS configuration should be done in a way that works
   with both this resolution mechanism and the mechanism described in
   [TURN].  The DNS RRs in Figure 3 can be used in conjunction with the
   DNS RRs in Figure 1 and Figure 2 for this purpose.

   _turn._udp.example.com.
   IN SRV   0 0 3478 a.example.net.

   _turn._tcp.example.com.
   IN SRV   0 0 5000 a.example.net.

   _turns._tcp.example.com.
   IN SRV   0 0 5349 a.example.net.


                                 Figure 3


5.  Security Considerations

   Security considerations for TURN are discussed in [TURN].

   The Application Service Tag and Application Protocol Tags defined in
   this document do not introduce any specific security issues beyond
   the security considerations discussed in [RFC3958].  [RFC3958]
   requests that an S-NAPTR application defines some form of end-to-end
   authentication to ensure that the correct destination has been
   reached.  This is achieved by the Long-Term Credential Mechanism



Petit-Huguenin          Expires September 1, 2010               [Page 8]

Internet-Draft               TURN Resolution               February 2010


   defined in [RFC5389], which is mandatory for [TURN].

   Additionally the usage of TLS [RFC5246] has the capability to address
   the requirement.  In this case the client MUST verify the identity of
   the server by following the identification procedure in section 7.2.2
   of [RFC5389] and by using the value of the <host> parameter as the
   identity of the server to be verified.

   An implication of this is that the server's certificate could need to
   be changed when SRV or NAPTR records are added.  For example, a
   client using just A/AAAA records, and configured with
   "turnserver.example.net", expects to find the name
   "turnserver.example.net" in the certificate.  If a second client uses
   SRV records and is configured with <host> parameter "example.com", it
   expects to find "example.com" in the certificate, even if the SRV
   record at _turns._tcp.example.com points to turnserver.example.net.


6.  IANA Considerations

   This section contains the registration information for one S-NAPTR
   Application Service Tag and three S-NAPTR Application Protocol Tags
   (in accordance with [RFC3958]).

6.1.  RELAY Application Service Tag Registration

   Application Protocol Tag: RELAY

   Intended usage: See Section 3.

   Interoperability considerations: N/A

   Security considerations: See Section 5.

   Relevant publications: This document.

   [Note to RFC Editor: Replace "This document" with reference to this
   document]

   Contact information: Marc Petit-Huguenin <petithug@acm.org>

   Author/Change controller: The IESG

6.2.  turn.udp Application Protocol Tag Registration

   Application Protocol Tag: turn.udp

   Intended usage: See Section 3.



Petit-Huguenin          Expires September 1, 2010               [Page 9]

Internet-Draft               TURN Resolution               February 2010


   Interoperability considerations: N/A

   Security considerations: See Section 5.

   Relevant publications: This document.

   [Note to RFC Editor: Replace "This document" with reference to this
   document]

   Contact information: Marc Petit-Huguenin <petithug@acm.org>

   Author/Change controller: The IESG

6.3.  turn.tcp Application Protocol Tag Registration

   Application Protocol Tag: turn.tcp

   Intended usage: See Section 3.

   Interoperability considerations:

   Security considerations: See Section 5.

   Relevant publications: This document.

   [Note to RFC Editor: Replace "This document" with reference to this
   document]

   Contact information: Marc Petit-Huguenin <petithug@acm.org>

   Author/Change controller: The IESG

6.4.  turn.tls Application Protocol Tag Registration

   Application Protocol Tag: turn.tls

   Intended usage: See Section 3.

   Interoperability considerations: N/A

   Security considerations: See Section 5.

   Relevant publications: This document.

   [Note to RFC Editor: Replace "This document" with reference to this
   document]

   Contact information: Marc Petit-Huguenin <petithug@acm.org>



Petit-Huguenin          Expires September 1, 2010              [Page 10]

Internet-Draft               TURN Resolution               February 2010


   Author/Change controller: The IESG


7.  Acknowledgements

   Thanks to Cullen Jennings, Alexey Melnikov, Scott Bradner, Spencer
   Dawkins, Pasi Eronen, Margaret Wasserman, Magnus Westerlund, Juergen
   Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E.
   Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes and Jim Kleck for
   their comments, suggestions and questions that helped to improve this
   document.

   This document was written with the xml2rfc tool described in
   [RFC2629].


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC3958]  Daigle, L. and A. Newton, "Domain-Based Application
              Service Location Using SRV RRs and the Dynamic Delegation
              Discovery Service (DDDS)", RFC 3958, January 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [TURN]     Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)",
              draft-ietf-behave-turn-16 (work in progress), July 2009.

8.2.  Informative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.




Petit-Huguenin          Expires September 1, 2010              [Page 11]

Internet-Draft               TURN Resolution               February 2010


   [TURN-URI]
              Petit-Huguenin, M., "Traversal Using Relays around NAT
              (TURN) Uniform Resource Identifiers",
              draft-petithuguenin-behave-turn-uri-bis-01 (work in
              progress), February 2010.

   [REF-IMPL]
              Petit-Huguenin, M., "Reference Implementation of TURN
              resolver and TURN URI parser", January 2010, <http://
              debian.implementers.org/stable/source/turnuri.tar.gz>.


Appendix A.  Release notes

   This section must be removed before publication as an RFC.

A.1.  Modifications between ietf-10 and ietf-09

   o  Clarified that the resolution mechanism is for choosing the
      transport between the TURN client and the TURN server, not the
      transport used by the allocation.

A.2.  Modifications between ietf-09 and ietf-08

   o  Clarified that the identity to use for server certificate
      verification is <host>
   o  Moved the reference implementation reference to the informative
      references and changed the URL to something more stable.

A.3.  Modifications between ietf-08 and ietf-07

   o  Added reference to TLS RFC.
   o  Removed usused references.
   o  Fixed reference to URI.

A.4.  Modifications between ietf-07 and ietf-06

   o  Clarified "application code" meaning.

A.5.  Modifications between ietf-06 and ietf-05

   o  Updated the short title to "TURN Resolution".
   o  Shorten I-D references.
   o  Nits
   o  Changed SHOULD NOT to MUST NOT for blacklist rule.
   o  Added notes to RFC editor.





Petit-Huguenin          Expires September 1, 2010              [Page 12]

Internet-Draft               TURN Resolution               February 2010


A.6.  Modifications between ietf-05 and ietf-04

   o  Moved the URI stuff to [TURN-URI].

A.7.  Modifications between ietf-04 and ietf-03

   o  Improved the algorithm steps.
   o  It is possible to use a TLS transport event if the scheme is
      turn:.
   o  Clarified when to stop the resolution with an error in step 2.
   o  Added transport list filtering process.
   o  Improved security section following sec-dir review.
   o  Fixed nits reported by gen-art review.
   o  Added example for remote hosting.
   o  Removed URIs section.
   o  Editorial modification.

A.8.  Modifications between ietf-03 and ietf-02

   o  A turn:<host>?transport=TCP URI fails if the list of supported
      transports contains only TLS.  Using a TLS transport in this case
      was underspecified.
   o  Reordered paragraphes in section 4.
   o  Added table for conversion of <scheme> and <transport> to TURN
      transport.
   o  Various editorial modifications.
   o  SRV algorithm changed to "...recommending an A and AAAA query."
   o  Put back the changelog for the versions before been accepted as WG
      item.

A.9.  Modifications between ietf-02 and ietf-01

   o  Shorten the abstract so it does not overflow on the second page.
   o  Added text to explicitly say that the resolution is only to create
      an allocation.
   o  Added text about failures.
   o  Fixed the default port for TLS in the example.
   o  Changed some priority in the example for RFC3958 section 2.2.5.
   o  Fixed the service/protocol order for the SRV RR in the example.
   o  Removed reference to draft-wood-tae-specifying-uri-transports as
      it has an experimental status.

A.10.  Modifications between ietf-01 and ietf-00

   o  Fixed the contact email.
   o  Changed the IPR to trust200902.





Petit-Huguenin          Expires September 1, 2010              [Page 13]

Internet-Draft               TURN Resolution               February 2010


   o  Added case for transport defined but unknown.
   o  Moved RFC 3958 to Normative References.
   o  Added study of draft-wood-tae-specifying-uri-transports in TODO
      list.

A.11.  Modifications between ietf-00 and petithuguenin-03

   o  Renamed the document to "draft-ietf-behave-turn-uri".
   o  Changed author affiliation.
   o  Fixed the text in the IANA considerations.

A.12.  Modifications between petithuguenin-03 and petithuguenin-02

   o  Added Running Code Consideration section.
   o  Added Remote Hosting example in introduction.
   o  Changed back to opaque URIs because of RFC4395 Section 2.2.  Now
      use "?" as separator.
   o  Added IANA considerations section.
   o  Added security considerations section.

A.13.  Modifications between petithuguenin-02 and petithuguenin-01

   o  Receiving a successful Allocate response stops the resolution
      mechanism and the resolution context must be discarded after this.
   o  Changed from opaque to hierarchical URIs because the ";" character
      is used in <reg-name>.
   o  Various nits.

A.14.  Modifications between petithuguenin-01 and petithuguenin-00

   o  Added <transport-ext> in the ABNF.
   o  Use the <rulename> and "literal" usages for free-form text defined
      by RFC5234.
   o  Fixed various typos.
   o  Put the rule to convert <scheme> and <transport> to a TURN
      transport in a separate paragraph.
   o  Modified the SRV usage to be in line with RFC 2782.
   o  Clarified that the NAPTR protocol ranking must be used before the
      application ranking.
   o  Added an example.
   o  Added release notes.

A.15.  Design Notes

   o  The Application Service Tag is "RELAY" so other relaying
      mechanisms than TURN (e.g., TWIST) can be registered as
      Application Protocol Tags.




Petit-Huguenin          Expires September 1, 2010              [Page 14]

Internet-Draft               TURN Resolution               February 2010


   o  S-NAPTR was preferred to U-NAPTR because there is no use case for
      U-NAPTR.
   o  Adding optional capabilities (IPv6 allocation, preserve bit,
      etc...) in the resolution process was rejected at the Dublin
      meeting.


Author's Address

   Marc Petit-Huguenin
   (Unaffiliated)

   Email: petithug@acm.org






































Petit-Huguenin          Expires September 1, 2010              [Page 15]

