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