One document matched: draft-ietf-mmusic-ice-options-registry-02.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-ietf-mmusic-ice-options-registry-02"
ipr="trust200902" updates="5245">
<front>
<title abbrev="IANA Registry for ICE">IANA Registry for Interactive
Connectivity Establishment (ICE) Options</title>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>SE-164 80 Kista</city>
<country>Sweden</country>
</postal>
<phone>+46 10 714 82 87</phone>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<author fullname="Colin Perkins" initials="C. " surname="Perkins">
<organization>University of Glasgow</organization>
<address>
<postal>
<street>School of Computing Science</street>
<city>Glasgow</city>
<code>G12 8QQ</code>
<country>United Kingdom</country>
</postal>
<email>csp@csperkins.org</email>
</address>
</author>
<date day="12" month="May" year="2011" />
<abstract>
<t>It has been identified that Interactive Connectivity Establishment
(ICE) RFC5245 is missing a registry for ICE options. This document
defines this missing IANA registry and updates RFC5245.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC5245">"Interactive Connectivity Establishment (ICE):
A Protocol for Network Address Translator (NAT) Traversal for
Offer/Answer"</xref> defines a concept of ICE Options. However, the ICE
RFC fails to create an IANA registry for ICE options. As one ICE option
is under specification in <xref
target="I-D.ietf-avtcore-ecn-for-rtp"></xref>, there is now a need to
create the registry.</t>
<t>RFC 5245 says: "ICE provides for extensibility by allowing an offer
or answer to contain a series of tokens that identify the ICE extensions
used by that agent. If an agent supports an ICE extension, it MUST
include the token defined for that extension in the ice-options
attribute."</t>
<t>Thus, as future extensions are defined, these ICE options needs to be
registered with IANA to ensure non-conflicting identification. The ICE
options identifiers are used in signalling between the ICE endpoints to
negotiate extension support. RFC 5245 defines one method of signalling
these ICE options, using <xref target="RFC3264">SDP with
Offer/Answer</xref>.</t>
<t>This document updates the ICE specification <xref
target="RFC5245"></xref> to define the "Interactive Connectivity
Establishment (ICE) Options" registry.</t>
</section>
<section title="Requirements Language">
<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">RFC 2119</xref>.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document defines a registry "Interactive Connectivity
Establishment (ICE) Options" for ICE options that can be used in SDP
"ice-options" attribute or other signalling parameters carrying the ICE
options.</t>
<section title="ICE Options">
<t>An ICE option identifier MUST fulfill the <xref
target="RFC5234">ABNF</xref> syntax for "ice-option-tag" as specified
in <xref target="RFC5245"></xref>. This syntax is reproduced here for
simplicity, but the authoritative definition is in the ICE RFC:</t>
<figure>
<artwork><![CDATA[ice-option-tag = 1*ice-char
ice-char = ALPHA / DIGIT / "+" / "/"]]></artwork>
</figure>
<t>ICE options are of unlimited length by the syntax, however they are
RECOMMENDED to be no longer than 20 characters. This is to reduce
message sizes and allow for efficient parsing.</t>
<t>Registration of an ICE option in the "Interactive Connectivity
Establishment (ICE) Options" registry is done using the Specification
Required policy as defined in <xref target="RFC5226">"Guidelines for
Writing an IANA Considerations Section in RFCs"</xref>.</t>
<t>A registration request MUST include the following information:<list
style="symbols">
<t>The ICE option identifier to be registered</t>
<t>Name, Email and Address of contact person for the
registration</t>
<t>Organization or individuals having the change control</t>
<t>Short description of the ICE extension to which the option
relates</t>
<t>Reference(s) to the specification defining the ICE option and
the related extensions</t>
</list></t>
<t>This document registers no ICE option.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>As this document defines an IANA registry for an already existing
concept there are no new security considerations.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank the people having reviewed the draft
and provided feedback, Flemming Andreasen, Mykyta Yevstifeyev, Amanda
Baber and Brian Carpenter.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.5226'?>
<?rfc include='reference.RFC.5234'?>
<?rfc include='reference.RFC.5245'?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3264"?>
<?rfc include='reference.I-D.draft-ietf-avtcore-ecn-for-rtp-01'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:36:35 |