idnits 2.17.1 draft-ietf-behave-turn-uri-08.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 16, 2010) is 5207 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 16, 2010 5 Expires: July 20, 2010 7 Traversal Using Relays around NAT (TURN) Resolution Mechanism 8 draft-ietf-behave-turn-uri-08 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 July 20, 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 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. RELAY Application Service Tag Registration . . . . . . . . 8 65 6.2. turn.udp Application Protocol Tag Registration . . . . . . 9 66 6.3. turn.tcp Application Protocol Tag Registration . . . . . . 9 67 6.4. turn.tls Application Protocol Tag Registration . . . . . . 10 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 72 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 11 73 A.1. Modifications between ietf-08 and ietf-07 . . . . . . . . 11 74 A.2. Modifications between ietf-07 and ietf-06 . . . . . . . . 11 75 A.3. Modifications between ietf-06 and ietf-05 . . . . . . . . 11 76 A.4. Modifications between ietf-05 and ietf-04 . . . . . . . . 12 77 A.5. Modifications between ietf-04 and ietf-03 . . . . . . . . 12 78 A.6. Modifications between ietf-03 and ietf-02 . . . . . . . . 12 79 A.7. Modifications between ietf-02 and ietf-01 . . . . . . . . 12 80 A.8. Modifications between ietf-01 and ietf-00 . . . . . . . . 12 81 A.9. Modifications between ietf-00 and petithuguenin-03 . . . . 13 82 A.10. Modifications between petithuguenin-03 and 83 petithuguenin-02 . . . . . . . . . . . . . . . . . . . . . 13 84 A.11. Modifications between petithuguenin-02 and 85 petithuguenin-01 . . . . . . . . . . . . . . . . . . . . . 13 86 A.12. Modifications between petithuguenin-01 and 87 petithuguenin-00 . . . . . . . . . . . . . . . . . . . . . 13 88 A.13. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 13 89 A.14. Running Code Considerations . . . . . . . . . . . . . . . 14 90 A.15. TODO List . . . . . . . . . . . . . . . . . . . . . . . . 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. 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 5. Security Considerations 341 Security considerations for TURN are discussed in [TURN]. 343 The Application Service Tag and Application Protocol Tags defined in 344 this document do not introduce any specific security issues beyond 345 the security considerations discussed in [RFC3958]. [RFC3958] 346 requests that an S-NAPTR application defines some form of end-to-end 347 authentication to ensure that the correct destination has been 348 reached. This is achieved by the Long-Term Credential Mechanism 349 defined in [RFC5389], which is mandatory for [TURN]. Additionally 350 the usage of TLS [RFC5246] has the capability to address the 351 requirement. In this case the client MUST verify the identity of the 352 server by following the identification procedure in section 7.2.2 of 353 [RFC5389]. 355 6. IANA Considerations 357 This section contains the registration information for one S-NAPTR 358 Application Service Tag and three S-NAPTR Application Protocol Tags 359 (in accordance with [RFC3958]). 361 6.1. RELAY Application Service Tag Registration 363 Application Protocol Tag: RELAY 365 Intended usage: See Section 3. 367 Interoperability considerations: N/A 369 Security considerations: See Section 5. 371 Relevant publications: This document. 373 [Note to RFC Editor: Replace "This document" with reference to this 374 document] 376 Contact information: Marc Petit-Huguenin 378 Author/Change controller: The IESG 380 6.2. turn.udp Application Protocol Tag Registration 382 Application Protocol Tag: turn.udp 384 Intended usage: See Section 3. 386 Interoperability considerations: N/A 388 Security considerations: See Section 5. 390 Relevant publications: This document. 392 [Note to RFC Editor: Replace "This document" with reference to this 393 document] 395 Contact information: Marc Petit-Huguenin 397 Author/Change controller: The IESG 399 6.3. turn.tcp Application Protocol Tag Registration 401 Application Protocol Tag: turn.tcp 403 Intended usage: See Section 3. 405 Interoperability considerations: 407 Security considerations: See Section 5. 409 Relevant publications: This document. 411 [Note to RFC Editor: Replace "This document" with reference to this 412 document] 414 Contact information: Marc Petit-Huguenin 416 Author/Change controller: The IESG 418 6.4. turn.tls Application Protocol Tag Registration 420 Application Protocol Tag: turn.tls 422 Intended usage: See Section 3. 424 Interoperability considerations: N/A 426 Security considerations: See Section 5. 428 Relevant publications: This document. 430 [Note to RFC Editor: Replace "This document" with reference to this 431 document] 433 Contact information: Marc Petit-Huguenin 435 Author/Change controller: The IESG 437 7. Acknowledgements 439 Thanks to Alexey Melnikov, Scott Bradner, Spencer Dawkins, Pasi 440 Eronen, Margaret Wasserman, Magnus Westerlund, Juergen Schoenwaelder, 441 Sean Turner, Ted Hardie, Dave Thaler, Alfred E. Heggestad, Eilon 442 Yardeni, Dan Wing, Alfred Hoenes and Jim Kleck for their comments, 443 suggestions and questions that helped to improve this document. 445 This document was written with the xml2rfc tool described in 446 [RFC2629]. 448 8. References 450 8.1. Normative References 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 456 specifying the location of services (DNS SRV)", RFC 2782, 457 February 2000. 459 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 460 Service Location Using SRV RRs and the Dynamic Delegation 461 Discovery Service (DDDS)", RFC 3958, January 2005. 463 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 464 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 466 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 467 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 468 October 2008. 470 [TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 471 Relays around NAT (TURN): Relay Extensions to Session 472 Traversal Utilities for NAT (STUN)", 473 draft-ietf-behave-turn-16 (work in progress), July 2009. 475 8.2. Informative References 477 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 478 June 1999. 480 [TURN-URI] 481 Petit-Huguenin, M., "Traversal Using Relays around NAT 482 (TURN) Uniform Resource Identifiers", 483 draft-petithuguenin-behave-turn-uri-bis-01 (work in 484 progress), January 2010. 486 Appendix A. Release notes 488 This section must be removed before publication as an RFC. 490 A.1. Modifications between ietf-08 and ietf-07 492 o Added reference to TLS RFC. 493 o Removed usused references. 494 o Fixed reference to URI. 496 A.2. Modifications between ietf-07 and ietf-06 498 o Clarified "application code" meaning. 500 A.3. Modifications between ietf-06 and ietf-05 502 o Updated the short title to "TURN Resolution". 503 o Shorten I-D references. 504 o Nits 505 o Changed SHOULD NOT to MUST NOT for blacklist rule. 506 o Added notes to RFC editor. 508 A.4. Modifications between ietf-05 and ietf-04 510 o Moved the URI stuff to [TURN-URI]. 512 A.5. Modifications between ietf-04 and ietf-03 514 o Improved the algorithm steps. 515 o It is possible to use a TLS transport event if the scheme is 516 turn:. 517 o Clarified when to stop the resolution with an error in step 2. 518 o Added transport list filtering process. 519 o Improved security section following sec-dir review. 520 o Fixed nits reported by gen-art review. 521 o Added example for remote hosting. 522 o Removed URIs section. 523 o Editorial modification. 525 A.6. Modifications between ietf-03 and ietf-02 527 o A turn:?transport=TCP URI fails if the list of supported 528 transports contains only TLS. Using a TLS transport in this case 529 was underspecified. 530 o Reordered paragraphes in section 4. 531 o Added table for conversion of and to TURN 532 transport. 533 o Various editorial modifications. 534 o SRV algorithm changed to "...recommending an A and AAAA query." 535 o Put back the changelog for the versions before been accepted as WG 536 item. 538 A.7. Modifications between ietf-02 and ietf-01 540 o Shorten the abstract so it does not overflow on the second page. 541 o Added text to explicitly say that the resolution is only to create 542 an allocation. 543 o Added text about failures. 544 o Fixed the default port for TLS in the example. 545 o Changed some priority in the example for RFC3958 section 2.2.5. 546 o Fixed the service/protocol order for the SRV RR in the example. 547 o Removed reference to draft-wood-tae-specifying-uri-transports as 548 it has an experimental status. 550 A.8. Modifications between ietf-01 and ietf-00 552 o Fixed the contact email. 553 o Changed the IPR to trust200902. 555 o Added case for transport defined but unknown. 556 o Moved RFC 3958 to Normative References. 557 o Added study of draft-wood-tae-specifying-uri-transports in TODO 558 list. 560 A.9. Modifications between ietf-00 and petithuguenin-03 562 o Renamed the document to "draft-ietf-behave-turn-uri". 563 o Changed author affiliation. 564 o Fixed the text in the IANA considerations. 566 A.10. Modifications between petithuguenin-03 and petithuguenin-02 568 o Added Running Code Consideration section. 569 o Added Remote Hosting example in introduction. 570 o Changed back to opaque URIs because of RFC4395 Section 2.2. Now 571 use "?" as separator. 572 o Added IANA considerations section. 573 o Added security considerations section. 575 A.11. Modifications between petithuguenin-02 and petithuguenin-01 577 o Receiving a successful Allocate response stops the resolution 578 mechanism and the resolution context must be discarded after this. 579 o Changed from opaque to hierarchical URIs because the ";" character 580 is used in . 581 o Various nits. 583 A.12. Modifications between petithuguenin-01 and petithuguenin-00 585 o Added in the ABNF. 586 o Use the and "literal" usages for free-form text defined 587 by RFC5234. 588 o Fixed various typos. 589 o Put the rule to convert and to a TURN 590 transport in a separate paragraph. 591 o Modified the SRV usage to be in line with RFC 2782. 592 o Clarified that the NAPTR protocol ranking must be used before the 593 application ranking. 594 o Added an example. 595 o Added release notes. 597 A.13. Design Notes 599 o The Application Service Tag is "RELAY" so other relaying 600 mechanisms than TURN (e.g., TWIST) can be registered as 601 Application Protocol Tags. 603 o S-NAPTR was preferred to U-NAPTR because there is no use case for 604 U-NAPTR. 605 o Adding optional capabilities (IPv6 allocation, preserve bit, 606 etc...) in the resolution process was rejected at the Dublin 607 meeting. 609 A.14. Running Code Considerations 611 o Zap (). Eilon Yardeni, 8x8 Inc. 612 Implements version -00. 613 o Reference Implementation of TURN URI parser and resolver 614 (). Marc Petit- 615 Huguenin. Implements version -07. 617 A.15. TODO List 619 (Empty) 621 Author's Address 623 Marc Petit-Huguenin 624 (Unaffiliated) 626 Email: petithug@acm.org