One document matched: draft-ietf-behave-turn-uri-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<?rfc compact="yes" ?><?rfc strict="no" ?><?rfc symrefs="yes" ?><?rfc toc="yes" ?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-behave-turn-uri-05" category="std">
<front>
<title abbrev="TURN URIs">Traversal Using Relays around NAT (TURN) Resolution Mechanism</title>
<author initials="M.P.H" surname="Petit-Huguenin" fullname="Marc Petit-Huguenin">
<organization>(Unaffiliated)</organization>
<address>
<email>petithug@acm.org</email>
</address>
</author>
<date day="25" month="November" year="2009"/>
<abstract>
<t>This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The <xref target="I-D.ietf-behave-turn">TURN specification</xref> 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 <xref target="RFC3958">S-NAPTR application</xref> for this purpose.
This application defines "RELAY" as an application service tag and "turn.udp", "turn.tcp", and "turn.tls" as application protocol tags.
</t>
<t>
Another usage of the resolution mechanism described in this document would be Remote Hosting as described in <xref target="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.
</t>
<t><xref target="I-D.petithuguenin-behave-turn-uri-bis"/> can be used as a convenient way of carrying the four components needed by the resolution mechanism described in this document.</t>
</section>
<section title="Terminology">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section anchor="resolution" title="Resolution Mechanism">
<t>
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.
</t>
<t>
The resolution algorithm uses a boolean flag, <secure>; an IP address or domain name, <host>; a port number that can be empty, <port>; and a transport name that can be "udp", "tcp" or empty, <transport> as input.
This four parameters are part of the user configuration of the TURN client.
The resolution mechanism 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 configuration parameters that reflect 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.
</t>
<t>
An Allocate error response as specified in section 6.4 of <xref target="I-D.ietf-behave-turn"/> is processed as a failure as specified by <xref target="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 <xref target="I-D.ietf-behave-turn"/> SHOULD NOT be used for the specified duration even if returned by a subsequent resolution.
</t>
<t>First the resolution algorithm checks that the parameters can be resolved with the list of TURN transports supported by the application:</t>
<t>
<list style="symbols">
<t>If <secure> is false 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.</t>
<t>If <secure> is false 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.</t>
<t>If <secure> is true and <transport> is defined as "udp" then the algorithm MUST stop with an error.</t>
<t>If <secure> is true 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.</t>
<t>If <secure> is true 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.</t>
<t>If <transport> is defined but unknown then the resolution MUST stop with an error.</t>
</list>
</t>
<t>
After verifying the validity of the URI elements, the algorithm filters the list of TURN transports supported by the application by removing the UDP and TCP TURN transport if <secure> is true.
If the list of TURN transports is empty after this filtering, the resolution MUST stop with an error.
</t>
<t>
After filtering the list of TURN transports supported by the application, the algorithm applies the steps described below.
Note that in some steps, <secure> and <transport> have to be converted to a TURN transport.
If <secure> is false and <transport> is defined as "udp" then the TURN UDP transport is used.
If <secure> is false and <transport> is defined as "tcp" then the TURN TCP transport is used.
If <secure> is true and <transport> is defined as "tcp" then the TURN TLS transport is used.
This is summarized in <xref target="conversion"/>.
</t>
<texttable anchor="conversion">
<ttcol><secure></ttcol>
<ttcol><transport></ttcol>
<ttcol>TURN Transport</ttcol>
<c>false</c> <c>"udp"</c> <c>UDP</c>
<c>false</c> <c>"tcp"</c> <c>TCP</c>
<c>true</c> <c>"tcp"</c> <c>TLS</c>
</texttable>
<t>
<list style="numbers">
<t>
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 <xref target="I-D.ietf-behave-turn"/> for the "turn" SRV service name if <secure> is false, or the "turns" SRV service name if <secure> is true MUST be used for contacting the TURN server.
If <transport> is defined then <secure> and <transport> are converted to a TURN transport as specified in <xref target="conversion"/>.
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.
<vspace blankLines="1"/>
</t>
<t>
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 <secure> and <transport> are converted to a TURN transport as specified in <xref target="conversion"/>.
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.
<vspace blankLines="1"/>
</t>
<t>
If <host> is a domain name and <port> is not defined but <transport> is defined, then the SRV algorithm defined in <xref target="RFC2782"/> is used to generate a list of IP address and port tuples.
<host> is used as Name, a value of false for <secure> as "turn" for Service, a value of true for <secure> as "turns" for Service and <transport> as Protocol in the SRV algorithm.
<secure> and <transport> are converted to a TURN transport as specified in <xref target="conversion"/> 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 <xref target="I-D.ietf-behave-turn"/> for the "turn" SRV service name if <secure> is false, or the "turns" SRV service name if <secure> is true 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 <secure> and <transport> then the resolution MUST stop with an error.
<vspace blankLines="1"/>
</t>
<t>
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 <xref target="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.
<vspace blankLines="1"/>
</t>
<t>
If the first NAPTR query in the previous step does not return any result then the SRV algorithm defined in <xref target="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, "turn" for the Service if <secure> is false or "turns" for the Service if <secure> is true.
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 <xref target="I-D.ietf-behave-turn"/> for the "turn" SRV service name if <secure> is false, or the "turns" SRV service name if <secure> is true 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 transports from the filtered list then the resolution MUST stop with an error.
</t>
</list>
</t>
</section>
<section title="Examples">
<section anchor="example-1" title="Multiple Protocols">
<t>With the DNS RRs in <xref target="dns-rr1"/> and an ordered TURN transport list of {TLS, TCP, UDP}, the resolution algorithm will convert the parameters <secure> with a value of false, <host> with a value of "example.net" and <port> and <transport> been empty to the list of IP addresses, port and protocol tuples in <xref target="result1"/>.</t>
<t>
<figure anchor="dns-rr1"><artwork>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
</artwork></figure>
</t>
<texttable anchor="result1"><ttcol>Order</ttcol><ttcol>Protocol</ttcol><ttcol>IP address</ttcol><ttcol>Port</ttcol><c>1</c><c>UDP</c><c>192.0.2.1</c><c>3478</c><c>2</c><c>TLS</c><c>192.0.2.1</c><c>5349</c><c>3</c><c>TCP</c><c>192.0.2.1</c><c>5000</c></texttable>
</section>
<section title="Remote Hosting">
<t>
In the example in <xref target="remote-hosting"/>, a VoIP provider (example.com) is using the TURN servers managed by the administrators of the example.net domain (defined in <xref target="dns-rr1"/>).
The resolution algorithm using the ordered TURN transport list of {TLS, TCP, UDP} would convert the same parameters than in the previous example but with the <host> parameter equal to "example.com" to the list of IP addresses, port and protocol tuples in <xref target="result1"/>.
</t>
<figure anchor="remote-hosting">
<artwork>
example.com.
IN NAPTR 100 10 "" "RELAY:turn.udp:turn.tcp:turn.tls" "" example.net.
</artwork>
</figure>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>Security considerations for TURN are discussed in <xref target="I-D.ietf-behave-turn"/>.</t>
<t>
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 <xref target="RFC3958"/>.
<xref target="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 by the Long-Term Credential Mechanism defined in [RFC5389], which is mandatory for <xref target="I-D.ietf-behave-turn">TURN</xref>.
Additionally 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 <xref target="RFC5389"/>.
</t>
</section>
<section title="IANA Considerations">
<t>This section contains the registration information for one S-NAPTR Application Service Tag and three S-NAPTR Application Protocol Tags (in accordance with <xref target="RFC3958"/>).</t>
<section title="RELAY Application Service Tag Registration">
<t>Application Protocol Tag: RELAY</t>
<t>Intended usage: See <xref target="resolution"/>.</t>
<t>Interoperability considerations: N/A</t>
<t>Security considerations: See <xref target="security"/>.</t>
<t>Relevant publications: This document.</t>
<t>Contact information: Marc Petit-Huguenin <petithug@acm.org></t>
<t>Author/Change controller: The IESG</t>
</section>
<section title="turn.udp Application Protocol Tag Registration">
<t>Application Protocol Tag: turn.udp</t>
<t>Intended usage: See <xref target="resolution"/>.</t>
<t>Interoperability considerations: N/A</t>
<t>Security considerations: See <xref target="security"/>.</t>
<t>Relevant publications: This document.</t>
<t>Contact information: Marc Petit-Huguenin <petithug@acm.org></t>
<t>Author/Change controller: The IESG</t>
</section>
<section title="turn.tcp Application Protocol Tag Registration">
<t>Application Protocol Tag: turn.tcp</t>
<t>Intended usage: See <xref target="resolution"/>.</t>
<t>Interoperability considerations: </t>
<t>Security considerations: See <xref target="security"/>.</t>
<t>Relevant publications: This document.</t>
<t>Contact information: Marc Petit-Huguenin <petithug@acm.org></t>
<t>Author/Change controller: The IESG</t>
</section>
<section title="turn.tls Application Protocol Tag Registration">
<t>Application Protocol Tag: turn.tls</t>
<t>Intended usage: See <xref target="resolution"/>.</t>
<t>Interoperability considerations: N/A</t>
<t>Security considerations: See <xref target="security"/>.</t>
<t>Relevant publications: This document.</t>
<t>Contact information: Marc Petit-Huguenin <petithug@acm.org></t>
<t>Author/Change controller: The IESG</t>
</section>
</section>
<section title="Acknowledgements">
<t>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.</t>
<t>This document was written with the xml2rfc tool described in <xref target="RFC2629"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year="1997" month="March"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
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
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"/>
<format type="HTML" octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
<format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
</reference>
<reference anchor="RFC2782">
<front>
<title abbrev="DNS SRV RR">A DNS RR for specifying the location of services (DNS SRV)</title>
<author initials="A." surname="Gulbrandsen" fullname="Arnt Gulbrandsen">
<organization>Troll Tech</organization>
<address>
<postal>
<street>Waldemar Thranes gate 98B</street>
<city>Oslo</city>
<region/>
<code>N-0175</code>
<country>NO</country></postal>
<phone>+47 22 806390</phone>
<facsimile>+47 22 806380</facsimile>
<email>arnt@troll.no</email></address></author>
<author initials="P." surname="Vixie" fullname="Paul Vixie">
<organization>Internet Software Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country></postal>
<phone>+1 650 779 7001</phone></address></author>
<author initials="L." surname="Esibov" fullname="Levon Esibov">
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country></postal>
<email>levone@microsoft.com</email></address></author>
<date year="2000" month="February"/>
<abstract>
<t>This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.</t></abstract></front>
<seriesInfo name="RFC" value="2782"/>
<format type="TXT" octets="24013" target="ftp://ftp.isi.edu/in-notes/rfc2782.txt"/>
</reference>
<reference anchor="RFC3958">
<front>
<title>Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)</title>
<author initials="L." surname="Daigle" fullname="L. Daigle">
<organization/></author>
<author initials="A." surname="Newton" fullname="A. Newton">
<organization/></author>
<date year="2005" month="January"/>
<abstract>
<t>This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="3958"/>
<format type="TXT" octets="54568" target="ftp://ftp.isi.edu/in-notes/rfc3958.txt"/>
</reference>
<reference anchor="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials="D." surname="Crocker" fullname="D. Crocker">
<organization/></author>
<author initials="P." surname="Overell" fullname="P. Overell">
<organization/></author>
<date year="2008" month="January"/>
<abstract>
<t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<format type="TXT" octets="26359" target="ftp://ftp.isi.edu/in-notes/rfc5234.txt"/>
</reference>
<reference anchor="RFC5389">
<front>
<title>Session Traversal Utilities for NAT (STUN)</title>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization/></author>
<author initials="R." surname="Mahy" fullname="R. Mahy">
<organization/></author>
<author initials="P." surname="Matthews" fullname="P. Matthews">
<organization/></author>
<author initials="D." surname="Wing" fullname="D. Wing">
<organization/></author>
<date year="2008" month="October"/>
<abstract>
<t>Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.</t><t> STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.</t><t> This document obsoletes RFC 3489. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="5389"/>
<format type="TXT" octets="125650" target="ftp://ftp.isi.edu/in-notes/rfc5389.txt"/>
</reference>
<reference anchor="I-D.ietf-behave-turn">
<front>
<title>Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)</title>
<author initials="J" surname="Rosenberg" fullname="Jonathan Rosenberg">
<organization/>
</author>
<author initials="R" surname="Mahy" fullname="Rohan Mahy">
<organization/>
</author>
<author initials="P" surname="Matthews" fullname="Philip Matthews">
<organization/>
</author>
<date month="July" day="3" year="2009"/>
<abstract><t>If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it can be also used without ICE.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-behave-turn-16"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-16.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC2629">
<front>
<title>Writing I-Ds and RFCs using XML</title>
<author initials="M.T." surname="Rose" fullname="Marshall T. Rose">
<organization>Invisible Worlds, Inc.</organization>
<address>
<postal>
<street>660 York Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94110</code>
<country>US</country></postal>
<phone>+1 415 695 3975</phone>
<email>mrose@not.invisible.net</email>
<uri>http://invisible.net/</uri></address></author>
<date year="1999" month="June"/>
<area>General</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.</t></abstract></front>
<seriesInfo name="RFC" value="2629"/>
<format type="TXT" octets="48677" target="ftp://ftp.isi.edu/in-notes/rfc2629.txt"/>
<format type="HTML" octets="71741" target="http://xml.resource.org/public/rfc/html/rfc2629.html"/>
<format type="XML" octets="53481" target="http://xml.resource.org/public/rfc/xml/rfc2629.xml"/>
</reference>
<reference anchor="RFC4395">
<front>
<title>Guidelines and Registration Procedures for New URI Schemes</title>
<author initials="T." surname="Hansen" fullname="T. Hansen">
<organization/></author>
<author initials="T." surname="Hardie" fullname="T. Hardie">
<organization/></author>
<author initials="L." surname="Masinter" fullname="L. Masinter">
<organization/></author>
<date year="2006" month="February"/>
<abstract>
<t>This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
<seriesInfo name="BCP" value="35"/>
<seriesInfo name="RFC" value="4395"/>
<format type="TXT" octets="31933" target="ftp://ftp.isi.edu/in-notes/rfc4395.txt"/>
</reference>
<reference anchor="I-D.petithuguenin-behave-turn-uri-bis">
<front>
<title>Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers</title>
<author initials="M.P.H" surname="Petit-Huguenin" fullname="Marc Petit-Huguenin"><organization/></author>
<date day="25" month="November" year="2009"/>
<abstract>
<t>This document defines two URI schemes that can be used to provision the configuration values needed by the resolution mechanism defined in <xref target="I-D.ietf-behave-turn-uri"/>.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-petithuguenin-behave-turn-uri-bis-00"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-petithuguenin-behave-turn-uri-bis-00.txt"/>
</reference>
</references>
<section title="Release notes">
<t>This section must be removed before publication as an RFC.</t>
<section title="Modifications between ietf-05 and ietf-04">
<t>
<list style="symbols">
<t>Moved the URI stuff to <xref target="I-D.petithuguenin-behave-turn-uri-bis"/>.</t>
</list>
</t>
</section>
<section title="Modifications between ietf-04 and ietf-03">
<t>
<list style="symbols">
<t>Improved the algorithm steps.</t>
<t>It is possible to use a TLS transport event if the scheme is turn:.</t>
<t>Clarified when to stop the resolution with an error in step 2.</t>
<t>Added transport list filtering process.</t>
<t>Improved security section following sec-dir review.</t>
<t>Fixed nits reported by gen-art review.</t>
<t>Added example for remote hosting.</t>
<t>Removed URIs section.</t>
<t>Editorial modification.</t>
</list>
</t>
</section>
<section title="Modifications between ietf-03 and ietf-02">
<t>
<list style="symbols">
<t>
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.
</t>
<t>Reordered paragraphes in section 4.</t>
<t>Added table for conversion of <scheme> and <transport> to TURN transport.</t>
<t>Various editorial modifications.</t>
<t>SRV algorithm changed to "...recommending an A and AAAA query."</t>
<t>Put back the changelog for the versions before been accepted as WG item.</t>
</list>
</t>
</section>
<section title="Modifications between ietf-02 and ietf-01">
<t>
<list style="symbols">
<t>Shorten the abstract so it does not overflow on the second page.</t>
<t>Added text to explicitly say that the resolution is only to create an allocation.</t>
<t>Added text about failures.</t>
<t>Fixed the default port for TLS in the example.</t>
<t>Changed some priority in the example for RFC3958 section 2.2.5.</t>
<t>Fixed the service/protocol order for the SRV RR in the example.</t>
<t>Removed reference to draft-wood-tae-specifying-uri-transports as it has an experimental status.</t>
</list>
</t>
</section>
<section title="Modifications between ietf-01 and ietf-00">
<t>
<list style="symbols">
<t>Fixed the contact email.</t>
<t>Changed the IPR to trust200902.</t>
<t>Added case for transport defined but unknown.</t>
<t>Moved RFC 3958 to Normative References.</t>
<t>Added study of draft-wood-tae-specifying-uri-transports in TODO list.</t>
</list>
</t>
</section>
<section title="Modifications between petithuguenin-03 and ietf-00">
<t>
<list style="symbols">
<t>Renamed the document to "draft-ietf-behave-turn-uri".</t>
<t>Changed author affiliation.</t>
<t>Fixed the text in the IANA considerations.</t>
</list>
</t>
</section>
<section title="Modifications between petithuguenin-03 and petithuguenin-02">
<t>
<list style="symbols">
<t>Added Running Code Consideration section.</t>
<t>Added Remote Hosting example in introduction.</t>
<t>
Changed back to opaque URIs because of <xref target="RFC4395"/> Section 2.2.
Now use "?" as separator.
</t>
<t>Added IANA considerations section.</t>
<t>Added security considerations section.</t>
</list>
</t>
</section>
<section title="Modifications between petithuguenin-02 and petithuguenin-01">
<t>
<list style="symbols">
<t>Receiving a successful Allocate response stops the resolution mechanism and the resolution context must be discarded after this.</t>
<t>Changed from opaque to hierarchical URIs because the ";" character is used in <reg-name>.</t>
<t>Various nits.</t>
</list>
</t>
</section>
<section title="Modifications between petithuguenin-01 and petithuguenin-00">
<t>
<list style="symbols">
<t>Added <transport-ext> in the ABNF.</t>
<t>Use the <rulename> and "literal" usages for free-form text defined by <xref target="RFC5234"/>.</t>
<t>Fixed various typos.</t>
<t>Put the rule to convert <scheme> and <transport> to a TURN transport in a separate paragraph.</t>
<t>Modified the SRV usage to be in line with RFC 2782.</t>
<t>Clarified that the NAPTR protocol ranking must be used before the application ranking.</t>
<t>Added an example.</t>
<t>Added release notes.</t>
</list>
</t>
</section>
<section title="Design Notes">
<t>
<list style="symbols">
<t>The Application Service Tag is "RELAY" so other relaying mechanisms than TURN (e.g., TWIST) can be registered as Application Protocol Tags.</t>
<t>S-NAPTR was preferred to U-NAPTR because there is no use case for U-NAPTR.</t>
<t>Adding optional capabilities (IPv6 allocation, preserve bit, etc...) in the resolution process was rejected at the Dublin meeting.</t>
</list>
</t>
</section>
<section title="Running Code Considerations">
<t>
<list style="symbols">
<t>
Zap (<http://www.croczilla.com/zap>).
Eilon Yardeni, 8x8 Inc.
Implements version -00.
</t>
<t>
Reference Implementation of TURN URI parser and resolver (<http://ietf.implementers.org/turn-uri-0.3.zip>).
Marc Petit-Huguenin.
Implements version -05.
</t>
</list>
</t>
</section>
<section title="TODO List">
<t>(Empty)
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:51:26 |