One document matched: draft-nandakumar-rtcweb-stun-uri-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-nandakumar-rtcweb-stun-uri-06"
ipr="trust200902">
<front>
<title abbrev="STUN URI">URI Scheme for Session Traversal
Utilities for NAT (STUN) Protocol</title>
<author fullname="Suhas Nandakumar" initials="S"
surname="Nandakumar">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<email>snandaku@cisco.com</email>
</address>
</author>
<author fullname="Gonzalo Salgueiro" initials="G.S."
surname="Salgueiro">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>7200-12 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>
<email>gsalguei@cisco.com</email>
</address>
</author>
<author fullname="Paul E. Jones" initials="P.J." surname="Jones">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>7025 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>
<email>paulej@packetizer.com</email>
</address>
</author>
<author fullname="Marc Petit-Huguenin" initials="M.P.H"
surname="Petit-Huguenin">
<organization>Impedance Mismatch</organization>
<address>
<email>petithug@acm.org</email>
</address>
</author>
<date year="2013"/>
<area>Real Time Applications and Infrastructure</area>
<workgroup>RTCWEB</workgroup>
<abstract>
<t>This document is the specification of the syntax and
semantics of the Uniform Resource Identifier (URI) scheme for
the Session Traversal Utilities for NAT (STUN) protocol.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document specifies the syntax and semantics of the
Uniform Resource Identifier (URI) scheme for the Session
Traversal Utilities for NAT (STUN) protocol.</t>
<t>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, to perform connectivity checks between
two endpoints, and used as a keepalive protocol to maintain NAT
bindings. RFC 5389 <xref target="RFC5389"/> defines the
specifics of the STUN protocol.</t>
<t>The "stun" and "stuns" URI schemes are used to designate a
standalone STUN server or any Internet host performing the
operations of a STUN server in the context of STUN usages
(Section 14 RFC 5389 <xref target="RFC5389"/>). With the advent
of standards such as WEBRTC <xref target="WEBRTC"/>, we
anticipate a plethora of endpoints and web applications to be
able to identify and communicate with such a STUN server to
carry out the STUN protocol. This also implies those endpoints
and/or applications to be provisioned with appropriate
configuration required to identify the STUN server. Having an
inconsistent syntax has its drawbacks and can result in
non-interoperable solutions. It can result in solutions that are
ambiguous and have implementation limitations on the different
aspects of the syntax and alike. The 'stun/stuns' URI scheme
helps alleviate most of these issues by providing a consistent
way to describe, configure and exchange the information
identifying a STUN server. This would also prevent the
shortcomings inherent with encoding similar information in
non-uniform syntaxes such as the ones proposed in the WEBRTC
Standards <xref target="WEBRTC"/>, for example.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119"/> when they appear in ALL CAPS. When
these words are not in ALL CAPS (such as "should" or "Should"),
they have their usual english meanings, and are not to be
interpreted as RFC 2119 key words.</t>
</section>
<section anchor="syntax"
title="Definition of the STUN or STUNS URI">
<section anchor="URI_Scheme_Syntax" title="URI Scheme Syntax">
<t>A STUN/STUNS URI has the following formal ABNF syntax <xref
target="RFC5234"/>:</t>
<figure>
<artwork type="abnf"><![CDATA[
stunURI = scheme ":" stun-host [ ":" stun-port ]
scheme = "stun" / "stuns"
stun-host = IP-literal / IPv4address / reg-name
stun-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>, <pct-encoded>, and
<sub-delims> are specified in <xref target="RFC3986"/>.
The core rules <DIGIT> and <HEXDIGIT> are used as
described in Appendix B of RFC 5234 <xref
target="RFC5234"/>.</t>
</section>
<section anchor="URI_Scheme_Semantics"
title="URI Scheme Semantics">
<t>The STUN protocol supports sending messages over UDP, TCP
or TLS-over-TCP. The "stuns" URI scheme MUST be used when STUN
is run over TLS-over-TCP (or in the future DTLS-over-UDP) and
the "stun" scheme MUST be used otherwise.</t>
<t>The required <stun-host> part of the "stun" URI
denotes the STUN server host.</t>
<t>For the optional DNS Discovery procedure mentioned in the
Section 9 of RFC5389, "stun" URI scheme implies UDP as the
transport protocol for SRV lookup and "stuns" URI scheme
indicates TCP as the transport protocol.</t>
<t>As specified in <xref target="RFC5389"/>, the
<stun-port> part, if present, denotes the port on which
the STUN server is awaiting connection requests. If it is
absent, the default port is 3478 for both UDP and TCP. The
default port for STUN over TLS is 5349 as per Section 9 of
<xref target="RFC5389"/>.</t>
</section>
</section>
<section anchor="section.ref-impl" title="Implementation Status">
<t>Note to RFC Editor: Please remove this section and the
reference to <xref target="RFC6982"/> before publication.</t>
<t>This section records the status of known implementations of
the protocol defined by this specification at the time of
posting of this Internet-Draft, and is based on a proposal
described in <xref target="RFC6982"/>. The description of
implementations in this section is intended to assist the IETF
in its decision processes in progressing drafts to RFCs. Please
note that the listing of any individual implementation here does
not imply endorsement by the IETF. Furthermore, no effort has
been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must
not be construed to be, a catalog of available implementations
or their features. Readers are advised to note that other
implementations may exist.</t>
<t>According to <xref target="RFC6982"/>, "this will allow
reviewers and working groups to assign due consideration to
documents that have the benefit of running code, which may serve
as evidence of valuable experimentation and feedback that have
made the implemented protocols more mature. It is up to the
individual working groups to use this information as they see
fit".</t>
<section anchor="section.impl-status.libjingle"
title="libjingle">
<t><list style="hanging">
<t hangText="Organization: ">Google Inc.</t>
<t hangText="Name: ">libjingle 0.7.1
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/source/talk/app/webrtc/peerconnection.cc</t>
<t hangText="Description: ">Libjingle is a set of
components provided by Google to implement Jingle
protocols XEP-166
(http://xmpp.org/extensions/xep-0166.html) and XEP-167
(http://xmpp.org/extensions/xep-0167.html).</t>
<t hangText="Level of maturity: ">Beta.</t>
<t hangText="Coverage: ">Implements
draft-nandakumar-rtcweb-stun-uri-01 without IPv6.</t>
<t hangText="Licensing: ">BSD 3-clauses license.</t>
<t
hangText="Contact: ">https://code.google.com/p/chromium/</t>
<t
hangText="URL: ">https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/source/talk/app/webrtc/peerconnection.cc</t>
</list></t>
</section>
<section anchor="section.impl-status.firefox" title="Firefox">
<t><list style="hanging">
<t hangText="Organization: ">Mozilla</t>
<t hangText="Name: ">Firefox Aurora 21
http://hg.mozilla.org/mozilla-central/rev/6b5016ab9ebb</t>
<t hangText="Description: ">Mozilla Firefox is a free and
open source web browser.</t>
<t hangText="Level of maturity: ">Beta.</t>
<t hangText="Coverage: ">Implements
draft-nandakumar-rtcweb-stun-uri-03.</t>
<t hangText="Licensing: ">Mozilla Public License, v.
2.0.</t>
<t
hangText="Contact: ">http://www.mozilla.org/en-US/firefox/channel/</t>
<t
hangText="URL: ">http://hg.mozilla.org/mozilla-central/file/4ff1e574e509/media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp</t>
</list></t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>The "stun" and "stuns" 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
"stun" and "stuns" URI Schemes (in accordance with <xref
target="RFC4395"/>). Note that these URI schemes are intended
for use in very specific NAT traversal environments, and should
not be used otherwise on the open Web or Internet.</t>
<section title="STUN URI Registration">
<t>URI scheme name: stun</t>
<t>Status: permanent</t>
<t>URI scheme syntax: See <xref
target="URI_Scheme_Syntax"/>.</t>
<t>URI scheme semantics: See <xref
target="URI_Scheme_Semantics"/>.</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 "stun" URI scheme is intended to be used by
applications that might need access to a STUN server.</t>
</list></t>
<t>Interoperability considerations: N/A</t>
<t>Security considerations: See <xref target="security"/>.</t>
<t>Contact: Suhas Nandakumar <snandaku@cisco.com></t>
<t>Author/Change controller: The IESG</t>
<t>References: RFCXXXX</t>
<t>[[NOTE TO RFC EDITOR: Please change XXXX to the number
assigned to this specification, and remove this paragraph on
publication.]]</t>
</section>
<section title="STUNS URI Registration">
<t>URI scheme name: stuns</t>
<t>Status: permanent</t>
<t>URI scheme syntax: See <xref
target="URI_Scheme_Syntax"/>.</t>
<t>URI scheme semantics: See <xref
target="URI_Scheme_Semantics"/>.</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 "stuns" URI scheme is intended to be used by
applications that might need access to a STUN server over
a secure connection.</t>
</list></t>
<t>Interoperability considerations: N/A</t>
<t>Security considerations: See <xref target="security"/>.</t>
<t>Contact: Suhas Nandakumar <snandaku@cisco.com></t>
<t>Author/Change controller: The IESG</t>
<t>References: RFCXXXX;</t>
<t>[[NOTE TO RFC EDITOR: Please change XXXX to the number
assigned to this specification, and remove this paragraph on
publication.]]</t>
</section>
</section>
<section title="Acknowledgements">
<t>The authors would like to extend a very special thanks to
Cullen Jennings for bringing to our attention the WebRTC need
for this document, as well as his detailed review and thoughtful
comments on this document.</t>
<t>This document has benefited from extensive discussion and
review of many of the members of the RTCWEB and BEHAVE working
groups. The authors would also like to acknowledge Ted Hardie,
Bjoern Hoehrmann, Russ Housley, Subramanian Moonesamy, Hadriel
Kaplan, Graham Klyne, Peter Saint-Andre and Harald Alvestrand
for their invaluable input, reviews, feedback comments, and
suggestions that helped to improve this document.</t>
<t>The authors would also like to express their gratitude to Dan
Wing for his assistance in shepherding this document. We also
want to thank Gonzalo Camarillo, the Real-time Applications and
Infrastructure Director, for sponsoring this document as well
his careful reviews.</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 fullname="Scott Bradner" initials="S."
surname="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 month="March" year="1997"/>
<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 octets="4723"
target="http://www.rfc-editor.org/rfc/rfc2119.txt"
type="TXT"/>
<format octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML"/>
<format octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML"/>
</reference>
<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>
</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>
<reference anchor="RFC5389">
<front>
<title>Session Traversal Utilities for NAT (STUN)</title>
<author fullname="J. Rosenberg" initials="J."
surname="Rosenberg">
<organization/>
</author>
<author fullname="R. Mahy" initials="R." surname="Mahy">
<organization/>
</author>
<author fullname="P. Matthews" initials="P."
surname="Matthews">
<organization/>
</author>
<author fullname="D. Wing" initials="D." surname="Wing">
<organization/>
</author>
<date month="October" year="2008"/>
<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 octets="125650"
target="http://www.rfc-editor.org/rfc/rfc5389.txt"
type="TXT"/>
</reference>
<reference anchor="WEBRTC"
target="http://www.w3.org/TR/2012/WD-webrtc-20120821">
<front>
<title>WebRTC 1.0: Real-time Communication Between
Browsers</title>
<author fullname="Adam Bergkvist" initials="A."
surname="Bergkvist">
<organization/>
</author>
<author fullname="Daniel C. Burnett" initials="D."
surname="Burnett">
<organization/>
</author>
<author fullname="Cullen Jennings" initials="C."
surname="Jennings">
<organization/>
</author>
<author fullname="Anant Narayanan" initials="A."
surname="Narayanan">
<organization/>
</author>
<date day="21" month="August" year="2012"/>
</front>
<seriesInfo name="World Wide Web Consortium WD"
value="WD-webrtc-20120821"/>
<format target="http://www.w3.org/TR/2012/WD-webrtc-20120821"
type="HTML"/>
</reference>
<reference anchor="RFC6982">
<front>
<title>Improving Awareness of Running Code: The
Implementation Status Section</title>
<author fullname="Y. Sheffer" initials="Y."
surname="Sheffer">
<organization/>
</author>
<author fullname="A. Farrel" initials="A." surname="Farrel">
<organization/>
</author>
<date month="July" year="2013"/>
<abstract>
<t>This document describes a simple process that allows
authors of Internet-Drafts to record the status of known
implementations by including an Implementation Status
section. This will allow reviewers and working groups to
assign due consideration to documents that have the
benefit of running code, which may serve as evidence of
valuable experimentation and feedback that have made the
implemented protocols more mature.</t>
<t>The process in this document is offered as an
experiment. Authors of Internet-Drafts are encouraged to
consider using the process for their documents, and
working groups are invited to think about applying the
process to all of their protocol specifications. The
authors of this document intend to collate experiences
with this experiment and to report them to the
community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6982"/>
<format octets="19358"
target="http://www.rfc-editor.org/rfc/rfc6982.txt"
type="TXT"/>
</reference>
</references>
<section title="Examples">
<t><xref target="examples1"/> shows examples for 'stun/stuns'uri
scheme. For all these examples, the <host> component is
populated with "example.org".</t>
<texttable anchor="examples1">
<ttcol>URI</ttcol>
<c>stun:example.org</c>
<c>stuns:example.org</c>
<c>stun:example.org:8000</c>
</texttable>
</section>
<section title="Design Notes">
<t><list style="symbols">
<t>The ABNF in this document duplicates the
<IP-literal>, <IPv4address>, and
<reg-name> productions and other dependent productions
from <xref target="RFC3986"/>, instead of referencing them.
This is because the definitions in <xref target="RFC3986"/>
are for hierarchical URIs, so using these references in an
opaque URI made reviewers think that a hierarchical URI
parser could be used to parse the URIs defined in this
document.</t>
<t>One recurring comment was to stop using the suffix "s" on
URI scheme, and to move the secure option to a parameter
(e.g., ";proto=tls"). We decided against this idea because
the need for ";proto=" for the STUN URI cannot be
sufficiently explained and supporting it would render an
incomplete specification. This would also result in lost
symmetry between the TURN and STUN URIs. A more detailed
account of the reasoning behind this is available at
<http://blog.marc.petit-huguenin.org/2012/09/on-design-of-stun-and-turn-uri-formats.html></t>
<t>Following the advice of Section 2.2 of <xref
target="RFC4395"/>, and because the STUN URI does not
describe a hierarchical structure, the STUN URIs are
opaque.</t>
</list></t>
</section>
<section title="Release notes">
<t>NOTE TO RFC EDITOR: This section must be removed before
publication as an RFC.</t>
<section title="Modifications between draft-nandakumar-rtcweb-stun-uri-06 and draft-nandakumar-rtcweb-stun-uri-05">
<t><list style="symbols">
<t>Removed the <IP-literal>, <IPv4address>,
and <reg-name> ABNF productions and other dependant
productions, added references to RFC 3986, and modified
the design note to warn developers against using a
hierarchical URI parser.</t>
<t>Updated the normative reference for RFC 6982, refreshed
the boilerplate, moved the download links into the name
item.</t>
<t>Added an annotation to the scheme registration
indicating the appropriate usage scope for the stun/stuns
URI schemes.</t>
<t>Added clarification that RFC 5389 are the references
for finding the default port.</t>
<t>Cleaned up the Acknowledgements text.</t>
<t>Added an additional Design Note regarding the opaque
nature of STUN URIs.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:35:11 |