One document matched: draft-ietf-behave-turn-uri-04.txt
Differences from draft-ietf-behave-turn-uri-03.txt
Network Working Group M. Petit-Huguenin
Internet-Draft (Unaffiliated)
Intended status: Standards Track November 9, 2009
Expires: May 13, 2010
Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers
draft-ietf-behave-turn-uri-04
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 13, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document defines two URI schemes and the resolution mechanism to
generate a list of server transport addresses that can be tried to
create a Traversal Using Relays around NAT (TURN) allocation.
Petit-Huguenin Expires May 13, 2010 [Page 1]
Internet-Draft TURN URIs November 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Syntax of a TURN or TURNS URI . . . . . . . . . . . . . . . . 3
4. Resolution Mechanism . . . . . . . . . . . . . . . . . . . . . 4
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Multiple Protocols . . . . . . . . . . . . . . . . . . . . 7
5.2. Remote Hosting . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7.1. TURN URI Registration . . . . . . . . . . . . . . . . . . 9
7.2. TURNS URI Registration . . . . . . . . . . . . . . . . . . 9
7.3. RELAY Application Service Tag Registration . . . . . . . . 10
7.4. turn.udp Application Protocol Tag Registration . . . . . . 10
7.5. turn.tcp Application Protocol Tag Registration . . . . . . 10
7.6. turn.tls Application Protocol Tag Registration . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 12
A.1. Modifications between ietf-04 and ietf-03 . . . . . . . . 12
A.2. Modifications between ietf-03 and ietf-02 . . . . . . . . 13
A.3. Modifications between ietf-02 and ietf-01 . . . . . . . . 13
A.4. Modifications between ietf-01 and ietf-00 . . . . . . . . 13
A.5. Modifications between petithuguenin-03 and ietf-00 . . . . 13
A.6. Modifications between petithuguenin-03 and
petithuguenin-02 . . . . . . . . . . . . . . . . . . . . . 13
A.7. Modifications between petithuguenin-02 and
petithuguenin-01 . . . . . . . . . . . . . . . . . . . . . 14
A.8. Modifications between petithuguenin-01 and
petithuguenin-00 . . . . . . . . . . . . . . . . . . . . . 14
A.9. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 14
A.10. Running Code Considerations . . . . . . . . . . . . . . . 15
A.11. TODO List . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Petit-Huguenin Expires May 13, 2010 [Page 2]
Internet-Draft TURN URIs November 2009
1. Introduction
The TURN specification [I-D.ietf-behave-turn] defines a process for a
TURN client to find TURN servers by using DNS SRV resource records,
but this process does not let the TURN server administrators
provision the preferred TURN transport protocol between the client
and the server and for the TURN client to discover this preference.
This document defines an S-NAPTR application [RFC3958] for this
purpose. This application defines "RELAY" as an application service
tag and "turn.udp", "turn.tcp", and "turn.tls" as application
protocol tags.
To simplify the provisioning of TURN clients, this document also
defines a TURN and a TURNS URI scheme and a resolution mechanism to
convert these URIs into a list of IP addresses, ports and TURN
transport protocols.
Another usage of the resolution mechanism described in this document
would be Remote Hosting as described in [RFC3958] section 4.4. For
example a VoIP provider who does not want to deploy TURN servers
could use the servers deployed by another company but could still
want to provide configuration parameters to its customers without
explicitly showing this relationship. The mechanism permits one to
implement this indirection, without preventing the company hosting
the TURN servers from managing them as it see fit.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Syntax of a TURN or TURNS URI
A TURN/TURNS URI has the following ABNF syntax [RFC5234]:
turnURI = scheme ":" host [ ":" port ] [ "?transport=" transport ]
scheme = "turn" / "turns"
transport = "udp" / "tcp" / transport-ext
transport-ext = 1*unreserved
<host>, <port> and <unreserved> are specified in [RFC3986].
Note that the usage of components defined in the [RFC3986] as part of
a generic hierarchical URI does not mean that a TURN/TURNS URI is
hierarchical.
Petit-Huguenin Expires May 13, 2010 [Page 3]
Internet-Draft TURN URIs November 2009
4. Resolution Mechanism
The resolution mechanism is used only to create an allocation. All
other transactions use the IP address, transport and port used for a
successful allocation creation.
The resolution algorithm uses <scheme>, <host>, <port> and
<transport> from the TURN URI as input. It also uses as input a list
ordered by preference of TURN transports (UDP, TCP, TLS) supported
that is provided by the application using the TURN client. This list
reflects the capabilities and preferences of the application code as
opposed to the TURN URI that reflects the preferences of the user of
the application. The output of the algorithm is a list of {IP
address, transport, port} tuples that a TURN client can try in order
to create an allocation on a TURN server.
An Allocate error response as specified in section 6.4 of
[I-D.ietf-behave-turn] is processed as a failure as specified by
[RFC3958] section 2.2.4. The resolution stops when a TURN client
gets a successful Allocate response from a TURN server. After an
allocation succeeds or all the allocations fail, the resolution
context MUST be discarded and the resolution algorithm MUST be
restarted from the beginning for any subsequent allocation. Servers
blacklisted as described in section 6.4 of [I-D.ietf-behave-turn]
SHOULD NOT be used for the specified duration even if returned by a
subsequent resolution.
First the resolution algorithm checks that the URI can be resolved
with the list of TURN transports supported by the application:
o If <scheme> is defined as "turn" and <transport> is defined as
"udp" but the list of TURN transports supported by the application
does not contain UDP then the resolution MUST stop with an error.
o If <scheme> is defined as "turn" and <transport> is defined as
"tcp" but the list of TURN transports supported by the application
does not contain TCP then the resolution MUST stop with an error.
o If <scheme> is defined as "turns" and <transport> is defined as
"udp" then the algorithm MUST stop with an error.
o If <scheme> is defined as "turns" and <transport> is defined as
"tcp" but the list of TURN transports supported by the application
does not contain TLS then the resolution MUST stop with an error.
o If <scheme> is defined as "turns" and <transport> is not defined
but the list of TURN transports supported by the application does
not contain TLS then the resolution MUST stop with an error.
o If <transport> is defined but unknown then the resolution MUST
stop with an error.
After verifying the validity of the URI elements, the algorithm
Petit-Huguenin Expires May 13, 2010 [Page 4]
Internet-Draft TURN URIs November 2009
filters the list of TURN transports supported by the application by
removing the UDP and TCP TURN transport if the <scheme> is defined as
"turns". If the list of TURN transports is empty after this
filtering, the resolution MUST stop with an error.
After filtering the list of TURN transports supported by the
application, the algorithm applies the steps described below. Note
that in some steps, <scheme> and <transport> have to be converted to
a TURN transport. If <scheme> is defined as "turn" and <transport>
is defined as "udp" then the TURN UDP transport is used. If <scheme>
is defined as "turn" and <transport> is defined as "tcp" then the
TURN TCP transport is used. If <scheme> is defined as "turns" and
<transport> is defined as "tcp" then the TURN TLS transport is used.
This is summarized in Table 1.
+----------+-------------+----------------+
| <scheme> | <transport> | TURN Transport |
+----------+-------------+----------------+
| "turn" | "udp" | UDP |
| "turn" | "tcp" | TCP |
| "turns" | "tcp" | TLS |
+----------+-------------+----------------+
Table 1
1. If <host> is an IP address, then it indicates the specific IP
address to be used. If <port> is not defined, the default port
declared in [I-D.ietf-behave-turn] for the SRV service name
defined in <scheme> is used. If <transport> is defined then
<scheme> and <transport> are converted to a TURN transport as
specified in Table 1. If <transport> is not defined, the
filtered TURN transports supported by the application are tried
by preference order. If the TURN client cannot contact a TURN
server with this IP address and port on any of the transports
supported by the application then the resolution MUST stop with
an error.
2. If <host> is a domain name and <port> is defined, then <host> is
resolved to a list of IP addresses via DNS A and AAAA queries.
If <transport> is defined, then <scheme> and <transport> are
converted to a TURN transport as specified in Table 1. If
<transport> is not defined, the filtered TURN transports
supported by the application are tried in preference order. The
TURN client can choose the order to contact the resolved IP
addresses in any implementation-specific way. If the TURN client
cannot contact a TURN server with this port, the transport or
list of transports, and the resolved IP addresses, then the
resolution MUST stop with an error.
Petit-Huguenin Expires May 13, 2010 [Page 5]
Internet-Draft TURN URIs November 2009
3. If <host> is a domain name and <port> is not defined but
<transport> is defined, then the SRV algorithm defined in
[RFC2782] is used to generate a list of IP address and port
tuples. <host> is used as Name, <scheme> as Service and
<transport> as Protocol in the SRV algorithm. <scheme> and
<transport> are converted to a TURN transport as specified in
Table 1 and this transport is used with each tuple for contacting
the TURN server. The SRV algorithm recommends doing an A query
if the SRV query returns an error or no SRV RR; in this case the
default port declared in [I-D.ietf-behave-turn] for the SRV
service name defined in <scheme> MUST be used for contacting the
TURN server. Also in this case, this specification modifies the
SRV algorithm by recommending an A and AAAA query. If the TURN
client cannot contact a TURN server at any of the IP address and
port tuples returned by the SRV algorithm with the transport
converted from the <scheme> and <transport> then the resolution
MUST stop with an error.
4. If <host> is a domain name and <port> and <transport> are not
defined, then <host> is converted to an ordered list of IP
address, port and transport tuples via the S-NAPTR algorithm
defined in [RFC3958] by using <host> as the initial target domain
name and "RELAY" as the Application Service Tag. The filtered
list of TURN transports supported by the application are
converted in Application Protocol Tags by using "turn.udp" if the
TURN transport is UDP, "turn.tcp" if the TURN transport is TCP
and "turn.tls" if the TURN transport is TLS. The order to try
the Application Protocol Tags is provided by the ranking of the
first set of NAPTR records. If multiple Application Protocol
Tags have the same ranking, the preferred order set by the
application is used. If the first NAPTR query fails, the
processing continues in step 5. If the TURN client cannot
contact a TURN server with any of the IP address, port and
transport tuples returned by the S-NAPTR algorithm then the
resolution MUST stop with an error.
5. If the first NAPTR query in the previous step does not return any
result then the SRV algorithm defined in [RFC2782] is used to
generate a list of IP address and port tuples. The SRV algorithm
is applied by using each transport in the filtered list of TURN
transports supported by the application for the Protocol, <host>
for the Name and <scheme> for the Service. The same transport
that was used to generate a list of tuples is used with each of
this tuples for contacting the TURN server. The SRV algorithm
recommends doing an A query if the SRV query returns an error or
no SRV RR; in this case the default port declared in
[I-D.ietf-behave-turn] for the SRV service name defined in
<scheme> MUST be used for contacting the TURN server. Also in
Petit-Huguenin Expires May 13, 2010 [Page 6]
Internet-Draft TURN URIs November 2009
this case, this specification modifies the SRV algorithm by
recommending an A and AAAA query. If the TURN client cannot
contact a TURN server at any of the IP address and port tuples
returned by the SRV algorithm with the transports from the
filtered list then the resolution MUST stop with an error.
5. Examples
5.1. Multiple Protocols
With the DNS RRs in Figure 1 and an ordered TURN transport list of
{TLS, TCP, UDP}, the resolution algorithm will convert the "turn:
example.net" URI to the list of IP addresses, port and protocol
tuples in Table 2.
example.net.
IN NAPTR 100 10 "" RELAY:turn.udp "" datagram.example.net.
IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net.
datagram.example.net.
IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net.
stream.example.net.
IN NAPTR 100 10 S RELAY:turn.tcp "" _turn._tcp.example.net.
IN NAPTR 200 10 A RELAY:turn.tls "" a.example.net.
_turn._udp.example.net.
IN SRV 0 0 3478 a.example.net.
_turn._tcp.example.net.
IN SRV 0 0 5000 a.example.net.
a.example.net.
IN A 192.0.2.1
Figure 1
+-------+----------+------------+------+
| Order | Protocol | IP address | Port |
+-------+----------+------------+------+
| 1 | UDP | 192.0.2.1 | 3478 |
| 2 | TLS | 192.0.2.1 | 5349 |
| 3 | TCP | 192.0.2.1 | 5000 |
+-------+----------+------------+------+
Table 2
Petit-Huguenin Expires May 13, 2010 [Page 7]
Internet-Draft TURN URIs November 2009
5.2. Remote Hosting
In the example in Figure 2, a VoIP provider (example.com) is using
the TURN servers managed by the administrators of the example.net
domain (defined in Figure 1). The resolution algorithm using the
ordered TURN transport list of {TLS, TCP, UDP} would convert the
"turn:example.com" URI to the list of IP addresses, port and protocol
tuples in Table 2.
example.com.
IN NAPTR 100 10 "" "RELAY:turn.udp:turn.tcp:turn.tls" "" example.net.
Figure 2
6. Security Considerations
Security considerations for TURN are discussed in
[I-D.ietf-behave-turn].
The Application Service Tag and Application Protocol Tags defined in
this document do not introduce any specific security issues beyond
the security considerations discussed in [RFC3958]. [RFC3958]
requests that an S-NAPTR application defines some form of end-to-end
authentication to ensure that the correct destination has been
reached. This is achieved for "turn" and "turns" URIs by the Long-
Term Credential Mechanism defined in [RFC5389], which is mandatory
for TURN [I-D.ietf-behave-turn]. Additionally for a "turns" URI, the
usage of TLS has the capability to address the requirement. In this
case the client MUST verify the identity of the server by following
the identification procedure in section 7.2.2 of [RFC5389].
The "turn" and "turns" URI schemes do not introduce any specific
security issues beyond the security considerations discussed in
[RFC3986].
7. IANA Considerations
This section contains the registration information for the "turn" and
"turns" URI Schemes (in accordance with [RFC4395]), one S-NAPTR
Application Service Tag, and three S-NAPTR Application Protocol Tags
(in accordance with [RFC3958]).
Petit-Huguenin Expires May 13, 2010 [Page 8]
Internet-Draft TURN URIs November 2009
7.1. TURN URI Registration
URI scheme name: turn
Status: permanent
URI scheme syntax: See Section 3.
URI scheme semantics: See Section 4.
Encoding considerations: There are no encoding considerations beyond
those in [RFC3986].
Applications/protocols that use this URI scheme name:
The "turn" URI scheme is intended to be used by applications that
might need access to a TURN server.
Interoperability considerations: N/A
Security considerations: See Section 6.
Contact: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
References: This document.
7.2. TURNS URI Registration
URI scheme name: turns
Status: permanent
URI scheme syntax: See Section 3.
URI scheme semantics: See Section 4.
Encoding considerations: There are no encoding considerations beyond
those in [RFC3986].
Applications/protocols that use this URI scheme name:
The "turns" URI scheme is intended to be used by applications that
might need access to a TURN server.
Interoperability considerations: N/A
Petit-Huguenin Expires May 13, 2010 [Page 9]
Internet-Draft TURN URIs November 2009
Security considerations: See Section 6.
Contact: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
References: This document.
7.3. RELAY Application Service Tag Registration
Application Protocol Tag: RELAY
Intended usage: See Section 4.
Interoperability considerations: N/A
Security considerations: See Section 6.
Relevant publications: This document.
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
7.4. turn.udp Application Protocol Tag Registration
Application Protocol Tag: turn.udp
Intended usage: See Section 4.
Interoperability considerations: N/A
Security considerations: See Section 6.
Relevant publications: This document.
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
7.5. turn.tcp Application Protocol Tag Registration
Application Protocol Tag: turn.tcp
Intended usage: See Section 4.
Interoperability considerations:
Petit-Huguenin Expires May 13, 2010 [Page 10]
Internet-Draft TURN URIs November 2009
Security considerations: See Section 6.
Relevant publications: This document.
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
7.6. turn.tls Application Protocol Tag Registration
Application Protocol Tag: turn.tls
Intended usage: See Section 4.
Interoperability considerations: N/A
Security considerations: See Section 6.
Relevant publications: This document.
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
8. Acknowledgements
Thanks to Pasi Eronen, Margaret Wasserman, Magnus Westerlund, Juergen
Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E.
Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes and Jim Kleck for
their comments, suggestions and questions that helped to improve this
document.
This document was written with the xml2rfc tool described in
[RFC2629].
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
Petit-Huguenin Expires May 13, 2010 [Page 11]
Internet-Draft TURN URIs November 2009
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-16 (work in progress), July 2009.
9.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006.
Appendix A. Release notes
This section must be removed before publication as an RFC.
A.1. Modifications between ietf-04 and ietf-03
o Improved the algorithm steps.
o It is possible to use a TLS transport event if the scheme is
turn:.
o Clarified when to stop the resolution with an error in step 2.
o Added transport list filtering process.
o Improved security section following sec-dir review.
o Fixed nits reported by gen-art review.
o Added example for remote hosting.
o Removed URIs section.
Petit-Huguenin Expires May 13, 2010 [Page 12]
Internet-Draft TURN URIs November 2009
o Editorial modification.
A.2. Modifications between ietf-03 and ietf-02
o A turn:<host>?transport=TCP URI fails if the list of supported
transports contains only TLS. Using a TLS transport in this case
was underspecified.
o Reordered paragraphes in section 4.
o Added table for conversion of <scheme> and <transport> to TURN
transport.
o Various editorial modifications.
o SRV algorithm changed to "...recommending an A and AAAA query."
o Put back the changelog for the versions before been accepted as WG
item.
A.3. Modifications between ietf-02 and ietf-01
o Shorten the abstract so it does not overflow on the second page.
o Added text to explicitly say that the resolution is only to create
an allocation.
o Added text about failures.
o Fixed the default port for TLS in the example.
o Changed some priority in the example for RFC3958 section 2.2.5.
o Fixed the service/protocol order for the SRV RR in the example.
o Removed reference to draft-wood-tae-specifying-uri-transports as
it has an experimental status.
A.4. Modifications between ietf-01 and ietf-00
o Fixed the contact email.
o Changed the IPR to trust200902.
o Added case for transport defined but unknown.
o Moved RFC 3958 to Normative References.
o Added study of draft-wood-tae-specifying-uri-transports in TODO
list.
A.5. Modifications between petithuguenin-03 and ietf-00
o Renamed the document to "draft-ietf-behave-turn-uri".
o Changed author affiliation.
o Fixed the text in the IANA considerations.
A.6. Modifications between petithuguenin-03 and petithuguenin-02
o Added Running Code Consideration section.
o Added Remote Hosting example in introduction.
Petit-Huguenin Expires May 13, 2010 [Page 13]
Internet-Draft TURN URIs November 2009
o Changed back to opaque URIs because of [RFC4395] Section 2.2. Now
use "?" as separator.
o Added IANA considerations section.
o Added security considerations section.
A.7. Modifications between petithuguenin-02 and petithuguenin-01
o Receiving a successful Allocate response stops the resolution
mechanism and the resolution context must be discarded after this.
o Changed from opaque to hierarchical URIs because the ";" character
is used in <reg-name>.
o Various nits.
A.8. Modifications between petithuguenin-01 and petithuguenin-00
o Added <transport-ext> in the ABNF.
o Use the <rulename> and "literal" usages for free-form text defined
by [RFC5234].
o Fixed various typos.
o Put the rule to convert <scheme> and <transport> to a TURN
transport in a separate paragraph.
o Modified the SRV usage to be in line with RFC 2782.
o Clarified that the NAPTR protocol ranking must be used before the
application ranking.
o Added an example.
o Added release notes.
A.9. Design Notes
o A "turns:" URI can only use the TURN TLS transport but a "turn:"
URI can use either a TURN UDP, TCP or TLS transport. This is
because the reason for TLS is not security, but be able to
traverse even a NAT that can decode Xored IP addresses, and
"upgrading" from TCP to TLS is harmless.
o The Application Service Tag is "RELAY" so other relaying
mechanisms than TURN (e.g., TWIST) can be registered as
Application Protocol Tags.
o S-NAPTR was preferred to U-NAPTR because there is no use case for
U-NAPTR.
o <password> is not used in the URIs because it is deprecated.
<username> is not used in the URIs because it is not used to guide
the resolution mechanism.
o As discussed in Dublin, there is no generic parameters in the URI
to prevent compatibity issues.
o Adding optional capabilities (IPv6 allocation, preserve bit,
etc...) in the resolution process was rejected at the Dublin
meeting.
Petit-Huguenin Expires May 13, 2010 [Page 14]
Internet-Draft TURN URIs November 2009
A.10. Running Code Considerations
o Zap (<http://www.croczilla.com/zap>). Eilon Yardeni, 8x8 Inc.
Implements version -00
o Reference Implementation of TURN URI parser and resolver
(<http://ietf.implementers.org/turn-uri-0.2.zip>). Marc Petit-
Huguenin. Implements version -04
A.11. TODO List
(Empty)
Author's Address
Marc Petit-Huguenin
(Unaffiliated)
Email: petithug@acm.org
Petit-Huguenin Expires May 13, 2010 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-24 04:19:04 |