One document matched: draft-ietf-behave-turn-uri-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?rfc compact="yes" ?><?rfc strict="no" ?><?rfc symrefs="yes" ?><?rfc toc="yes" ?><rfc ipr="trust200811" docName="draft-ietf-behave-turn-uri-00" category="std">
<front>
<title abbrev="TURN URIs">Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers</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 year="2008"/>
<abstract>
<t>This document defines two URI schemes and the resolution mechanism to convert these URIs to a list of server transport addresses that can be used between a Traversal Using Relays around NAT (TURN) client and server.</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 a <xref target="RFC3958">S-NAPTR application</xref> for this purpose.
This application defines "RELAY" as application service tag and "turn.udp", "turn.tcp", and "turn.tls" as application protocol tags.
</t>
<t>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.</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>
</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="syntax" title="Syntax of a TURN or TURNS URI">
<t>A TURN/TURNS URI has the following ABNF syntax <xref target="RFC5234"/>:</t>
<figure>
<artwork type="abnf">
turnURI = scheme ":" host [ ":" port ] [ "?transport=" transport ]
scheme = "turn" / "turns"
transport = "udp" / "tcp" / transport-ext
transport-ext = 1*unreserved
</artwork>
</figure>
<t><host>, <port> and <unreserved> are specified in <xref target="RFC3986"/>.</t>
</section>
<section anchor="resolution" title="TURN or TURNS URI Resolution">
<t>
The URI resolution algorithm uses <scheme>, <host>, <port> and <transport> as input.
It also uses a list ordered by preference of TURN transports (UDP, TCP, TLS) supported by the application using the TURN client.
The output of the algorithm is a list of {IP address, transport, port} tuples that a TURN client can try in order to contact a TURN server.
</t>
<t>
The resolution stops when a TURN client gets a successful Allocate response from a TURN server.
After receiving a successful Allocate response, the resolution context MUST be discarded and the URI resolution algorithm MUST be restarted from the beginning for any subsequent allocation.
</t>
<t>
In some steps <transport> and <scheme> 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.
</t>
<t>First the resolution algorithm checks that the URI can be resolved with the list of TURN transports supported:</t>
<t>
<list style="symbols">
<t>If <scheme> is defined as "turn" and <transport> is defined as "udp" but the list of TURN transports does not contain UDP then the resolution MUST stop with an error.</t>
<t>If <scheme> is defined as "turn" and <transport> is defined as "tcp" but the list of TURN transports does not contain TCP or TLS then the resolution MUST stop with an error.</t>
<t>If <scheme> is defined as "turns" and <transport> is defined as "udp" then the algorithm MUST stop with an error.</t>
<t>If <scheme> is defined as "turns" and <transport> is defined as "tcp" but the list of TURN transports does not contain TLS then the resolution MUST stop with an error.</t>
<t>If <scheme> is defined as "turns" and <transport> is not defined but the list of TURN transports does not contain TLS then the resolution MUST stop with an error.</t>
</list>
</t>
<t>Then the algorithm applies the following steps.</t>
<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 SRV service name defined in <scheme> is used.
If <transport> is defined then <scheme> and <transport> are converted to a TURN transport as specified above.
If <transport> is not defined, the 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 then the resolution MUST stop with an error.
</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 <scheme> and <transport> are converted to a TURN transport as specified above.
If <transport> is not defined, the TURN transports supported by the application are tried by preference order.
If the TURN client cannot contact a TURN server with this port and any combination of transports and resolved IP addresses then the resolution MUST stop with an error.
</t>
<t>
If <host> is a domain name and <port> is not defined but <transport> is defined then <host> is converted to a list of IP address and port tuples via a DNS SRV query as defined in <xref target="I-D.ietf-behave-turn"/> section 6.1.
<scheme> is used for the service name and <transport> is used for the protocol name in the <xref target="RFC2782">SRV algorithm</xref>.
If the TURN client cannot contact a TURN server at any of the IP address, port and transport tuples returned by the SRV algorithm then the resolution MUST stop with an error.
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 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 or AAAA query.
</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"/> with a "RELAY" Application Service Tag.
The 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 protocol tags is provided by the ranking of the first set of NAPTR records.
If multiple protocol tags have the same ranking, the preferred order set by the application is used.
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.
If the first NAPTR SRV query does not return any result then <host> is converted to a list of IP address and port tuples by using the algorithm specified in step 3 for each of the TURN transports supported by the application by order of preference.
</t>
</list>
</t>
</section>
<section title="Example">
<t>With the DNS RRs in <xref target="dns-rr"/> and a preferred protocol list of {TLS, TCP, UDP}, the resolution algorithm will convert the "turn:example.com" URI to the list of IP addresses, port and protocol tuples in <xref target="result"/>.</t>
<figure anchor="dns-rr">
<artwork>
example.com.
IN NAPTR 100 10 "" "RELAY:turn.udp" "" datagram.example.com.
IN NAPTR 200 10 "" "RELAY:turn.tcp:turn.tls" "" stream.example.com.
datagram.example.com.
IN NAPTR 100 10 "S" "RELAY:turn.udp" "" _udp._turn.example.com.
stream.example.com.
IN NAPTR 100 10 "A" "RELAY:turn.tls" "" a.example.com.
IN NAPTR 200 10 "S" "RELAY:turn.tcp" "" _tcp._turn.example.com.
_udp._turn.example.com.
IN SRV 0 0 5000 a.example.com.
_tcp._turn.example.com.
IN SRV 0 0 5000 a.example.com.
a.example.com.
IN A 192.0.2.1
</artwork>
</figure>
<texttable anchor="result">
<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>5000</c>
<c>2</c> <c>TLS</c> <c>192.0.2.1</c> <c>3478</c>
<c>3</c> <c>TCP</c> <c>192.0.2.1</c> <c>5000</c>
</texttable>
</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"/>.</t>
<t>The "turn" and "turns" URI schemes do not introduce any specific security issues beyond the security considerations discussed in <xref target="RFC3986"/>.</t>
</section>
<section title="IANA Considerations">
<t>This section contains the registration information for the "turn" and "turns" URI Schemes (in accordance with <xref target="RFC4395"/>), one S-NAPTR Application Service Tag, and three S-NAPTR Application Protocol Tags (in accordance with <xref target="RFC3958"/>).</t>
<section title="TURN URI Registration">
<t>URI scheme name: turn</t>
<t>Status: permanent</t>
<t>URI scheme syntax: See <xref target="syntax"/>.</t>
<t>URI scheme semantics: See <xref target="resolution"/>.</t>
<t>Encoding considerations: There are no encoding considerations beyond those in <xref target="RFC3986"/>.</t>
<t>Applications/protocols that use this URI scheme name:</t>
<t>
<list>
<t>The "turn" URI scheme is intended to be used by applications that might need access to a TURN server.</t>
</list>
</t>
<t>Interoperability considerations: N/A</t>
<t>Security considerations: See <xref target="security"/>.</t>
<t>Contact: Marc Petit-Huguenin <petithug@8x8.com></t>
<t>Author/Change controller: The IESG</t>
<t>References: This document.</t>
</section>
<section title="TURNS URI Registration">
<t>URI scheme name: turns</t>
<t>Status: permanent</t>
<t>URI scheme syntax: See <xref target="syntax"/>.</t>
<t>URI scheme semantics: See <xref target="resolution"/>.</t>
<t>Encoding considerations: There are no encoding considerations beyond those in <xref target="RFC3986"/>.</t>
<t>Applications/protocols that use this URI scheme name:</t>
<t>
<list>
<t>The "turns" URI scheme is intended to be used by applications that might need access to a TURN server.</t>
</list>
</t>
<t>Interoperability considerations: N/A</t>
<t>Security considerations: See <xref target="security"/>.</t>
<t>Contact: Marc Petit-Huguenin <petithug@8x8.com></t>
<t>Author/Change controller: The IESG</t>
<t>References: This document.</t>
</section>
<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@8x8.com></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@8x8.com></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@8x8.com></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@8x8.com></t>
<t>Author/Change controller: The IESG</t>
</section>
</section>
<section title="Running Code Considerations">
<t>The SIP client of the free and open source <eref target="http://www.croczilla.com/zap">Zap project</eref> uses the resolution mechanism and TURN URI described in this document.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to 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 xmlns:xi="http://www.w3.org/2001/XInclude" title="Normative References">
<reference anchor="RFC2119" xml:base="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<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" xml:base="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<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="RFC3986" xml:base="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<front>
<title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="Day Software">Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year="2005" month="January"/>
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
</t></abstract></front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<format type="TXT" octets="141811" target="ftp://ftp.isi.edu/in-notes/rfc3986.txt"/>
<format type="HTML" octets="213584" target="http://xml.resource.org/public/rfc/html/rfc3986.html"/>
<format type="XML" octets="163534" target="http://xml.resource.org/public/rfc/xml/rfc3986.xml"/>
</reference>
<reference anchor="RFC5234" xml:base="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<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="I-D.ietf-behave-turn" xml:base="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-turn.xml">
<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="November" day="30" year="2008"/>
<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-12"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-12.txt"/>
</reference>
</references>
<references xmlns:xi="http://www.w3.org/2001/XInclude" title="Informative References">
<reference anchor="RFC2629" xml:base="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<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="RFC3958" xml:base="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3958.xml">
<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="RFC4395" xml:base="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4395.xml">
<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="115"/>
<seriesInfo name="RFC" value="4395"/>
<format type="TXT" octets="31933" target="ftp://ftp.isi.edu/in-notes/rfc4395.txt"/>
</reference>
</references>
<section title="Release notes">
<t>This section must be removed before publication as an RFC.</t>
<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>
<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.
</t>
<t>As discussed in Dublin, there is no generic parameters in the URI to prevent compatibity issues.</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="TODO List">
<t>(Empty)
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:44:10 |