idnits 2.17.1 draft-ietf-behave-turn-uri-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (November 9, 2009) is 5280 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 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 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 November 9, 2009 5 Expires: May 13, 2010 7 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers 8 draft-ietf-behave-turn-uri-04 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on May 13, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document defines two URI schemes and the resolution mechanism to 47 generate a list of server transport addresses that can be tried to 48 create a Traversal Using Relays around NAT (TURN) allocation. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Syntax of a TURN or TURNS URI . . . . . . . . . . . . . . . . 3 55 4. Resolution Mechanism . . . . . . . . . . . . . . . . . . . . . 4 56 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 5.1. Multiple Protocols . . . . . . . . . . . . . . . . . . . . 7 58 5.2. Remote Hosting . . . . . . . . . . . . . . . . . . . . . . 8 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 7.1. TURN URI Registration . . . . . . . . . . . . . . . . . . 9 62 7.2. TURNS URI Registration . . . . . . . . . . . . . . . . . . 9 63 7.3. RELAY Application Service Tag Registration . . . . . . . . 10 64 7.4. turn.udp Application Protocol Tag Registration . . . . . . 10 65 7.5. turn.tcp Application Protocol Tag Registration . . . . . . 10 66 7.6. turn.tls Application Protocol Tag Registration . . . . . . 11 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 71 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 12 72 A.1. Modifications between ietf-04 and ietf-03 . . . . . . . . 12 73 A.2. Modifications between ietf-03 and ietf-02 . . . . . . . . 13 74 A.3. Modifications between ietf-02 and ietf-01 . . . . . . . . 13 75 A.4. Modifications between ietf-01 and ietf-00 . . . . . . . . 13 76 A.5. Modifications between petithuguenin-03 and ietf-00 . . . . 13 77 A.6. Modifications between petithuguenin-03 and 78 petithuguenin-02 . . . . . . . . . . . . . . . . . . . . . 13 79 A.7. Modifications between petithuguenin-02 and 80 petithuguenin-01 . . . . . . . . . . . . . . . . . . . . . 14 81 A.8. Modifications between petithuguenin-01 and 82 petithuguenin-00 . . . . . . . . . . . . . . . . . . . . . 14 83 A.9. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 14 84 A.10. Running Code Considerations . . . . . . . . . . . . . . . 15 85 A.11. TODO List . . . . . . . . . . . . . . . . . . . . . . . . 15 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 The TURN specification [I-D.ietf-behave-turn] defines a process for a 91 TURN client to find TURN servers by using DNS SRV resource records, 92 but this process does not let the TURN server administrators 93 provision the preferred TURN transport protocol between the client 94 and the server and for the TURN client to discover this preference. 95 This document defines an S-NAPTR application [RFC3958] for this 96 purpose. This application defines "RELAY" as an application service 97 tag and "turn.udp", "turn.tcp", and "turn.tls" as application 98 protocol tags. 100 To simplify the provisioning of TURN clients, this document also 101 defines a TURN and a TURNS URI scheme and a resolution mechanism to 102 convert these URIs into a list of IP addresses, ports and TURN 103 transport protocols. 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 see fit. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 3. Syntax of a TURN or TURNS URI 122 A TURN/TURNS URI has the following ABNF syntax [RFC5234]: 124 turnURI = scheme ":" host [ ":" port ] [ "?transport=" transport ] 125 scheme = "turn" / "turns" 126 transport = "udp" / "tcp" / transport-ext 127 transport-ext = 1*unreserved 129 , and are specified in [RFC3986]. 131 Note that the usage of components defined in the [RFC3986] as part of 132 a generic hierarchical URI does not mean that a TURN/TURNS URI is 133 hierarchical. 135 4. Resolution Mechanism 137 The resolution mechanism is used only to create an allocation. All 138 other transactions use the IP address, transport and port used for a 139 successful allocation creation. 141 The resolution algorithm uses , , and 142 from the TURN URI as input. It also uses as input a list 143 ordered by preference of TURN transports (UDP, TCP, TLS) supported 144 that is provided by the application using the TURN client. This list 145 reflects the capabilities and preferences of the application code as 146 opposed to the TURN URI that reflects the preferences of the user of 147 the application. The output of the algorithm is a list of {IP 148 address, transport, port} tuples that a TURN client can try in order 149 to create an allocation on a TURN server. 151 An Allocate error response as specified in section 6.4 of 152 [I-D.ietf-behave-turn] is processed as a failure as specified by 153 [RFC3958] section 2.2.4. The resolution stops when a TURN client 154 gets a successful Allocate response from a TURN server. After an 155 allocation succeeds or all the allocations fail, the resolution 156 context MUST be discarded and the resolution algorithm MUST be 157 restarted from the beginning for any subsequent allocation. Servers 158 blacklisted as described in section 6.4 of [I-D.ietf-behave-turn] 159 SHOULD NOT be used for the specified duration even if returned by a 160 subsequent resolution. 162 First the resolution algorithm checks that the URI can be resolved 163 with the list of TURN transports supported by the application: 165 o If is defined as "turn" and is defined as 166 "udp" but the list of TURN transports supported by the application 167 does not contain UDP then the resolution MUST stop with an error. 168 o If is defined as "turn" and is defined as 169 "tcp" but the list of TURN transports supported by the application 170 does not contain TCP then the resolution MUST stop with an error. 171 o If is defined as "turns" and is defined as 172 "udp" then the algorithm MUST stop with an error. 173 o If is defined as "turns" and is defined as 174 "tcp" but the list of TURN transports supported by the application 175 does not contain TLS then the resolution MUST stop with an error. 176 o If is defined as "turns" and is not defined 177 but the list of TURN transports supported by the application does 178 not contain TLS then the resolution MUST stop with an error. 179 o If is defined but unknown then the resolution MUST 180 stop with an error. 182 After verifying the validity of the URI elements, the algorithm 183 filters the list of TURN transports supported by the application by 184 removing the UDP and TCP TURN transport if the is defined as 185 "turns". If the list of TURN transports is empty after this 186 filtering, the resolution MUST stop with an error. 188 After filtering the list of TURN transports supported by the 189 application, the algorithm applies the steps described below. Note 190 that in some steps, and have to be converted to 191 a TURN transport. If is defined as "turn" and 192 is defined as "udp" then the TURN UDP transport is used. If 193 is defined as "turn" and is defined as "tcp" then the 194 TURN TCP transport is used. If is defined as "turns" and 195 is defined as "tcp" then the TURN TLS transport is used. 196 This is summarized in Table 1. 198 +----------+-------------+----------------+ 199 | | | TURN Transport | 200 +----------+-------------+----------------+ 201 | "turn" | "udp" | UDP | 202 | "turn" | "tcp" | TCP | 203 | "turns" | "tcp" | TLS | 204 +----------+-------------+----------------+ 206 Table 1 208 1. If is an IP address, then it indicates the specific IP 209 address to be used. If is not defined, the default port 210 declared in [I-D.ietf-behave-turn] for the SRV service name 211 defined in is used. If is defined then 212 and are converted to a TURN transport as 213 specified in Table 1. If is not defined, the 214 filtered TURN transports supported by the application are tried 215 by preference order. If the TURN client cannot contact a TURN 216 server with this IP address and port on any of the transports 217 supported by the application then the resolution MUST stop with 218 an error. 220 2. If is a domain name and is defined, then is 221 resolved to a list of IP addresses via DNS A and AAAA queries. 222 If is defined, then and are 223 converted to a TURN transport as specified in Table 1. If 224 is not defined, the filtered TURN transports 225 supported by the application are tried in preference order. The 226 TURN client can choose the order to contact the resolved IP 227 addresses in any implementation-specific way. If the TURN client 228 cannot contact a TURN server with this port, the transport or 229 list of transports, and the resolved IP addresses, then the 230 resolution MUST stop with an error. 232 3. If is a domain name and is not defined but 233 is defined, then the SRV algorithm defined in 234 [RFC2782] is used to generate a list of IP address and port 235 tuples. is used as Name, as Service and 236 as Protocol in the SRV algorithm. and 237 are converted to a TURN transport as specified in 238 Table 1 and this transport is used with each tuple for contacting 239 the TURN server. The SRV algorithm recommends doing an A query 240 if the SRV query returns an error or no SRV RR; in this case the 241 default port declared in [I-D.ietf-behave-turn] for the SRV 242 service name defined in MUST be used for contacting the 243 TURN server. Also in this case, this specification modifies the 244 SRV algorithm by recommending an A and AAAA query. If the TURN 245 client cannot contact a TURN server at any of the IP address and 246 port tuples returned by the SRV algorithm with the transport 247 converted from the and then the resolution 248 MUST stop with an error. 250 4. If is a domain name and and are not 251 defined, then is converted to an ordered list of IP 252 address, port and transport tuples via the S-NAPTR algorithm 253 defined in [RFC3958] by using as the initial target domain 254 name and "RELAY" as the Application Service Tag. The filtered 255 list of TURN transports supported by the application are 256 converted in Application Protocol Tags by using "turn.udp" if the 257 TURN transport is UDP, "turn.tcp" if the TURN transport is TCP 258 and "turn.tls" if the TURN transport is TLS. The order to try 259 the Application Protocol Tags is provided by the ranking of the 260 first set of NAPTR records. If multiple Application Protocol 261 Tags have the same ranking, the preferred order set by the 262 application is used. If the first NAPTR query fails, the 263 processing continues in step 5. If the TURN client cannot 264 contact a TURN server with any of the IP address, port and 265 transport tuples returned by the S-NAPTR algorithm then the 266 resolution MUST stop with an error. 268 5. If the first NAPTR query in the previous step does not return any 269 result then the SRV algorithm defined in [RFC2782] is used to 270 generate a list of IP address and port tuples. The SRV algorithm 271 is applied by using each transport in the filtered list of TURN 272 transports supported by the application for the Protocol, 273 for the Name and for the Service. The same transport 274 that was used to generate a list of tuples is used with each of 275 this 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 278 [I-D.ietf-behave-turn] for the SRV service name defined in 279 MUST be used for contacting the TURN server. Also in 280 this case, this specification modifies the SRV algorithm by 281 recommending an A and AAAA query. If the TURN client cannot 282 contact a TURN server at any of the IP address and port tuples 283 returned by the SRV algorithm with the transports from the 284 filtered list then the resolution MUST stop with an error. 286 5. Examples 288 5.1. Multiple Protocols 290 With the DNS RRs in Figure 1 and an ordered TURN transport list of 291 {TLS, TCP, UDP}, the resolution algorithm will convert the "turn: 292 example.net" URI to the list of IP addresses, port and protocol 293 tuples in Table 2. 295 example.net. 296 IN NAPTR 100 10 "" RELAY:turn.udp "" datagram.example.net. 297 IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net. 299 datagram.example.net. 300 IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net. 302 stream.example.net. 303 IN NAPTR 100 10 S RELAY:turn.tcp "" _turn._tcp.example.net. 304 IN NAPTR 200 10 A RELAY:turn.tls "" a.example.net. 306 _turn._udp.example.net. 307 IN SRV 0 0 3478 a.example.net. 309 _turn._tcp.example.net. 310 IN SRV 0 0 5000 a.example.net. 312 a.example.net. 313 IN A 192.0.2.1 315 Figure 1 317 +-------+----------+------------+------+ 318 | Order | Protocol | IP address | Port | 319 +-------+----------+------------+------+ 320 | 1 | UDP | 192.0.2.1 | 3478 | 321 | 2 | TLS | 192.0.2.1 | 5349 | 322 | 3 | TCP | 192.0.2.1 | 5000 | 323 +-------+----------+------------+------+ 325 Table 2 327 5.2. Remote Hosting 329 In the example in Figure 2, a VoIP provider (example.com) is using 330 the TURN servers managed by the administrators of the example.net 331 domain (defined in Figure 1). The resolution algorithm using the 332 ordered TURN transport list of {TLS, TCP, UDP} would convert the 333 "turn:example.com" URI to the list of IP addresses, port and protocol 334 tuples in Table 2. 336 example.com. 337 IN NAPTR 100 10 "" "RELAY:turn.udp:turn.tcp:turn.tls" "" example.net. 339 Figure 2 341 6. Security Considerations 343 Security considerations for TURN are discussed in 344 [I-D.ietf-behave-turn]. 346 The Application Service Tag and Application Protocol Tags defined in 347 this document do not introduce any specific security issues beyond 348 the security considerations discussed in [RFC3958]. [RFC3958] 349 requests that an S-NAPTR application defines some form of end-to-end 350 authentication to ensure that the correct destination has been 351 reached. This is achieved for "turn" and "turns" URIs by the Long- 352 Term Credential Mechanism defined in [RFC5389], which is mandatory 353 for TURN [I-D.ietf-behave-turn]. Additionally for a "turns" URI, the 354 usage of TLS has the capability to address the requirement. In this 355 case the client MUST verify the identity of the server by following 356 the identification procedure in section 7.2.2 of [RFC5389]. 358 The "turn" and "turns" URI schemes do not introduce any specific 359 security issues beyond the security considerations discussed in 360 [RFC3986]. 362 7. IANA Considerations 364 This section contains the registration information for the "turn" and 365 "turns" URI Schemes (in accordance with [RFC4395]), one S-NAPTR 366 Application Service Tag, and three S-NAPTR Application Protocol Tags 367 (in accordance with [RFC3958]). 369 7.1. TURN URI Registration 371 URI scheme name: turn 373 Status: permanent 375 URI scheme syntax: See Section 3. 377 URI scheme semantics: See Section 4. 379 Encoding considerations: There are no encoding considerations beyond 380 those in [RFC3986]. 382 Applications/protocols that use this URI scheme name: 384 The "turn" URI scheme is intended to be used by applications that 385 might need access to a TURN server. 387 Interoperability considerations: N/A 389 Security considerations: See Section 6. 391 Contact: Marc Petit-Huguenin 393 Author/Change controller: The IESG 395 References: This document. 397 7.2. TURNS URI Registration 399 URI scheme name: turns 401 Status: permanent 403 URI scheme syntax: See Section 3. 405 URI scheme semantics: See Section 4. 407 Encoding considerations: There are no encoding considerations beyond 408 those in [RFC3986]. 410 Applications/protocols that use this URI scheme name: 412 The "turns" URI scheme is intended to be used by applications that 413 might need access to a TURN server. 415 Interoperability considerations: N/A 416 Security considerations: See Section 6. 418 Contact: Marc Petit-Huguenin 420 Author/Change controller: The IESG 422 References: This document. 424 7.3. RELAY Application Service Tag Registration 426 Application Protocol Tag: RELAY 428 Intended usage: See Section 4. 430 Interoperability considerations: N/A 432 Security considerations: See Section 6. 434 Relevant publications: This document. 436 Contact information: Marc Petit-Huguenin 438 Author/Change controller: The IESG 440 7.4. turn.udp Application Protocol Tag Registration 442 Application Protocol Tag: turn.udp 444 Intended usage: See Section 4. 446 Interoperability considerations: N/A 448 Security considerations: See Section 6. 450 Relevant publications: This document. 452 Contact information: Marc Petit-Huguenin 454 Author/Change controller: The IESG 456 7.5. turn.tcp Application Protocol Tag Registration 458 Application Protocol Tag: turn.tcp 460 Intended usage: See Section 4. 462 Interoperability considerations: 464 Security considerations: See Section 6. 466 Relevant publications: This document. 468 Contact information: Marc Petit-Huguenin 470 Author/Change controller: The IESG 472 7.6. turn.tls Application Protocol Tag Registration 474 Application Protocol Tag: turn.tls 476 Intended usage: See Section 4. 478 Interoperability considerations: N/A 480 Security considerations: See Section 6. 482 Relevant publications: This document. 484 Contact information: Marc Petit-Huguenin 486 Author/Change controller: The IESG 488 8. Acknowledgements 490 Thanks to Pasi Eronen, Margaret Wasserman, Magnus Westerlund, Juergen 491 Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E. 492 Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes and Jim Kleck for 493 their comments, suggestions and questions that helped to improve this 494 document. 496 This document was written with the xml2rfc tool described in 497 [RFC2629]. 499 9. References 501 9.1. Normative References 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, March 1997. 506 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 507 specifying the location of services (DNS SRV)", RFC 2782, 508 February 2000. 510 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 511 Service Location Using SRV RRs and the Dynamic Delegation 512 Discovery Service (DDDS)", RFC 3958, January 2005. 514 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 515 Resource Identifier (URI): Generic Syntax", STD 66, 516 RFC 3986, January 2005. 518 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 519 Specifications: ABNF", STD 68, RFC 5234, January 2008. 521 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 522 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 523 October 2008. 525 [I-D.ietf-behave-turn] 526 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 527 Relays around NAT (TURN): Relay Extensions to Session 528 Traversal Utilities for NAT (STUN)", 529 draft-ietf-behave-turn-16 (work in progress), July 2009. 531 9.2. Informative References 533 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 534 June 1999. 536 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 537 Registration Procedures for New URI Schemes", BCP 35, 538 RFC 4395, February 2006. 540 Appendix A. Release notes 542 This section must be removed before publication as an RFC. 544 A.1. Modifications between ietf-04 and ietf-03 546 o Improved the algorithm steps. 547 o It is possible to use a TLS transport event if the scheme is 548 turn:. 549 o Clarified when to stop the resolution with an error in step 2. 550 o Added transport list filtering process. 551 o Improved security section following sec-dir review. 552 o Fixed nits reported by gen-art review. 553 o Added example for remote hosting. 554 o Removed URIs section. 556 o Editorial modification. 558 A.2. Modifications between ietf-03 and ietf-02 560 o A turn:?transport=TCP URI fails if the list of supported 561 transports contains only TLS. Using a TLS transport in this case 562 was underspecified. 563 o Reordered paragraphes in section 4. 564 o Added table for conversion of and to TURN 565 transport. 566 o Various editorial modifications. 567 o SRV algorithm changed to "...recommending an A and AAAA query." 568 o Put back the changelog for the versions before been accepted as WG 569 item. 571 A.3. Modifications between ietf-02 and ietf-01 573 o Shorten the abstract so it does not overflow on the second page. 574 o Added text to explicitly say that the resolution is only to create 575 an allocation. 576 o Added text about failures. 577 o Fixed the default port for TLS in the example. 578 o Changed some priority in the example for RFC3958 section 2.2.5. 579 o Fixed the service/protocol order for the SRV RR in the example. 580 o Removed reference to draft-wood-tae-specifying-uri-transports as 581 it has an experimental status. 583 A.4. Modifications between ietf-01 and ietf-00 585 o Fixed the contact email. 586 o Changed the IPR to trust200902. 587 o Added case for transport defined but unknown. 588 o Moved RFC 3958 to Normative References. 589 o Added study of draft-wood-tae-specifying-uri-transports in TODO 590 list. 592 A.5. Modifications between petithuguenin-03 and ietf-00 594 o Renamed the document to "draft-ietf-behave-turn-uri". 595 o Changed author affiliation. 596 o Fixed the text in the IANA considerations. 598 A.6. Modifications between petithuguenin-03 and petithuguenin-02 600 o Added Running Code Consideration section. 601 o Added Remote Hosting example in introduction. 603 o Changed back to opaque URIs because of [RFC4395] Section 2.2. Now 604 use "?" as separator. 605 o Added IANA considerations section. 606 o Added security considerations section. 608 A.7. Modifications between petithuguenin-02 and petithuguenin-01 610 o Receiving a successful Allocate response stops the resolution 611 mechanism and the resolution context must be discarded after this. 612 o Changed from opaque to hierarchical URIs because the ";" character 613 is used in . 614 o Various nits. 616 A.8. Modifications between petithuguenin-01 and petithuguenin-00 618 o Added in the ABNF. 619 o Use the and "literal" usages for free-form text defined 620 by [RFC5234]. 621 o Fixed various typos. 622 o Put the rule to convert and to a TURN 623 transport in a separate paragraph. 624 o Modified the SRV usage to be in line with RFC 2782. 625 o Clarified that the NAPTR protocol ranking must be used before the 626 application ranking. 627 o Added an example. 628 o Added release notes. 630 A.9. Design Notes 632 o A "turns:" URI can only use the TURN TLS transport but a "turn:" 633 URI can use either a TURN UDP, TCP or TLS transport. This is 634 because the reason for TLS is not security, but be able to 635 traverse even a NAT that can decode Xored IP addresses, and 636 "upgrading" from TCP to TLS is harmless. 637 o The Application Service Tag is "RELAY" so other relaying 638 mechanisms than TURN (e.g., TWIST) can be registered as 639 Application Protocol Tags. 640 o S-NAPTR was preferred to U-NAPTR because there is no use case for 641 U-NAPTR. 642 o is not used in the URIs because it is deprecated. 643 is not used in the URIs because it is not used to guide 644 the resolution mechanism. 645 o As discussed in Dublin, there is no generic parameters in the URI 646 to prevent compatibity issues. 647 o Adding optional capabilities (IPv6 allocation, preserve bit, 648 etc...) in the resolution process was rejected at the Dublin 649 meeting. 651 A.10. Running Code Considerations 653 o Zap (). Eilon Yardeni, 8x8 Inc. 654 Implements version -00 655 o Reference Implementation of TURN URI parser and resolver 656 (). Marc Petit- 657 Huguenin. Implements version -04 659 A.11. TODO List 661 (Empty) 663 Author's Address 665 Marc Petit-Huguenin 666 (Unaffiliated) 668 Email: petithug@acm.org