One document matched: draft-petithuguenin-behave-turn-uri-bis-04.xml


<?xml version="1.0" encoding="US-ASCII"?>
<?rfc compact="yes" ?>

<?rfc strict="no" ?>

<?rfc symrefs="yes" ?>

<?rfc toc="yes" ?>

<rfc category="info" docName="draft-petithuguenin-behave-turn-uri-bis-04" ipr="noModificationTrust200902">
	<front>
		<title abbrev="TURN URIs">Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers</title>

		<author fullname="Marc Petit-Huguenin" initials="M.P.H" surname="Petit-Huguenin">
			<organization>Unaffiliated</organization>

			<address>
				<email>petithug@acm.org</email>
			</address>
		</author>

		<date day="10" month="July" year="2011"/>

		<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="RFC5928"/>.</t>
		</abstract>
	</front>

	<middle>
		<section title="Introduction">
			<t>
<xref target="RFC5928"/> defines a resolution mechanism to convert a secure flag, an host name or IP address, a eventually empty port, and an eventually empty transport to a list of IP address, port, and TURN transport tuples.</t>

			<t>To simplify the provisioning of TURN clients, this document defines a TURN and a TURNS URI scheme that can carry the four components needed for the resolution mechanism.</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"><![CDATA[
turnURI       = scheme ":" turn-host [ ":" turn-port ]
              [ "?transport=" transport ]
scheme        = "turn" / "turns"
transport     = "udp" / "tcp" / transport-ext
transport-ext = 1*unreserved
turn-host     = IP-literal / IPv4address / reg-name
turn-port     = *DIGIT
IP-literal    = "[" ( IPv6address / IPvFuture  ) "]"
IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
IPv6address   =                            6( h16 ":" ) ls32
              /                       "::" 5( h16 ":" ) ls32
              / [               h16 ] "::" 4( h16 ":" ) ls32
              / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
              / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
              / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
              / [ *4( h16 ":" ) h16 ] "::"              ls32
              / [ *5( h16 ":" ) h16 ] "::"              h16
              / [ *6( h16 ":" ) h16 ] "::"
h16           = 1*4HEXDIG
ls32          = ( h16 ":" h16 ) / IPv4address
IPv4address   = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet     = DIGIT                 ; 0-9
              / %x31-39 DIGIT         ; 10-99
              / "1" 2DIGIT            ; 100-199
              / "2" %x30-34 DIGIT     ; 200-249
              / "25" %x30-35          ; 250-255
reg-name      = *( unreserved / pct-encoded / sub-delims )
				]]></artwork>
			</figure>

			<t><unreserved>, <sub-delims>, and <pct-encoded> are specified in <xref target="RFC3986"/>.</t>

			<t><secure> is equal to false is <scheme> is equal to "turn" and equal to false if <scheme> is equal to "turns".</t>
		</section>

		<section anchor="security" title="Security Considerations">
			<t>Security considerations for the resolution mechanism are discussed in <xref target="RFC5928"/>.</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"/>).</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="RFC5928"/>.</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@acm.org></t>
				<t>Author/Change controller: Marc Petit-Huguenin <petithug@acm.org></t>
				<t>References: This document.</t>
				<t>[Note to RFC Editor: Replace "This document" with reference to 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="RFC5928"/>.</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@acm.org></t>
				<t>Author/Change controller: Marc Petit-Huguenin <petithug@acm.org></t>
				<t>References: This document.</t>
				<t>[Note to RFC Editor: Replace "This document" with reference to this document]</t>
			</section>
		</section>

		<section title="Acknowledgements">
			<t>Thanks to 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>The <turn-port> and <turn-host> ABNF productions have been copied from the <port> and <host> ABNF productions from <xref target="RFC3986"/>.</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="RFC3986">

<front>
<title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="Tim Berners-Lee" initials="T." surname="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 fullname="Roy T. Fielding" initials="R." surname="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 fullname="Larry Masinter" initials="L." surname="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 month="January" year="2005"/>
<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 octets="141811" target="http://www.rfc-editor.org/rfc/rfc3986.txt" type="TXT"/>
<format octets="213584" target="http://xml.resource.org/public/rfc/html/rfc3986.html" type="HTML"/>
<format octets="163534" target="http://xml.resource.org/public/rfc/xml/rfc3986.xml" type="XML"/>
</reference>
			<reference anchor="RFC5234">

<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization/>
</author>
<author fullname="P. Overell" initials="P." surname="Overell">
<organization/>
</author>
<date month="January" year="2008"/>
<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 octets="26359" target="http://www.rfc-editor.org/rfc/rfc5234.txt" type="TXT"/>
</reference>
			<reference anchor="RFC5928">

<front>
<title>Traversal Using Relays around NAT (TURN) Resolution Mechanism</title>
<author fullname="M. Petit-Huguenin" initials="M." surname="Petit-Huguenin">
<organization/>
</author>
<date month="August" year="2010"/>
<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. [STANDARDS-TRACK]</t>
</abstract>
</front>

<seriesInfo name="RFC" value="5928"/>
<format octets="23993" target="http://www.rfc-editor.org/rfc/rfc5928.txt" type="TXT"/>
</reference>
		</references>

		<references title="Informative References">
			<reference anchor="RFC2629">

<front>
<title>Writing I-Ds and RFCs using XML</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="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 month="June" year="1999"/>
<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 octets="48677" target="http://www.rfc-editor.org/rfc/rfc2629.txt" type="TXT"/>
<format octets="71741" target="http://xml.resource.org/public/rfc/html/rfc2629.html" type="HTML"/>
<format octets="53481" target="http://xml.resource.org/public/rfc/xml/rfc2629.xml" type="XML"/>
</reference>
			<reference anchor="RFC4395">

<front>
<title>Guidelines and Registration Procedures for New URI Schemes</title>
<author fullname="T. Hansen" initials="T." surname="Hansen">
<organization/>
</author>
<author fullname="T. Hardie" initials="T." surname="Hardie">
<organization/>
</author>
<author fullname="L. Masinter" initials="L." surname="Masinter">
<organization/>
</author>
<date month="February" year="2006"/>
<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 octets="31933" target="http://www.rfc-editor.org/rfc/rfc4395.txt" type="TXT"/>
</reference>
		</references>

		<section title="Release notes">
			<t>This section must be removed before publication as an RFC.</t>

			<section title="Modifications between petithuguenin-04 and petithuguenin-03">
				<t>
					<list style="symbols">
						<t>Fixed references code link.</t>
					</list>
				</t>
			</section>

			<section title="Modifications between petithuguenin-03 and petithuguenin-02">
				<t>
					<list style="symbols">
						<t>Updated RFC references.</t>
					</list>
				</t>
			</section>

			<section title="Modifications between petithuguenin-02 and petithuguenin-01">
				<t>
					<list style="symbols">
						<t>Nits.</t>
					</list>
				</t>
			</section>

			<section title="Modifications between petithuguenin-01 and petithuguenin-00">
				<t>
					<list style="symbols">
						<t>Shorten I-D references.</t>
					</list>
				</t>
			</section>

			<section title="Design Notes">
				<t>
					<list style="symbols">
						<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>
					</list>
				</t>
			</section>

			<section title="Running Code Considerations">
				<t>
					<list style="symbols">
						<t>
							Reference Implementation of TURN URI parser and resolver (<http://debian.implementers.org/turn-uri.tar.gz>).
							Marc Petit-Huguenin.
							Implements version -04
						</t>
					</list>
				</t>
			</section>

			
		</section>
	</back>
</rfc>

PAFTECH AB 2003-20262026-04-23 22:23:12