One document matched: draft-ietf-mmusic-ice-options-registry-00.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-00"
     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 year="2011" />

    <abstract>
      <t>It has been identified that Interactive Connectivity Establishment
      (ICE) is missing a registry for ICE options. This document defines this
      missing IANA registry.</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 there has come
      into existence at least one ICE option, there is 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 end-points to
      negotiate extension support. RFC 5245 defines one method of signaling
      these ICE options, using <xref target="RFC3264">SDP with
      Offer/Answer</xref>.</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 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 reproduce 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 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>Name of contact person for the registration</t>

            <t>Email and Address of the Contact person</t>

            <t>Organization or individuals having the change control</t>

            <t>The ICE option identifier</t>

            <t>Short description of the ICE extension</t>

            <t>Reference(s) to the specification defining the ICE option and
            the related extensions</t>
          </list></t>

        <t></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></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"?>
    </references>
  </back>
</rfc>