idnits 2.17.1 draft-ietf-behave-turn-uri-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 28, 2010) is 5171 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-05) exists of draft-petithuguenin-behave-turn-uri-bis-01 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Petit-Huguenin 3 Internet-Draft (Unaffiliated) 4 Intended status: Standards Track February 28, 2010 5 Expires: September 1, 2010 7 Traversal Using Relays around NAT (TURN) Resolution Mechanism 8 draft-ietf-behave-turn-uri-10 10 Abstract 12 This document defines a resolution mechanism to generate a list of 13 server transport addresses that can be tried to create a Traversal 14 Using Relays around NAT (TURN) allocation. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 1, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Resolution Mechanism . . . . . . . . . . . . . . . . . . . . . 3 59 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Multiple Protocols . . . . . . . . . . . . . . . . . . . . 7 61 4.2. Remote Hosting . . . . . . . . . . . . . . . . . . . . . . 8 62 4.3. Compatibility with TURN . . . . . . . . . . . . . . . . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 6.1. RELAY Application Service Tag Registration . . . . . . . . 9 66 6.2. turn.udp Application Protocol Tag Registration . . . . . . 9 67 6.3. turn.tcp Application Protocol Tag Registration . . . . . . 10 68 6.4. turn.tls Application Protocol Tag Registration . . . . . . 10 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 12 74 A.1. Modifications between ietf-10 and ietf-09 . . . . . . . . 12 75 A.2. Modifications between ietf-09 and ietf-08 . . . . . . . . 12 76 A.3. Modifications between ietf-08 and ietf-07 . . . . . . . . 12 77 A.4. Modifications between ietf-07 and ietf-06 . . . . . . . . 12 78 A.5. Modifications between ietf-06 and ietf-05 . . . . . . . . 12 79 A.6. Modifications between ietf-05 and ietf-04 . . . . . . . . 13 80 A.7. Modifications between ietf-04 and ietf-03 . . . . . . . . 13 81 A.8. Modifications between ietf-03 and ietf-02 . . . . . . . . 13 82 A.9. Modifications between ietf-02 and ietf-01 . . . . . . . . 13 83 A.10. Modifications between ietf-01 and ietf-00 . . . . . . . . 13 84 A.11. Modifications between ietf-00 and petithuguenin-03 . . . . 14 85 A.12. Modifications between petithuguenin-03 and 86 petithuguenin-02 . . . . . . . . . . . . . . . . . . . . . 14 87 A.13. Modifications between petithuguenin-02 and 88 petithuguenin-01 . . . . . . . . . . . . . . . . . . . . . 14 89 A.14. Modifications between petithuguenin-01 and 90 petithuguenin-00 . . . . . . . . . . . . . . . . . . . . . 14 91 A.15. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 14 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 1. Introduction 96 The TURN specification [TURN] defines a process for a TURN client to 97 find TURN servers by using DNS SRV resource records, but this process 98 does not let the TURN server administrators provision the preferred 99 TURN transport protocol between the client and the server and does 100 not allow the TURN client to discover this preference. This document 101 defines an S-NAPTR application [RFC3958] for this purpose. This 102 application defines "RELAY" as an application service tag and 103 "turn.udp", "turn.tcp", and "turn.tls" as application protocol tags. 105 Another usage of the resolution mechanism described in this document 106 would be Remote Hosting as described in [RFC3958] section 4.4. For 107 example a VoIP provider who does not want to deploy TURN servers 108 could use the servers deployed by another company but could still 109 want to provide configuration parameters to its customers without 110 explicitly showing this relationship. The mechanism permits one to 111 implement this indirection, without preventing the company hosting 112 the TURN servers from managing them as it sees fit. 114 [TURN-URI] can be used as a convenient way of carrying the four 115 components needed by the resolution mechanism described in this 116 document. A reference implementation is available [REF-IMPL]. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 3. Resolution Mechanism 126 The resolution mechanism is used only to create an allocation. All 127 other transactions use the IP address, transport and port used for a 128 successful allocation creation. The resolution mechanism only 129 selects the transport used between the TURN client and the TURN 130 server. The transport used by the allocation itself is selected by 131 the REQUESTED-TRANSPORT attribute as described in section 6.1 of 132 [TURN]. 134 The resolution algorithm uses a boolean flag, ; an IP address 135 or domain name, ; a port number that can be empty, ; and 136 a transport name that can be "udp", "tcp" or empty, as 137 input. This four parameters are part of the user configuration of 138 the TURN client. The resolution mechanism also uses as input a list 139 ordered by preference of TURN transports (UDP, TCP, TLS) supported 140 that is provided by the application using the TURN client. This list 141 reflects the capabilities and preferences of the application code 142 that is using the S-NAPTR resolver and TURN client, as opposed to the 143 configuration parameters that reflect the preferences of the user of 144 the application. The output of the algorithm is a list of {IP 145 address, transport, port} tuples that a TURN client can try in order 146 to create an allocation on a TURN server. 148 An Allocate error response as specified in section 6.4 of [TURN] is 149 processed as a failure as specified by [RFC3958] section 2.2.4. The 150 resolution stops when a TURN client gets a successful Allocate 151 response from a TURN server. After an allocation succeeds or all the 152 allocations fail, the resolution context MUST be discarded and the 153 resolution algorithm MUST be restarted from the beginning for any 154 subsequent allocation. Servers blacklisted as described in section 155 6.4 of [TURN] MUST NOT be used for the specified duration even if 156 returned by a subsequent resolution. 158 First the resolution algorithm checks that the parameters can be 159 resolved with the list of TURN transports supported by the 160 application: 162 o If is false and is defined as "udp" but the 163 list of TURN transports supported by the application does not 164 contain UDP then the resolution MUST stop with an error. 165 o If is false and is defined as "tcp" but the 166 list of TURN transports supported by the application does not 167 contain TCP then the resolution MUST stop with an error. 168 o If is true and is defined as "udp" then the 169 algorithm MUST stop with an error. 170 o If is true and is defined as "tcp" but the 171 list of TURN transports supported by the application does not 172 contain TLS then the resolution MUST stop with an error. 173 o If is true and is not defined but the list of 174 TURN transports supported by the application does not contain TLS 175 then the resolution MUST stop with an error. 176 o If is defined but unknown then the resolution MUST 177 stop with an error. 179 After verifying the validity of the parameters, the algorithm filters 180 the list of TURN transports supported by the application by removing 181 the UDP and TCP TURN transport if is true. If the list of 182 TURN transports is empty after this filtering, the resolution MUST 183 stop with an error. 185 After filtering the list of TURN transports supported by the 186 application, the algorithm applies the steps described below. Note 187 that in some steps, and have to be converted to 188 a TURN transport. If is false and is defined as 189 "udp" then the TURN UDP transport is used. If is false and 190 is defined as "tcp" then the TURN TCP transport is used. 191 If is true and is defined as "tcp" then the TURN 192 TLS transport is used. This is summarized in Table 1. 194 +----------+-------------+----------------+ 195 | | | TURN Transport | 196 +----------+-------------+----------------+ 197 | false | "udp" | UDP | 198 | false | "tcp" | TCP | 199 | true | "tcp" | TLS | 200 +----------+-------------+----------------+ 202 Table 1 204 1. If is an IP address, then it indicates the specific IP 205 address to be used. If is not defined, the default port 206 declared in [TURN] for the "turn" SRV service name if is 207 false, or the "turns" SRV service name if is true MUST 208 be used for contacting the TURN server. If is 209 defined then and are converted to a TURN 210 transport as specified in Table 1. If is not 211 defined, the filtered TURN transports supported by the 212 application are tried by preference order. If the TURN client 213 cannot contact a TURN server with this IP address and port on any 214 of the transports supported by the application then the 215 resolution MUST stop with an error. 217 2. If is a domain name and is defined, then is 218 resolved to a list of IP addresses via DNS A and AAAA queries. 219 If is defined, then and are 220 converted to a TURN transport as specified in Table 1. If 221 is not defined, the filtered TURN transports 222 supported by the application are tried in preference order. The 223 TURN client can choose the order to contact the resolved IP 224 addresses in any implementation-specific way. If the TURN client 225 cannot contact a TURN server with this port, the transport or 226 list of transports, and the resolved IP addresses, then the 227 resolution MUST stop with an error. 229 3. If is a domain name and is not defined but 230 is defined, then the SRV algorithm defined in 231 [RFC2782] is used to generate a list of IP address and port 232 tuples. is used as Name, a value of false for as 233 "turn" for Service, a value of true for as "turns" for 234 Service and as Protocol in the SRV algorithm. 235 and are converted to a TURN transport as 236 specified in Table 1 and this transport is used with each tuple 237 for contacting the TURN server. The SRV algorithm recommends 238 doing an A query if the SRV query returns an error or no SRV RR; 239 in this case the default port declared in [TURN] for the "turn" 240 SRV service name if is false, or the "turns" SRV service 241 name if is true MUST be used for contacting the TURN 242 server. Also in this case, this specification modifies the SRV 243 algorithm by recommending an A and AAAA query. If the TURN 244 client cannot contact a TURN server at any of the IP address and 245 port tuples returned by the SRV algorithm with the transport 246 converted from and then the resolution MUST 247 stop with an error. 249 4. If is a domain name and and are not 250 defined, then is converted to an ordered list of IP 251 address, port and transport tuples via the S-NAPTR algorithm 252 defined in [RFC3958] by using as the initial target domain 253 name and "RELAY" as the Application Service Tag. The filtered 254 list of TURN transports supported by the application are 255 converted in Application Protocol Tags by using "turn.udp" if the 256 TURN transport is UDP, "turn.tcp" if the TURN transport is TCP 257 and "turn.tls" if the TURN transport is TLS. The order to try 258 the Application Protocol Tags is provided by the ranking of the 259 first set of NAPTR records. If multiple Application Protocol 260 Tags have the same ranking, the preferred order set by the 261 application is used. If the first NAPTR query fails, the 262 processing continues in step 5. If the TURN client cannot 263 contact a TURN server with any of the IP address, port and 264 transport tuples returned by the S-NAPTR algorithm then the 265 resolution MUST stop with an error. 267 5. If the first NAPTR query in the previous step does not return any 268 result then the SRV algorithm defined in [RFC2782] is used to 269 generate a list of IP address and port tuples. The SRV algorithm 270 is applied by using each transport in the filtered list of TURN 271 transports supported by the application for the Protocol, 272 for the Name, "turn" for the Service if is false or 273 "turns" for the Service if is true. The same transport 274 that was used to generate a list of tuples is used with each of 275 these tuples for contacting the TURN server. The SRV algorithm 276 recommends doing an A query if the SRV query returns an error or 277 no SRV RR; in this case the default port declared in [TURN] for 278 the "turn" SRV service name if is false, or the "turns" 279 SRV service name if is true MUST be used for contacting 280 the TURN server. Also in this case, this specification modifies 281 the SRV algorithm by recommending an A and AAAA query. If the 282 TURN client cannot contact a TURN server at any of the IP address 283 and port tuples returned by the SRV algorithm with the transports 284 from the filtered list then the resolution MUST stop with an 285 error. 287 4. Examples 289 4.1. Multiple Protocols 291 With the DNS RRs in Figure 1 and an ordered TURN transport list of 292 {TLS, TCP, UDP}, the resolution algorithm will convert the parameters 293 with a value of false, with a value of "example.net" 294 and and been empty to the list of IP addresses, 295 port and protocol tuples in Table 2. 297 example.net. 298 IN NAPTR 100 10 "" RELAY:turn.udp "" datagram.example.net. 299 IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net. 301 datagram.example.net. 302 IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net. 304 stream.example.net. 305 IN NAPTR 100 10 S RELAY:turn.tcp "" _turn._tcp.example.net. 306 IN NAPTR 200 10 A RELAY:turn.tls "" a.example.net. 308 _turn._udp.example.net. 309 IN SRV 0 0 3478 a.example.net. 311 _turn._tcp.example.net. 312 IN SRV 0 0 5000 a.example.net. 314 a.example.net. 315 IN A 192.0.2.1 317 Figure 1 319 +-------+----------+------------+------+ 320 | Order | Protocol | IP address | Port | 321 +-------+----------+------------+------+ 322 | 1 | UDP | 192.0.2.1 | 3478 | 323 | 2 | TLS | 192.0.2.1 | 5349 | 324 | 3 | TCP | 192.0.2.1 | 5000 | 325 +-------+----------+------------+------+ 327 Table 2 329 4.2. Remote Hosting 331 In the example in Figure 2, a VoIP provider (example.com) is using 332 the TURN servers managed by the administrators of the example.net 333 domain (defined in Figure 1). The resolution algorithm using the 334 ordered TURN transport list of {TLS, TCP, UDP} would convert the same 335 parameters than in the previous example but with the parameter 336 equal to "example.com" to the list of IP addresses, port and protocol 337 tuples in Table 2. 339 example.com. 340 IN NAPTR 100 10 "" RELAY:turn.udp:turn.tcp:turn.tls "" example.net. 342 Figure 2 344 4.3. Compatibility with TURN 346 In deployments where it is not possible to guarantee that all TURN 347 clients will support the resolution mechanism described in this 348 document, the DNS configuration should be done in a way that works 349 with both this resolution mechanism and the mechanism described in 350 [TURN]. The DNS RRs in Figure 3 can be used in conjunction with the 351 DNS RRs in Figure 1 and Figure 2 for this purpose. 353 _turn._udp.example.com. 354 IN SRV 0 0 3478 a.example.net. 356 _turn._tcp.example.com. 357 IN SRV 0 0 5000 a.example.net. 359 _turns._tcp.example.com. 360 IN SRV 0 0 5349 a.example.net. 362 Figure 3 364 5. Security Considerations 366 Security considerations for TURN are discussed in [TURN]. 368 The Application Service Tag and Application Protocol Tags defined in 369 this document do not introduce any specific security issues beyond 370 the security considerations discussed in [RFC3958]. [RFC3958] 371 requests that an S-NAPTR application defines some form of end-to-end 372 authentication to ensure that the correct destination has been 373 reached. This is achieved by the Long-Term Credential Mechanism 374 defined in [RFC5389], which is mandatory for [TURN]. 376 Additionally the usage of TLS [RFC5246] has the capability to address 377 the requirement. In this case the client MUST verify the identity of 378 the server by following the identification procedure in section 7.2.2 379 of [RFC5389] and by using the value of the parameter as the 380 identity of the server to be verified. 382 An implication of this is that the server's certificate could need to 383 be changed when SRV or NAPTR records are added. For example, a 384 client using just A/AAAA records, and configured with 385 "turnserver.example.net", expects to find the name 386 "turnserver.example.net" in the certificate. If a second client uses 387 SRV records and is configured with parameter "example.com", it 388 expects to find "example.com" in the certificate, even if the SRV 389 record at _turns._tcp.example.com points to turnserver.example.net. 391 6. IANA Considerations 393 This section contains the registration information for one S-NAPTR 394 Application Service Tag and three S-NAPTR Application Protocol Tags 395 (in accordance with [RFC3958]). 397 6.1. RELAY Application Service Tag Registration 399 Application Protocol Tag: RELAY 401 Intended usage: See Section 3. 403 Interoperability considerations: N/A 405 Security considerations: See Section 5. 407 Relevant publications: This document. 409 [Note to RFC Editor: Replace "This document" with reference to this 410 document] 412 Contact information: Marc Petit-Huguenin 414 Author/Change controller: The IESG 416 6.2. turn.udp Application Protocol Tag Registration 418 Application Protocol Tag: turn.udp 420 Intended usage: See Section 3. 422 Interoperability considerations: N/A 424 Security considerations: See Section 5. 426 Relevant publications: This document. 428 [Note to RFC Editor: Replace "This document" with reference to this 429 document] 431 Contact information: Marc Petit-Huguenin 433 Author/Change controller: The IESG 435 6.3. turn.tcp Application Protocol Tag Registration 437 Application Protocol Tag: turn.tcp 439 Intended usage: See Section 3. 441 Interoperability considerations: 443 Security considerations: See Section 5. 445 Relevant publications: This document. 447 [Note to RFC Editor: Replace "This document" with reference to this 448 document] 450 Contact information: Marc Petit-Huguenin 452 Author/Change controller: The IESG 454 6.4. turn.tls Application Protocol Tag Registration 456 Application Protocol Tag: turn.tls 458 Intended usage: See Section 3. 460 Interoperability considerations: N/A 462 Security considerations: See Section 5. 464 Relevant publications: This document. 466 [Note to RFC Editor: Replace "This document" with reference to this 467 document] 469 Contact information: Marc Petit-Huguenin 470 Author/Change controller: The IESG 472 7. Acknowledgements 474 Thanks to Cullen Jennings, Alexey Melnikov, Scott Bradner, Spencer 475 Dawkins, Pasi Eronen, Margaret Wasserman, Magnus Westerlund, Juergen 476 Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E. 477 Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes and Jim Kleck for 478 their comments, suggestions and questions that helped to improve this 479 document. 481 This document was written with the xml2rfc tool described in 482 [RFC2629]. 484 8. References 486 8.1. Normative References 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, March 1997. 491 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 492 specifying the location of services (DNS SRV)", RFC 2782, 493 February 2000. 495 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 496 Service Location Using SRV RRs and the Dynamic Delegation 497 Discovery Service (DDDS)", RFC 3958, January 2005. 499 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 500 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 502 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 503 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 504 October 2008. 506 [TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 507 Relays around NAT (TURN): Relay Extensions to Session 508 Traversal Utilities for NAT (STUN)", 509 draft-ietf-behave-turn-16 (work in progress), July 2009. 511 8.2. Informative References 513 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 514 June 1999. 516 [TURN-URI] 517 Petit-Huguenin, M., "Traversal Using Relays around NAT 518 (TURN) Uniform Resource Identifiers", 519 draft-petithuguenin-behave-turn-uri-bis-01 (work in 520 progress), February 2010. 522 [REF-IMPL] 523 Petit-Huguenin, M., "Reference Implementation of TURN 524 resolver and TURN URI parser", January 2010, . 527 Appendix A. Release notes 529 This section must be removed before publication as an RFC. 531 A.1. Modifications between ietf-10 and ietf-09 533 o Clarified that the resolution mechanism is for choosing the 534 transport between the TURN client and the TURN server, not the 535 transport used by the allocation. 537 A.2. Modifications between ietf-09 and ietf-08 539 o Clarified that the identity to use for server certificate 540 verification is 541 o Moved the reference implementation reference to the informative 542 references and changed the URL to something more stable. 544 A.3. Modifications between ietf-08 and ietf-07 546 o Added reference to TLS RFC. 547 o Removed usused references. 548 o Fixed reference to URI. 550 A.4. Modifications between ietf-07 and ietf-06 552 o Clarified "application code" meaning. 554 A.5. Modifications between ietf-06 and ietf-05 556 o Updated the short title to "TURN Resolution". 557 o Shorten I-D references. 558 o Nits 559 o Changed SHOULD NOT to MUST NOT for blacklist rule. 560 o Added notes to RFC editor. 562 A.6. Modifications between ietf-05 and ietf-04 564 o Moved the URI stuff to [TURN-URI]. 566 A.7. Modifications between ietf-04 and ietf-03 568 o Improved the algorithm steps. 569 o It is possible to use a TLS transport event if the scheme is 570 turn:. 571 o Clarified when to stop the resolution with an error in step 2. 572 o Added transport list filtering process. 573 o Improved security section following sec-dir review. 574 o Fixed nits reported by gen-art review. 575 o Added example for remote hosting. 576 o Removed URIs section. 577 o Editorial modification. 579 A.8. Modifications between ietf-03 and ietf-02 581 o A turn:?transport=TCP URI fails if the list of supported 582 transports contains only TLS. Using a TLS transport in this case 583 was underspecified. 584 o Reordered paragraphes in section 4. 585 o Added table for conversion of and to TURN 586 transport. 587 o Various editorial modifications. 588 o SRV algorithm changed to "...recommending an A and AAAA query." 589 o Put back the changelog for the versions before been accepted as WG 590 item. 592 A.9. Modifications between ietf-02 and ietf-01 594 o Shorten the abstract so it does not overflow on the second page. 595 o Added text to explicitly say that the resolution is only to create 596 an allocation. 597 o Added text about failures. 598 o Fixed the default port for TLS in the example. 599 o Changed some priority in the example for RFC3958 section 2.2.5. 600 o Fixed the service/protocol order for the SRV RR in the example. 601 o Removed reference to draft-wood-tae-specifying-uri-transports as 602 it has an experimental status. 604 A.10. Modifications between ietf-01 and ietf-00 606 o Fixed the contact email. 607 o Changed the IPR to trust200902. 609 o Added case for transport defined but unknown. 610 o Moved RFC 3958 to Normative References. 611 o Added study of draft-wood-tae-specifying-uri-transports in TODO 612 list. 614 A.11. Modifications between ietf-00 and petithuguenin-03 616 o Renamed the document to "draft-ietf-behave-turn-uri". 617 o Changed author affiliation. 618 o Fixed the text in the IANA considerations. 620 A.12. Modifications between petithuguenin-03 and petithuguenin-02 622 o Added Running Code Consideration section. 623 o Added Remote Hosting example in introduction. 624 o Changed back to opaque URIs because of RFC4395 Section 2.2. Now 625 use "?" as separator. 626 o Added IANA considerations section. 627 o Added security considerations section. 629 A.13. Modifications between petithuguenin-02 and petithuguenin-01 631 o Receiving a successful Allocate response stops the resolution 632 mechanism and the resolution context must be discarded after this. 633 o Changed from opaque to hierarchical URIs because the ";" character 634 is used in . 635 o Various nits. 637 A.14. Modifications between petithuguenin-01 and petithuguenin-00 639 o Added in the ABNF. 640 o Use the and "literal" usages for free-form text defined 641 by RFC5234. 642 o Fixed various typos. 643 o Put the rule to convert and to a TURN 644 transport in a separate paragraph. 645 o Modified the SRV usage to be in line with RFC 2782. 646 o Clarified that the NAPTR protocol ranking must be used before the 647 application ranking. 648 o Added an example. 649 o Added release notes. 651 A.15. Design Notes 653 o The Application Service Tag is "RELAY" so other relaying 654 mechanisms than TURN (e.g., TWIST) can be registered as 655 Application Protocol Tags. 657 o S-NAPTR was preferred to U-NAPTR because there is no use case for 658 U-NAPTR. 659 o Adding optional capabilities (IPv6 allocation, preserve bit, 660 etc...) in the resolution process was rejected at the Dublin 661 meeting. 663 Author's Address 665 Marc Petit-Huguenin 666 (Unaffiliated) 668 Email: petithug@acm.org