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