idnits 2.17.1 draft-ietf-behave-turn-uri-09.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 (January 30, 2010) is 5193 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 January 30, 2010 5 Expires: August 3, 2010 7 Traversal Using Relays around NAT (TURN) Resolution Mechanism 8 draft-ietf-behave-turn-uri-09 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 August 3, 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 . . . . . . . . . . . . . . . . . . . . . . 7 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-09 and ietf-08 . . . . . . . . 12 75 A.2. Modifications between ietf-08 and ietf-07 . . . . . . . . 12 76 A.3. Modifications between ietf-07 and ietf-06 . . . . . . . . 12 77 A.4. Modifications between ietf-06 and ietf-05 . . . . . . . . 12 78 A.5. Modifications between ietf-05 and ietf-04 . . . . . . . . 12 79 A.6. Modifications between ietf-04 and ietf-03 . . . . . . . . 12 80 A.7. Modifications between ietf-03 and ietf-02 . . . . . . . . 13 81 A.8. Modifications between ietf-02 and ietf-01 . . . . . . . . 13 82 A.9. Modifications between ietf-01 and ietf-00 . . . . . . . . 13 83 A.10. Modifications between ietf-00 and petithuguenin-03 . . . . 13 84 A.11. Modifications between petithuguenin-03 and 85 petithuguenin-02 . . . . . . . . . . . . . . . . . . . . . 14 86 A.12. Modifications between petithuguenin-02 and 87 petithuguenin-01 . . . . . . . . . . . . . . . . . . . . . 14 88 A.13. Modifications between petithuguenin-01 and 89 petithuguenin-00 . . . . . . . . . . . . . . . . . . . . . 14 90 A.14. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 14 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 The TURN specification [TURN] defines a process for a TURN client to 96 find TURN servers by using DNS SRV resource records, but this process 97 does not let the TURN server administrators provision the preferred 98 TURN transport protocol between the client and the server and does 99 not allow the TURN client to discover this preference. This document 100 defines an S-NAPTR application [RFC3958] for this purpose. This 101 application defines "RELAY" as an application service tag and 102 "turn.udp", "turn.tcp", and "turn.tls" as application protocol tags. 104 Another usage of the resolution mechanism described in this document 105 would be Remote Hosting as described in [RFC3958] section 4.4. For 106 example a VoIP provider who does not want to deploy TURN servers 107 could use the servers deployed by another company but could still 108 want to provide configuration parameters to its customers without 109 explicitly showing this relationship. The mechanism permits one to 110 implement this indirection, without preventing the company hosting 111 the TURN servers from managing them as it sees fit. 113 [TURN-URI] can be used as a convenient way of carrying the four 114 components needed by the resolution mechanism described in this 115 document. A reference implementation is available [REF-IMPL]. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. Resolution Mechanism 125 The resolution mechanism is used only to create an allocation. All 126 other transactions use the IP address, transport and port used for a 127 successful allocation creation. 129 The resolution algorithm uses a boolean flag, ; an IP address 130 or domain name, ; a port number that can be empty, ; and 131 a transport name that can be "udp", "tcp" or empty, as 132 input. This four parameters are part of the user configuration of 133 the TURN client. The resolution mechanism also uses as input a list 134 ordered by preference of TURN transports (UDP, TCP, TLS) supported 135 that is provided by the application using the TURN client. This list 136 reflects the capabilities and preferences of the application code 137 that is using the S-NAPTR resolver and TURN client, as opposed to the 138 configuration parameters that reflect the preferences of the user of 139 the application. The output of the algorithm is a list of {IP 140 address, transport, port} tuples that a TURN client can try in order 141 to create an allocation on a TURN server. 143 An Allocate error response as specified in section 6.4 of [TURN] is 144 processed as a failure as specified by [RFC3958] section 2.2.4. The 145 resolution stops when a TURN client gets a successful Allocate 146 response from a TURN server. After an allocation succeeds or all the 147 allocations fail, the resolution context MUST be discarded and the 148 resolution algorithm MUST be restarted from the beginning for any 149 subsequent allocation. Servers blacklisted as described in section 150 6.4 of [TURN] MUST NOT be used for the specified duration even if 151 returned by a subsequent resolution. 153 First the resolution algorithm checks that the parameters can be 154 resolved with the list of TURN transports supported by the 155 application: 157 o If is false and is defined as "udp" but the 158 list of TURN transports supported by the application does not 159 contain UDP then the resolution MUST stop with an error. 160 o If is false and is defined as "tcp" but the 161 list of TURN transports supported by the application does not 162 contain TCP then the resolution MUST stop with an error. 163 o If is true and is defined as "udp" then the 164 algorithm MUST stop with an error. 165 o If is true and is defined as "tcp" but the 166 list of TURN transports supported by the application does not 167 contain TLS then the resolution MUST stop with an error. 168 o If is true and is not defined but the list of 169 TURN transports supported by the application does not contain TLS 170 then the resolution MUST stop with an error. 171 o If is defined but unknown then the resolution MUST 172 stop with an error. 174 After verifying the validity of the parameters, the algorithm filters 175 the list of TURN transports supported by the application by removing 176 the UDP and TCP TURN transport if is true. If the list of 177 TURN transports is empty after this filtering, the resolution MUST 178 stop with an error. 180 After filtering the list of TURN transports supported by the 181 application, the algorithm applies the steps described below. Note 182 that in some steps, and have to be converted to 183 a TURN transport. If is false and is defined as 184 "udp" then the TURN UDP transport is used. If is false and 185 is defined as "tcp" then the TURN TCP transport is used. 186 If is true and is defined as "tcp" then the TURN 187 TLS transport is used. This is summarized in Table 1. 189 +----------+-------------+----------------+ 190 | | | TURN Transport | 191 +----------+-------------+----------------+ 192 | false | "udp" | UDP | 193 | false | "tcp" | TCP | 194 | true | "tcp" | TLS | 195 +----------+-------------+----------------+ 197 Table 1 199 1. If is an IP address, then it indicates the specific IP 200 address to be used. If is not defined, the default port 201 declared in [TURN] for the "turn" SRV service name if is 202 false, or the "turns" SRV service name if is true MUST 203 be used for contacting the TURN server. If is 204 defined then and are converted to a TURN 205 transport as specified in Table 1. If is not 206 defined, the filtered TURN transports supported by the 207 application are tried by preference order. If the TURN client 208 cannot contact a TURN server with this IP address and port on any 209 of the transports supported by the application then the 210 resolution MUST stop with an error. 212 2. If is a domain name and is defined, then is 213 resolved to a list of IP addresses via DNS A and AAAA queries. 214 If is defined, then and are 215 converted to a TURN transport as specified in Table 1. If 216 is not defined, the filtered TURN transports 217 supported by the application are tried in preference order. The 218 TURN client can choose the order to contact the resolved IP 219 addresses in any implementation-specific way. If the TURN client 220 cannot contact a TURN server with this port, the transport or 221 list of transports, and the resolved IP addresses, then the 222 resolution MUST stop with an error. 224 3. If is a domain name and is not defined but 225 is defined, then the SRV algorithm defined in 226 [RFC2782] is used to generate a list of IP address and port 227 tuples. is used as Name, a value of false for as 228 "turn" for Service, a value of true for as "turns" for 229 Service and as Protocol in the SRV algorithm. 230 and are converted to a TURN transport as 231 specified in Table 1 and this transport is used with each tuple 232 for contacting the TURN server. The SRV algorithm recommends 233 doing an A query if the SRV query returns an error or no SRV RR; 234 in this case the default port declared in [TURN] for the "turn" 235 SRV service name if is false, or the "turns" SRV service 236 name if is true MUST be used for contacting the TURN 237 server. Also in this case, this specification modifies the SRV 238 algorithm by recommending an A and AAAA query. If the TURN 239 client cannot contact a TURN server at any of the IP address and 240 port tuples returned by the SRV algorithm with the transport 241 converted from and then the resolution MUST 242 stop with an error. 244 4. If is a domain name and and are not 245 defined, then is converted to an ordered list of IP 246 address, port and transport tuples via the S-NAPTR algorithm 247 defined in [RFC3958] by using as the initial target domain 248 name and "RELAY" as the Application Service Tag. The filtered 249 list of TURN transports supported by the application are 250 converted in Application Protocol Tags by using "turn.udp" if the 251 TURN transport is UDP, "turn.tcp" if the TURN transport is TCP 252 and "turn.tls" if the TURN transport is TLS. The order to try 253 the Application Protocol Tags is provided by the ranking of the 254 first set of NAPTR records. If multiple Application Protocol 255 Tags have the same ranking, the preferred order set by the 256 application is used. If the first NAPTR query fails, the 257 processing continues in step 5. If the TURN client cannot 258 contact a TURN server with any of the IP address, port and 259 transport tuples returned by the S-NAPTR algorithm then the 260 resolution MUST stop with an error. 262 5. If the first NAPTR query in the previous step does not return any 263 result then the SRV algorithm defined in [RFC2782] is used to 264 generate a list of IP address and port tuples. The SRV algorithm 265 is applied by using each transport in the filtered list of TURN 266 transports supported by the application for the Protocol, 267 for the Name, "turn" for the Service if is false or 268 "turns" for the Service if is true. The same transport 269 that was used to generate a list of tuples is used with each of 270 these tuples for contacting the TURN server. The SRV algorithm 271 recommends doing an A query if the SRV query returns an error or 272 no SRV RR; in this case the default port declared in [TURN] for 273 the "turn" SRV service name if is false, or the "turns" 274 SRV service name if is true MUST be used for contacting 275 the TURN server. Also in this case, this specification modifies 276 the SRV algorithm by recommending an A and AAAA query. If the 277 TURN client cannot contact a TURN server at any of the IP address 278 and port tuples returned by the SRV algorithm with the transports 279 from the filtered list then the resolution MUST stop with an 280 error. 282 4. Examples 284 4.1. Multiple Protocols 286 With the DNS RRs in Figure 1 and an ordered TURN transport list of 287 {TLS, TCP, UDP}, the resolution algorithm will convert the parameters 288 with a value of false, with a value of "example.net" 289 and and been empty to the list of IP addresses, 290 port and protocol tuples in Table 2. 292 example.net. 293 IN NAPTR 100 10 "" RELAY:turn.udp "" datagram.example.net. 294 IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net. 296 datagram.example.net. 297 IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net. 299 stream.example.net. 300 IN NAPTR 100 10 S RELAY:turn.tcp "" _turn._tcp.example.net. 301 IN NAPTR 200 10 A RELAY:turn.tls "" a.example.net. 303 _turn._udp.example.net. 304 IN SRV 0 0 3478 a.example.net. 306 _turn._tcp.example.net. 307 IN SRV 0 0 5000 a.example.net. 309 a.example.net. 310 IN A 192.0.2.1 312 Figure 1 314 +-------+----------+------------+------+ 315 | Order | Protocol | IP address | Port | 316 +-------+----------+------------+------+ 317 | 1 | UDP | 192.0.2.1 | 3478 | 318 | 2 | TLS | 192.0.2.1 | 5349 | 319 | 3 | TCP | 192.0.2.1 | 5000 | 320 +-------+----------+------------+------+ 322 Table 2 324 4.2. Remote Hosting 326 In the example in Figure 2, a VoIP provider (example.com) is using 327 the TURN servers managed by the administrators of the example.net 328 domain (defined in Figure 1). The resolution algorithm using the 329 ordered TURN transport list of {TLS, TCP, UDP} would convert the same 330 parameters than in the previous example but with the parameter 331 equal to "example.com" to the list of IP addresses, port and protocol 332 tuples in Table 2. 334 example.com. 335 IN NAPTR 100 10 "" RELAY:turn.udp:turn.tcp:turn.tls "" example.net. 337 Figure 2 339 4.3. Compatibility with TURN 341 In deployments where it is not possible to guarantee that all TURN 342 clients will support the resolution mechanism described in this 343 document, the DNS configuration should be done in a way that works 344 with both this resolution mechanism and the mechanism described in 345 [TURN]. The DNS RRs in Figure 3 can be used in conjunction with the 346 DNS RRs in Figure 1 and Figure 2 for this purpose. 348 _turn._udp.example.com. 349 IN SRV 0 0 3478 a.example.net. 351 _turn._tcp.example.com. 352 IN SRV 0 0 5000 a.example.net. 354 _turns._tcp.example.com. 355 IN SRV 0 0 5349 a.example.net. 357 Figure 3 359 5. Security Considerations 361 Security considerations for TURN are discussed in [TURN]. 363 The Application Service Tag and Application Protocol Tags defined in 364 this document do not introduce any specific security issues beyond 365 the security considerations discussed in [RFC3958]. [RFC3958] 366 requests that an S-NAPTR application defines some form of end-to-end 367 authentication to ensure that the correct destination has been 368 reached. This is achieved by the Long-Term Credential Mechanism 369 defined in [RFC5389], which is mandatory for [TURN]. 371 Additionally the usage of TLS [RFC5246] has the capability to address 372 the requirement. In this case the client MUST verify the identity of 373 the server by following the identification procedure in section 7.2.2 374 of [RFC5389] and by using the value of the parameter as the 375 identity of the server to be verified. 377 An implication of this is that the server's certificate could need to 378 be changed when SRV or NAPTR records are added. For example, a 379 client using just A/AAAA records, and configured with 380 "turnserver.example.net", expects to find the name 381 "turnserver.example.net" in the certificate. If a second client uses 382 SRV records and is configured with parameter "example.com", it 383 expects to find "example.com" in the certificate, even if the SRV 384 record at _turns._tcp.example.com points to turnserver.example.net. 386 6. IANA Considerations 388 This section contains the registration information for one S-NAPTR 389 Application Service Tag and three S-NAPTR Application Protocol Tags 390 (in accordance with [RFC3958]). 392 6.1. RELAY Application Service Tag Registration 394 Application Protocol Tag: RELAY 396 Intended usage: See Section 3. 398 Interoperability considerations: N/A 400 Security considerations: See Section 5. 402 Relevant publications: This document. 404 [Note to RFC Editor: Replace "This document" with reference to this 405 document] 407 Contact information: Marc Petit-Huguenin 409 Author/Change controller: The IESG 411 6.2. turn.udp Application Protocol Tag Registration 413 Application Protocol Tag: turn.udp 415 Intended usage: See Section 3. 417 Interoperability considerations: N/A 419 Security considerations: See Section 5. 421 Relevant publications: This document. 423 [Note to RFC Editor: Replace "This document" with reference to this 424 document] 426 Contact information: Marc Petit-Huguenin 428 Author/Change controller: The IESG 430 6.3. turn.tcp Application Protocol Tag Registration 432 Application Protocol Tag: turn.tcp 434 Intended usage: See Section 3. 436 Interoperability considerations: 438 Security considerations: See Section 5. 440 Relevant publications: This document. 442 [Note to RFC Editor: Replace "This document" with reference to this 443 document] 445 Contact information: Marc Petit-Huguenin 447 Author/Change controller: The IESG 449 6.4. turn.tls Application Protocol Tag Registration 451 Application Protocol Tag: turn.tls 453 Intended usage: See Section 3. 455 Interoperability considerations: N/A 457 Security considerations: See Section 5. 459 Relevant publications: This document. 461 [Note to RFC Editor: Replace "This document" with reference to this 462 document] 464 Contact information: Marc Petit-Huguenin 466 Author/Change controller: The IESG 468 7. Acknowledgements 470 Thanks to Cullen Jennings, Alexey Melnikov, Scott Bradner, Spencer 471 Dawkins, Pasi Eronen, Margaret Wasserman, Magnus Westerlund, Juergen 472 Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E. 473 Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes and Jim Kleck for 474 their comments, suggestions and questions that helped to improve this 475 document. 477 This document was written with the xml2rfc tool described in 478 [RFC2629]. 480 8. References 482 8.1. Normative References 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, March 1997. 487 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 488 specifying the location of services (DNS SRV)", RFC 2782, 489 February 2000. 491 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 492 Service Location Using SRV RRs and the Dynamic Delegation 493 Discovery Service (DDDS)", RFC 3958, January 2005. 495 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 496 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 498 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 499 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 500 October 2008. 502 [TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 503 Relays around NAT (TURN): Relay Extensions to Session 504 Traversal Utilities for NAT (STUN)", 505 draft-ietf-behave-turn-16 (work in progress), July 2009. 507 8.2. Informative References 509 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 510 June 1999. 512 [TURN-URI] 513 Petit-Huguenin, M., "Traversal Using Relays around NAT 514 (TURN) Uniform Resource Identifiers", 515 draft-petithuguenin-behave-turn-uri-bis-01 (work in 516 progress), January 2010. 518 [REF-IMPL] 519 Petit-Huguenin, M., "Reference Implementation of TURN 520 resolver and TURN URI parser", January 2010, . 523 Appendix A. Release notes 525 This section must be removed before publication as an RFC. 527 A.1. Modifications between ietf-09 and ietf-08 529 o Clarified that the identity to use for server certificate 530 verification is 531 o Moved the reference implementation reference to the informative 532 references and changed the URL to something more stable. 534 A.2. Modifications between ietf-08 and ietf-07 536 o Added reference to TLS RFC. 537 o Removed usused references. 538 o Fixed reference to URI. 540 A.3. Modifications between ietf-07 and ietf-06 542 o Clarified "application code" meaning. 544 A.4. Modifications between ietf-06 and ietf-05 546 o Updated the short title to "TURN Resolution". 547 o Shorten I-D references. 548 o Nits 549 o Changed SHOULD NOT to MUST NOT for blacklist rule. 550 o Added notes to RFC editor. 552 A.5. Modifications between ietf-05 and ietf-04 554 o Moved the URI stuff to [TURN-URI]. 556 A.6. Modifications between ietf-04 and ietf-03 558 o Improved the algorithm steps. 559 o It is possible to use a TLS transport event if the scheme is 560 turn:. 562 o Clarified when to stop the resolution with an error in step 2. 563 o Added transport list filtering process. 564 o Improved security section following sec-dir review. 565 o Fixed nits reported by gen-art review. 566 o Added example for remote hosting. 567 o Removed URIs section. 568 o Editorial modification. 570 A.7. Modifications between ietf-03 and ietf-02 572 o A turn:?transport=TCP URI fails if the list of supported 573 transports contains only TLS. Using a TLS transport in this case 574 was underspecified. 575 o Reordered paragraphes in section 4. 576 o Added table for conversion of and to TURN 577 transport. 578 o Various editorial modifications. 579 o SRV algorithm changed to "...recommending an A and AAAA query." 580 o Put back the changelog for the versions before been accepted as WG 581 item. 583 A.8. Modifications between ietf-02 and ietf-01 585 o Shorten the abstract so it does not overflow on the second page. 586 o Added text to explicitly say that the resolution is only to create 587 an allocation. 588 o Added text about failures. 589 o Fixed the default port for TLS in the example. 590 o Changed some priority in the example for RFC3958 section 2.2.5. 591 o Fixed the service/protocol order for the SRV RR in the example. 592 o Removed reference to draft-wood-tae-specifying-uri-transports as 593 it has an experimental status. 595 A.9. Modifications between ietf-01 and ietf-00 597 o Fixed the contact email. 598 o Changed the IPR to trust200902. 599 o Added case for transport defined but unknown. 600 o Moved RFC 3958 to Normative References. 601 o Added study of draft-wood-tae-specifying-uri-transports in TODO 602 list. 604 A.10. Modifications between ietf-00 and petithuguenin-03 606 o Renamed the document to "draft-ietf-behave-turn-uri". 607 o Changed author affiliation. 609 o Fixed the text in the IANA considerations. 611 A.11. Modifications between petithuguenin-03 and petithuguenin-02 613 o Added Running Code Consideration section. 614 o Added Remote Hosting example in introduction. 615 o Changed back to opaque URIs because of RFC4395 Section 2.2. Now 616 use "?" as separator. 617 o Added IANA considerations section. 618 o Added security considerations section. 620 A.12. Modifications between petithuguenin-02 and petithuguenin-01 622 o Receiving a successful Allocate response stops the resolution 623 mechanism and the resolution context must be discarded after this. 624 o Changed from opaque to hierarchical URIs because the ";" character 625 is used in . 626 o Various nits. 628 A.13. Modifications between petithuguenin-01 and petithuguenin-00 630 o Added in the ABNF. 631 o Use the and "literal" usages for free-form text defined 632 by RFC5234. 633 o Fixed various typos. 634 o Put the rule to convert and to a TURN 635 transport in a separate paragraph. 636 o Modified the SRV usage to be in line with RFC 2782. 637 o Clarified that the NAPTR protocol ranking must be used before the 638 application ranking. 639 o Added an example. 640 o Added release notes. 642 A.14. Design Notes 644 o The Application Service Tag is "RELAY" so other relaying 645 mechanisms than TURN (e.g., TWIST) can be registered as 646 Application Protocol Tags. 647 o S-NAPTR was preferred to U-NAPTR because there is no use case for 648 U-NAPTR. 649 o Adding optional capabilities (IPv6 allocation, preserve bit, 650 etc...) in the resolution process was rejected at the Dublin 651 meeting. 653 Author's Address 655 Marc Petit-Huguenin 656 (Unaffiliated) 658 Email: petithug@acm.org