idnits 2.17.1 draft-ietf-behave-turn-uri-07.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 14, 2010) is 5209 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) == Outdated reference: A later version (-05) exists of draft-petithuguenin-behave-turn-uri-bis-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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 January 14, 2010 5 Expires: July 18, 2010 7 Traversal Using Relays around NAT (TURN) Resolution Mechanism 8 draft-ietf-behave-turn-uri-07 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 18, 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 . . . . . . 9 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-07 and ietf-06 . . . . . . . . 11 74 A.2. Modifications between ietf-06 and ietf-05 . . . . . . . . 11 75 A.3. Modifications between ietf-05 and ietf-04 . . . . . . . . 11 76 A.4. Modifications between ietf-04 and ietf-03 . . . . . . . . 11 77 A.5. Modifications between ietf-03 and ietf-02 . . . . . . . . 12 78 A.6. Modifications between ietf-02 and ietf-01 . . . . . . . . 12 79 A.7. Modifications between ietf-01 and ietf-00 . . . . . . . . 12 80 A.8. Modifications between petithuguenin-03 and ietf-00 . . . . 12 81 A.9. Modifications between petithuguenin-03 and 82 petithuguenin-02 . . . . . . . . . . . . . . . . . . . . . 13 83 A.10. Modifications between petithuguenin-02 and 84 petithuguenin-01 . . . . . . . . . . . . . . . . . . . . . 13 85 A.11. Modifications between petithuguenin-01 and 86 petithuguenin-00 . . . . . . . . . . . . . . . . . . . . . 13 87 A.12. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 13 88 A.13. Running Code Considerations . . . . . . . . . . . . . . . 14 89 A.14. TODO List . . . . . . . . . . . . . . . . . . . . . . . . 14 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 The TURN specification [TURN] defines a process for a TURN client to 95 find TURN servers by using DNS SRV resource records, but this process 96 does not let the TURN server administrators provision the preferred 97 TURN transport protocol between the client and the server and does 98 not allow the TURN client to discover this preference. This document 99 defines an S-NAPTR application [RFC3958] for this purpose. This 100 application defines "RELAY" as an application service tag and 101 "turn.udp", "turn.tcp", and "turn.tls" as application protocol tags. 103 Another usage of the resolution mechanism described in this document 104 would be Remote Hosting as described in [RFC3958] section 4.4. For 105 example a VoIP provider who does not want to deploy TURN servers 106 could use the servers deployed by another company but could still 107 want to provide configuration parameters to its customers without 108 explicitly showing this relationship. The mechanism permits one to 109 implement this indirection, without preventing the company hosting 110 the TURN servers from managing them as it sees fit. 112 [TURN-URI] can be used as a convenient way of carrying the four 113 components needed by the resolution mechanism described in this 114 document. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 3. Resolution Mechanism 124 The resolution mechanism is used only to create an allocation. All 125 other transactions use the IP address, transport and port used for a 126 successful allocation creation. 128 The resolution algorithm uses a boolean flag, ; an IP address 129 or domain name, ; a port number that can be empty, ; and 130 a transport name that can be "udp", "tcp" or empty, as 131 input. This four parameters are part of the user configuration of 132 the TURN client. The resolution mechanism also uses as input a list 133 ordered by preference of TURN transports (UDP, TCP, TLS) supported 134 that is provided by the application using the TURN client. This list 135 reflects the capabilities and preferences of the application code 136 that is using the S-NAPTR resolver and TURN client, as opposed to the 137 configuration parameters that reflect the preferences of the user of 138 the application. The output of the algorithm is a list of {IP 139 address, transport, port} tuples that a TURN client can try in order 140 to create an allocation on a TURN server. 142 An Allocate error response as specified in section 6.4 of [TURN] is 143 processed as a failure as specified by [RFC3958] section 2.2.4. The 144 resolution stops when a TURN client gets a successful Allocate 145 response from a TURN server. After an allocation succeeds or all the 146 allocations fail, the resolution context MUST be discarded and the 147 resolution algorithm MUST be restarted from the beginning for any 148 subsequent allocation. Servers blacklisted as described in section 149 6.4 of [TURN] MUST NOT be used for the specified duration even if 150 returned by a subsequent resolution. 152 First the resolution algorithm checks that the parameters can be 153 resolved with the list of TURN transports supported by the 154 application: 156 o If is false and is defined as "udp" but the 157 list of TURN transports supported by the application does not 158 contain UDP then the resolution MUST stop with an error. 159 o If is false and is defined as "tcp" but the 160 list of TURN transports supported by the application does not 161 contain TCP then the resolution MUST stop with an error. 162 o If is true and is defined as "udp" then the 163 algorithm MUST stop with an error. 164 o If is true and is defined as "tcp" but the 165 list of TURN transports supported by the application does not 166 contain TLS then the resolution MUST stop with an error. 167 o If is true and is not defined but the list of 168 TURN transports supported by the application does not contain TLS 169 then the resolution MUST stop with an error. 170 o If is defined but unknown then the resolution MUST 171 stop with an error. 173 After verifying the validity of the URI elements, the algorithm 174 filters the list of TURN transports supported by the application by 175 removing the UDP and TCP TURN transport if is true. If the 176 list of TURN transports is empty after this filtering, the resolution 177 MUST stop with an error. 179 After filtering the list of TURN transports supported by the 180 application, the algorithm applies the steps described below. Note 181 that in some steps, and have to be converted to 182 a TURN transport. If is false and is defined as 183 "udp" then the TURN UDP transport is used. If is false and 184 is defined as "tcp" then the TURN TCP transport is used. 185 If is true and is defined as "tcp" then the TURN 186 TLS transport is used. This is summarized in Table 1. 188 +----------+-------------+----------------+ 189 | | | TURN Transport | 190 +----------+-------------+----------------+ 191 | false | "udp" | UDP | 192 | false | "tcp" | TCP | 193 | true | "tcp" | TLS | 194 +----------+-------------+----------------+ 196 Table 1 198 1. If is an IP address, then it indicates the specific IP 199 address to be used. If is not defined, the default port 200 declared in [TURN] for the "turn" SRV service name if is 201 false, or the "turns" SRV service name if is true MUST 202 be used for contacting the TURN server. If is 203 defined then and are converted to a TURN 204 transport as specified in Table 1. If is not 205 defined, the filtered TURN transports supported by the 206 application are tried by preference order. If the TURN client 207 cannot contact a TURN server with this IP address and port on any 208 of the transports supported by the application then the 209 resolution MUST stop with an error. 211 2. If is a domain name and is defined, then is 212 resolved to a list of IP addresses via DNS A and AAAA queries. 213 If is defined, then and are 214 converted to a TURN transport as specified in Table 1. If 215 is not defined, the filtered TURN transports 216 supported by the application are tried in preference order. The 217 TURN client can choose the order to contact the resolved IP 218 addresses in any implementation-specific way. If the TURN client 219 cannot contact a TURN server with this port, the transport or 220 list of transports, and the resolved IP addresses, then the 221 resolution MUST stop with an error. 223 3. If is a domain name and is not defined but 224 is defined, then the SRV algorithm defined in 225 [RFC2782] is used to generate a list of IP address and port 226 tuples. is used as Name, a value of false for as 227 "turn" for Service, a value of true for as "turns" for 228 Service and as Protocol in the SRV algorithm. 229 and are converted to a TURN transport as 230 specified in Table 1 and this transport is used with each tuple 231 for contacting the TURN server. The SRV algorithm recommends 232 doing an A query if the SRV query returns an error or no SRV RR; 233 in this case the default port declared in [TURN] for the "turn" 234 SRV service name if is false, or the "turns" SRV service 235 name if is true MUST be used for contacting the TURN 236 server. Also in this case, this specification modifies the SRV 237 algorithm by recommending an A and AAAA query. If the TURN 238 client cannot contact a TURN server at any of the IP address and 239 port tuples returned by the SRV algorithm with the transport 240 converted from and then the resolution MUST 241 stop with an error. 243 4. If is a domain name and and are not 244 defined, then is converted to an ordered list of IP 245 address, port and transport tuples via the S-NAPTR algorithm 246 defined in [RFC3958] by using as the initial target domain 247 name and "RELAY" as the Application Service Tag. The filtered 248 list of TURN transports supported by the application are 249 converted in Application Protocol Tags by using "turn.udp" if the 250 TURN transport is UDP, "turn.tcp" if the TURN transport is TCP 251 and "turn.tls" if the TURN transport is TLS. The order to try 252 the Application Protocol Tags is provided by the ranking of the 253 first set of NAPTR records. If multiple Application Protocol 254 Tags have the same ranking, the preferred order set by the 255 application is used. If the first NAPTR query fails, the 256 processing continues in step 5. If the TURN client cannot 257 contact a TURN server with any of the IP address, port and 258 transport tuples returned by the S-NAPTR algorithm then the 259 resolution MUST stop with an error. 261 5. If the first NAPTR query in the previous step does not return any 262 result then the SRV algorithm defined in [RFC2782] is used to 263 generate a list of IP address and port tuples. The SRV algorithm 264 is applied by using each transport in the filtered list of TURN 265 transports supported by the application for the Protocol, 266 for the Name, "turn" for the Service if is false or 267 "turns" for the Service if is true. The same transport 268 that was used to generate a list of tuples is used with each of 269 these tuples for contacting the TURN server. The SRV algorithm 270 recommends doing an A query if the SRV query returns an error or 271 no SRV RR; in this case the default port declared in [TURN] for 272 the "turn" SRV service name if is false, or the "turns" 273 SRV service name if is true MUST be used for contacting 274 the TURN server. Also in this case, this specification modifies 275 the SRV algorithm by recommending an A and AAAA query. If the 276 TURN client cannot contact a TURN server at any of the IP address 277 and port tuples returned by the SRV algorithm with the transports 278 from the filtered list then the resolution MUST stop with an 279 error. 281 4. Examples 283 4.1. Multiple Protocols 285 With the DNS RRs in Figure 1 and an ordered TURN transport list of 286 {TLS, TCP, UDP}, the resolution algorithm will convert the parameters 287 with a value of false, with a value of "example.net" 288 and and been empty to the list of IP addresses, 289 port and protocol tuples in Table 2. 291 example.net. 292 IN NAPTR 100 10 "" RELAY:turn.udp "" datagram.example.net. 293 IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net. 295 datagram.example.net. 296 IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net. 298 stream.example.net. 299 IN NAPTR 100 10 S RELAY:turn.tcp "" _turn._tcp.example.net. 300 IN NAPTR 200 10 A RELAY:turn.tls "" a.example.net. 302 _turn._udp.example.net. 303 IN SRV 0 0 3478 a.example.net. 305 _turn._tcp.example.net. 306 IN SRV 0 0 5000 a.example.net. 308 a.example.net. 309 IN A 192.0.2.1 311 Figure 1 313 +-------+----------+------------+------+ 314 | Order | Protocol | IP address | Port | 315 +-------+----------+------------+------+ 316 | 1 | UDP | 192.0.2.1 | 3478 | 317 | 2 | TLS | 192.0.2.1 | 5349 | 318 | 3 | TCP | 192.0.2.1 | 5000 | 319 +-------+----------+------------+------+ 321 Table 2 323 4.2. Remote Hosting 325 In the example in Figure 2, a VoIP provider (example.com) is using 326 the TURN servers managed by the administrators of the example.net 327 domain (defined in Figure 1). The resolution algorithm using the 328 ordered TURN transport list of {TLS, TCP, UDP} would convert the same 329 parameters than in the previous example but with the parameter 330 equal to "example.com" to the list of IP addresses, port and protocol 331 tuples in Table 2. 333 example.com. 334 IN NAPTR 100 10 "" "RELAY:turn.udp:turn.tcp:turn.tls" "" example.net. 336 Figure 2 338 5. Security Considerations 340 Security considerations for TURN are discussed in [TURN]. 342 The Application Service Tag and Application Protocol Tags defined in 343 this document do not introduce any specific security issues beyond 344 the security considerations discussed in [RFC3958]. [RFC3958] 345 requests that an S-NAPTR application defines some form of end-to-end 346 authentication to ensure that the correct destination has been 347 reached. This is achieved by the Long-Term Credential Mechanism 348 defined in [RFC5389], which is mandatory for [TURN]. Additionally 349 the usage of TLS has the capability to address the requirement. In 350 this case the client MUST verify the identity of the server by 351 following the identification procedure in section 7.2.2 of [RFC5389]. 353 6. IANA Considerations 355 This section contains the registration information for one S-NAPTR 356 Application Service Tag and three S-NAPTR Application Protocol Tags 357 (in accordance with [RFC3958]). 359 6.1. RELAY Application Service Tag Registration 361 Application Protocol Tag: RELAY 363 Intended usage: See Section 3. 365 Interoperability considerations: N/A 367 Security considerations: See Section 5. 369 Relevant publications: This document. 371 [Note to RFC Editor: Replace "This document" with reference to this 372 document] 374 Contact information: Marc Petit-Huguenin 376 Author/Change controller: The IESG 378 6.2. turn.udp Application Protocol Tag Registration 380 Application Protocol Tag: turn.udp 382 Intended usage: See Section 3. 384 Interoperability considerations: N/A 386 Security considerations: See Section 5. 388 Relevant publications: This document. 390 [Note to RFC Editor: Replace "This document" with reference to this 391 document] 393 Contact information: Marc Petit-Huguenin 395 Author/Change controller: The IESG 397 6.3. turn.tcp Application Protocol Tag Registration 399 Application Protocol Tag: turn.tcp 401 Intended usage: See Section 3. 403 Interoperability considerations: 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.4. turn.tls Application Protocol Tag Registration 418 Application Protocol Tag: turn.tls 419 Intended usage: See Section 3. 421 Interoperability considerations: N/A 423 Security considerations: See Section 5. 425 Relevant publications: This document. 427 [Note to RFC Editor: Replace "This document" with reference to this 428 document] 430 Contact information: Marc Petit-Huguenin 432 Author/Change controller: The IESG 434 7. Acknowledgements 436 Thanks to Scott Bradner, Spencer Dawkins, Pasi Eronen, Margaret 437 Wasserman, Magnus Westerlund, Juergen Schoenwaelder, Sean Turner, Ted 438 Hardie, Dave Thaler, Alfred E. Heggestad, Eilon Yardeni, Dan Wing, 439 Alfred Hoenes and Jim Kleck for their comments, suggestions and 440 questions that helped to improve this document. 442 This document was written with the xml2rfc tool described in 443 [RFC2629]. 445 8. References 447 8.1. Normative References 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, March 1997. 452 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 453 specifying the location of services (DNS SRV)", RFC 2782, 454 February 2000. 456 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 457 Service Location Using SRV RRs and the Dynamic Delegation 458 Discovery Service (DDDS)", RFC 3958, January 2005. 460 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 461 Specifications: ABNF", STD 68, RFC 5234, January 2008. 463 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 464 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 465 October 2008. 467 [TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 468 Relays around NAT (TURN): Relay Extensions to Session 469 Traversal Utilities for NAT (STUN)", 470 draft-ietf-behave-turn-16 (work in progress), July 2009. 472 8.2. Informative References 474 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 475 June 1999. 477 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 478 Registration Procedures for New URI Schemes", BCP 35, 479 RFC 4395, February 2006. 481 [TURN-URI] 482 Petit-Huguenin, M., "Traversal Using Relays around NAT 483 (TURN) Uniform Resource Identifiers", 484 draft-petithuguenin-behave-turn-uri-bis-01 (work in 485 progress), January 2010. 487 Appendix A. Release notes 489 This section must be removed before publication as an RFC. 491 A.1. Modifications between ietf-07 and ietf-06 493 o Clarified "application code" meaning. 495 A.2. Modifications between ietf-06 and ietf-05 497 o Updated the short title to "TURN Resolution". 498 o Shorten I-D references. 499 o Nits 500 o Changed SHOULD NOT to MUST NOT for blacklist rule. 501 o Added notes to RFC editor. 503 A.3. Modifications between ietf-05 and ietf-04 505 o Moved the URI stuff to [TURN-URI]. 507 A.4. Modifications between ietf-04 and ietf-03 509 o Improved the algorithm steps. 511 o It is possible to use a TLS transport event if the scheme is 512 turn:. 513 o Clarified when to stop the resolution with an error in step 2. 514 o Added transport list filtering process. 515 o Improved security section following sec-dir review. 516 o Fixed nits reported by gen-art review. 517 o Added example for remote hosting. 518 o Removed URIs section. 519 o Editorial modification. 521 A.5. Modifications between ietf-03 and ietf-02 523 o A turn:?transport=TCP URI fails if the list of supported 524 transports contains only TLS. Using a TLS transport in this case 525 was underspecified. 526 o Reordered paragraphes in section 4. 527 o Added table for conversion of and to TURN 528 transport. 529 o Various editorial modifications. 530 o SRV algorithm changed to "...recommending an A and AAAA query." 531 o Put back the changelog for the versions before been accepted as WG 532 item. 534 A.6. Modifications between ietf-02 and ietf-01 536 o Shorten the abstract so it does not overflow on the second page. 537 o Added text to explicitly say that the resolution is only to create 538 an allocation. 539 o Added text about failures. 540 o Fixed the default port for TLS in the example. 541 o Changed some priority in the example for RFC3958 section 2.2.5. 542 o Fixed the service/protocol order for the SRV RR in the example. 543 o Removed reference to draft-wood-tae-specifying-uri-transports as 544 it has an experimental status. 546 A.7. Modifications between ietf-01 and ietf-00 548 o Fixed the contact email. 549 o Changed the IPR to trust200902. 550 o Added case for transport defined but unknown. 551 o Moved RFC 3958 to Normative References. 552 o Added study of draft-wood-tae-specifying-uri-transports in TODO 553 list. 555 A.8. Modifications between petithuguenin-03 and ietf-00 556 o Renamed the document to "draft-ietf-behave-turn-uri". 557 o Changed author affiliation. 558 o Fixed the text in the IANA considerations. 560 A.9. Modifications between petithuguenin-03 and petithuguenin-02 562 o Added Running Code Consideration section. 563 o Added Remote Hosting example in introduction. 564 o Changed back to opaque URIs because of [RFC4395] Section 2.2. Now 565 use "?" as separator. 566 o Added IANA considerations section. 567 o Added security considerations section. 569 A.10. Modifications between petithuguenin-02 and petithuguenin-01 571 o Receiving a successful Allocate response stops the resolution 572 mechanism and the resolution context must be discarded after this. 573 o Changed from opaque to hierarchical URIs because the ";" character 574 is used in . 575 o Various nits. 577 A.11. Modifications between petithuguenin-01 and petithuguenin-00 579 o Added in the ABNF. 580 o Use the and "literal" usages for free-form text defined 581 by [RFC5234]. 582 o Fixed various typos. 583 o Put the rule to convert and to a TURN 584 transport in a separate paragraph. 585 o Modified the SRV usage to be in line with RFC 2782. 586 o Clarified that the NAPTR protocol ranking must be used before the 587 application ranking. 588 o Added an example. 589 o Added release notes. 591 A.12. Design Notes 593 o The Application Service Tag is "RELAY" so other relaying 594 mechanisms than TURN (e.g., TWIST) can be registered as 595 Application Protocol Tags. 596 o S-NAPTR was preferred to U-NAPTR because there is no use case for 597 U-NAPTR. 598 o Adding optional capabilities (IPv6 allocation, preserve bit, 599 etc...) in the resolution process was rejected at the Dublin 600 meeting. 602 A.13. Running Code Considerations 604 o Zap (). Eilon Yardeni, 8x8 Inc. 605 Implements version -00. 606 o Reference Implementation of TURN URI parser and resolver 607 (). Marc Petit- 608 Huguenin. Implements version -07. 610 A.14. TODO List 612 (Empty) 614 Author's Address 616 Marc Petit-Huguenin 617 (Unaffiliated) 619 Email: petithug@acm.org