<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" [
	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
	<!ENTITY RFC3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
	<!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
	<!ENTITY RFC3758 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3758.xml">
	<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
	<!ENTITY RFC4582 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4582.xml">
	<!ENTITY RFC4975 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4975.xml">
	<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
	<!ENTITY RFC6455 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6455.xml">
	<!ENTITY RFC6525 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6525.xml">
	<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
	<!ENTITY DATAREQ SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-data-channel.xml">
	<!ENTITY DATAPROTO SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-data-protocol.xml">
	<!ENTITY SDPSCTP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sctp-sdp.xml">
	<!ENTITY SDPBIS SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mmusic-rfc4566bis-32.xml">
	<!ENTITY SDPMUXATTR SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sdp-mux-attributes.xml">
	<!ENTITY CLUEDATA SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-clue-datachannel.xml">
	<!ENTITY MSRPDATA SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-msrp-usage-data-channel.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes" ?> version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-mmusic-data-channel-sdpneg-28" ipr="trust200902"> indexInclude="true" ipr="trust200902" number="8864" prepTime="2021-01-18T22:48:58" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg-28" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8864" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="SDP-based abbrev="SDP-Based Data Channel Negotiation">
                 SDP-based Negotiation">Negotiation Data Channel Negotiation
  </title> Channels Using the Session Description Protocol (SDP)</title>
    <seriesInfo name="RFC" value="8864" stream="IETF"/>
    <author initials="K. E." initials="K." surname="Drage" fullname="Keith Drage">
			<organization>Unaffiliated</organization>
      <organization showOnFrontPage="true">Unaffiliated</organization>
      <address>
        <email>drageke@ntlworld.com</email>
      </address>
    </author>
    <author initials="M. R." initials="M." surname="Makaraju" fullname="Maridi R. Makaraju (Raju)">
			<organization>Nokia</organization>
      <organization showOnFrontPage="true">Unaffiliated</organization>
      <address>
				<postal>
					<street>2000 Lucent Lane</street>
					<city>Naperville</city>
					<region>Illinois</region>
					<country>US</country>
				</postal>
				<email> Raju.Makaraju@nokia.com</email>
        <email>mmraju@gmail.com</email>
      </address>
    </author>
    <author fullname="Richard Ejzak" initials="R.P." initials="R." surname="Ejzak">
			<organization>Unaffiliated</organization>
      <organization showOnFrontPage="true">Unaffiliated</organization>
      <address>
        <email>richard.ejzak@gmail.com</email>
      </address>
    </author>
    <author fullname="Jerome Marcon" initials="J.M." initials="J." surname="Marcon">
			<organization>Unaffiliated</organization>
      <organization showOnFrontPage="true">Unaffiliated</organization>
      <address>
        <email>jeromee.marcon@free.fr</email>
      </address>
    </author>
    <author initials="R. E." initials="R." surname="Even" fullname="Roni Even" role="editor">
			<organization>Huawei</organization>
      <organization showOnFrontPage="true"/>
      <address>
				<email>roni.even@huawei.com</email>
        <email>ron.even.tlv@gmail.com</email>
      </address>
    </author>
    <date month="May" year="2019"/>
		<area>ART</area>
		<workgroup>MMUSIC</workgroup>
		<abstract>
			<t> month="01" year="2021"/>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">  Data channel setup can be done using either the in-band Data Channel Establishment Protocol (DCEP) or using some out-of-band non-DCEP protocol.  This document specifies how the SDP (Session
   Description Protocol) offer/answer exchange can be used to achieve
   an out-of-band non-DCEP negotiation for establishing a data channel.
</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8864" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions">Conventions</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-applicability-statement">Applicability Statement</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sdp-data-channel-attributes">SDP Data Channel Attributes</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sdp-dcmap-attribute">SDP DCMAP Attribute</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2">
                  <li pn="section-toc.1-1.5.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dcmap-attribute-syntax">DCMAP Attribute Syntax</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dcmap-stream-id-parameter">'dcmap-stream-id' Parameter</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.3.1"><xref derivedContent="5.1.3" format="counter" sectionFormat="of" target="section-5.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-label-parameter">'label' Parameter</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.4.1"><xref derivedContent="5.1.4" format="counter" sectionFormat="of" target="section-5.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-subprotocol-parameter">'subprotocol' Parameter</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.5">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.5.1"><xref derivedContent="5.1.5" format="counter" sectionFormat="of" target="section-5.1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-max-retr-parameter">'max-retr' Parameter</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.6">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.6.1"><xref derivedContent="5.1.6" format="counter" sectionFormat="of" target="section-5.1.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-max-time-parameter">'max-time' Parameter</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.7">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.7.1"><xref derivedContent="5.1.7" format="counter" sectionFormat="of" target="section-5.1.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ordered-parameter">'ordered' Parameter</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.8">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.8.1"><xref derivedContent="5.1.8" format="counter" sectionFormat="of" target="section-5.1.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-priority-parameter">'priority' Parameter</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.9">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.9.1"><xref derivedContent="5.1.9" format="counter" sectionFormat="of" target="section-5.1.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dcmap-multiplexing-category">DCMAP Multiplexing Category</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sdp-dcsa-attribute">SDP DCSA Attribute</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.2.2">
                  <li pn="section-toc.1-1.5.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dcsa-attribute-syntax">DCSA Attribute Syntax</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.2.1"><xref derivedContent="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dcsa-multiplexing-category">DCSA Multiplexing Category</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sdp-offer-answer-procedures">SDP Offer/Answer Procedures</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-managing-stream-identifiers">Managing Stream Identifiers</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-negotiating-data-channel-pa">Negotiating Data Channel Parameters</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-generating-the-initial-offe">Generating the Initial Offer for a Data Channel</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-generating-the-sdp-answer">Generating the SDP Answer</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-offerer-processing-of-the-s">Offerer Processing of the SDP Answer</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.6">
                <t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent="6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-modifying-the-session">Modifying the Session</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.6.2">
                  <li pn="section-toc.1-1.6.2.6.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.6.2.1.1"><xref derivedContent="6.6.1" format="counter" sectionFormat="of" target="section-6.6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-closing-a-data-channel">Closing a Data Channel</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.7">
                <t indent="0" pn="section-toc.1-1.6.2.7.1"><xref derivedContent="6.7" format="counter" sectionFormat="of" target="section-6.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-various-sdp-offer-answer-co">Various SDP Offer/Answer Considerations</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-examples">Examples</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-subprotocol-identifiers">Subprotocol Identifiers</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-sdp-attributes">New SDP Attributes</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2.2.2">
                  <li pn="section-toc.1-1.9.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.9.2.2.2.1.1"><xref derivedContent="9.2.1" format="counter" sectionFormat="of" target="section-9.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dcmap">dcmap</xref></t>
                  </li>
                  <li pn="section-toc.1-1.9.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.9.2.2.2.2.1"><xref derivedContent="9.2.2" format="counter" sectionFormat="of" target="section-9.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dcsa">dcsa</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.9.2.3">
                <t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent="9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registering-attributes-for-">Registering Attributes for Use with Data Channels</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-generic-data-channel-negoti">Generic Data Channel Negotiation Aspects when Not Using DCEP</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-stream-identifier-numbering">Stream Identifier Numbering</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-generic-data-channel-negotia">Generic Data Channel Negotiation Not Using DCEP</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2.2.2">
                  <li pn="section-toc.1-1.11.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.11.2.2.2.1.1"><xref derivedContent="A.2.1" format="counter" sectionFormat="of" target="section-a.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview">Overview</xref></t>
                  </li>
                  <li pn="section-toc.1-1.11.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.11.2.2.2.2.1"><xref derivedContent="A.2.2" format="counter" sectionFormat="of" target="section-a.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-opening-a-data-channel">Opening a Data Channel</xref></t>
                  </li>
                  <li pn="section-toc.1-1.11.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.11.2.2.2.3.1"><xref derivedContent="A.2.3" format="counter" sectionFormat="of" target="section-a.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-closing-a-data-channel-2">Closing a Data Channel</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section title="Introduction" anchor="introduction">
			<t> anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">   The concept of establishing a bi-directional bidirectional
   data channel running on top of the Stream Control Transmission
   Protocol (SCTP) is discussed in
 <xref target="I-D.ietf-rtcweb-data-channel"/> target="RFC8831" format="default" sectionFormat="of" derivedContent="RFC8831"/>, allowing applications to use data channels. An in-band Data
   Channel Establishment Protocol (DCEP) is described in <xref target="I-D.ietf-rtcweb-data-protocol"/>,
   however target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>;
   however, other in-band or out-of-band
   protocols may be used for establishing data channels.  Each data
   channel consists of paired SCTP streams sharing the same SCTP Stream
   Identifier.  Data channels are created by endpoint applications using
   the
   (1) the WebRTC API (Application Programming Interface), Interface) <xref target="WebRtcAPI" format="default" sectionFormat="of" derivedContent="WebRtcAPI"/> or (2)  other protocols
   like CLUE
 <xref target="I-D.ietf-clue-datachannel"/>.
   (e.g., Controlling Multiple Streams for Telepresence (CLUE)
 <xref target="RFC8850" format="default" sectionFormat="of" derivedContent="RFC8850"/>).  The protocols can be signaled
   by the data channel "subprotocol" 'subprotocol' parameter, conceptually similar to
   the
   a WebSocket subprotocol as described in <xref target="RFC5234"/> "subprotocol". target="RFC6455" format="default" sectionFormat="of" derivedContent="RFC6455"/>.
 However, apart from the
   "subprotocol" value transmitted to the peer, an endpoint application can agree on how to instantiate a given
   subprotocol on a data channel, and whether it is signaled in-band
   using DCEP or out-of-band using a non-DCEP protocol (or both).  </t>
			<t>This both).</t>
      <t indent="0" pn="section-1-2">This document defines SDP Session Description Protocol (SDP) offer/answer <xref target="RFC3264"/>
      procedures <xref target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/> that enable out-of-band negotiation
for establishing data channels for transport of well-defined subprotocols.
   These procedures are based on generic SDP offer/answer negotiation rules for SCTP
   based SCTP-based media transport as specified in <xref target="I-D.ietf-mmusic-sctp-sdp"/> target="RFC8841" format="default" sectionFormat="of" derivedContent="RFC8841"/> for
   the SDP "m" "m=" line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP.
      </t>
			<t>This
      <t indent="0" pn="section-1-3">This document uses MSRP (Message (the Message Session Relay Protocol) <xref target="RFC4975"/> target="RFC4975" format="default" sectionFormat="of" derivedContent="RFC4975"/>
   and BFCP (Binary (the Binary Floor Control Protocol) <xref target="RFC4582"/> target="RFC8855" format="default" sectionFormat="of" derivedContent="RFC8855"/> in many of the several examples. It does not provide a
   complete specification of how to negotiate the use of a data channel to transport
   MSRP. Procedures specific to each
   subprotocol would have to be documented elsewhere. For MSRP MSRP, they are documented in <xref target="I-D.ietf-mmusic-msrp-usage-data-channel"/> . target="RFC8873" format="default" sectionFormat="of" derivedContent="RFC8873"/>. The use of MSRP in some examples is only to show how the generic
   procedures described herein might apply to a specific subprotocol.
      </t>
    </section>
    <section title="Conventions">
			<t>The numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-conventions">Conventions</name>
      <t indent="0" pn="section-2-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
     "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
     "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
     "<bcp14>SHOULD NOT</bcp14>",
     "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
     "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
     to be interpreted as described in BCP14 BCP 14 <xref target="RFC2119"/>
				<xref target="RFC8174"/> target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>
        <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals,
     as shown here.

			</t> here.</t>
    </section>
    <section title="Terminology" anchor="terminology">
			<t>This anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-3-1">This document uses the following terms:
    <list style="hanging">
					<t>Data channel: A
      </t>
      <dl newline="false" spacing="normal" indent="3" pn="section-3-2">
        <dt pn="section-3-2.1">Data channel:</dt>
        <dd pn="section-3-2.2">A WebRTC data channel as specified in
     <xref target="I-D.ietf-rtcweb-data-channel"/>.</t>
					<t>Data channel stack: An target="RFC8831" format="default" sectionFormat="of" derivedContent="RFC8831"/>.</dd>
        <dt pn="section-3-2.3">Data channel stack:</dt>
        <dd pn="section-3-2.4">An entity which, that, upon application request,
     runs the data channel protocol to keep track of states, states as well as the
     sending and receiving of data. If the application is a browser based browser-based JavaScript application application,
     then this stack resides in the browser. If the application is a
     native application application, then this stack resides in the application and is accessible
     via some sort of APIs.</t>
					<t>Data channel properties: Fixed API or APIs.</dd>
        <dt pn="section-3-2.5">Data channel properties:</dt>
        <dd pn="section-3-2.6">Fixed properties assigned to a data
     channel at the time of its creation. Some of these properties
     determine the way the data channel stack transmits data on this
     channel (e.g., stream identifier, reliability, order of delivery, etc.).</t>
					<t>Data channel subprotocol: The delivery).</dd>
        <dt pn="section-3-2.7">Data channel subprotocol:</dt>
        <dd pn="section-3-2.8">The application protocol which that is transported
     over a single data channel. Data channel subprotocol messages are sent as data
     channel payload over an established data channel. An SDP offer/answer exchange can be used
     as specified in this document to negotiate the establishment of data channels,
     corresponding data channel properties, associated data channel subprotocols subprotocols, and data
     channel subprotocol properties. In this case case, the data channel subprotocols may be identified
     by the values of the "subprotocol" 'subprotocol' parameters of the SDP "a=dcmap" "a=dcmap:" attribute as
     described in <xref target="subprotocol-parameter"/>. target="subprotocol-parameter" format="default" sectionFormat="of" derivedContent="Section 5.1.4"/>. Within this document document, the term
     "data channel subprotocol" is often abbreviated as just "subprotocol".
     </t>
					<t>DCEP: Data
     </dd>
        <dt pn="section-3-2.9">DCEP:</dt>
        <dd pn="section-3-2.10">Data Channel Establishment Protocol Protocol, as defined in
     <xref target="I-D.ietf-rtcweb-data-protocol"/>.</t>
					<t>In-band: Transmission target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>.</dd>
        <dt pn="section-3-2.11">In-band:</dt>
        <dd pn="section-3-2.12">Transmission through the peer-to-peer SCTP association.</t>
					<t>Out-of-band: Transmission association.</dd>
        <dt pn="section-3-2.13">Out-of-band:</dt>
        <dd pn="section-3-2.14">Transmission through the application signaling path.</t>
					<t>Peer: From path.</dd>
        <dt pn="section-3-2.15">Peer:</dt>
        <dd pn="section-3-2.16">From the perspective of one of the agents in a session, its
     peer is the other agent. Specifically, from the perspective of the
     SDP offerer, the peer is the SDP answerer. From the perspective of
     the SDP answerer, the peer is the SDP offerer.</t>
					<t>SCTP offerer.</dd>
        <dt pn="section-3-2.17">SCTP Stream Sequence Number (SSN): the (SSN):</dt>
        <dd pn="section-3-2.18">The SCTP stream sequence number Stream Sequence Number, as specified
     in <xref target="RFC4960"/>.</t>
					<t>Stream identifier: The target="RFC4960" format="default" sectionFormat="of" derivedContent="RFC4960"/>.</dd>
        <dt pn="section-3-2.19">Stream identifier:</dt>
        <dd pn="section-3-2.20">The identifier of the outbound and inbound
     SCTP streams composing a data channel.</t>
				</list>
			</t> channel.</dd>
      </dl>
    </section>
    <section title=" Applicability Statement" anchor="appl_statement">
			<t> anchor="appl_statement" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-applicability-statement">Applicability Statement</name>
      <t indent="0" pn="section-4-1"> The mechanism described in this document only applies to the Session Description
   Protocol (SDP) SDP <xref target="I-D.ietf-mmusic-rfc4566bis"/> target="RFC8866" format="default" sectionFormat="of" derivedContent="RFC8866"/> when used together with the SDP offer/answer
   mechanism <xref target="RFC3264"/>. target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/>. Declarative usage of SDP is out of scope for this
   document,
   document and is thus undefined.</t>
    </section>
    <section title="SDP anchor="sdp_synt" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-sdp-data-channel-attributes">SDP Data Channel Attributes" anchor="sdp_synt">
			<t>This Attributes</name>
      <t indent="0" pn="section-5-1">This section defines two new SDP media-level attributes that can be
      used together with the SDP Offer/Answer mechanism to negotiate data channel-specific
      data-channel-specific and subprotocol-specific parameters without the
      usage of DCEP <xref target="I-D.ietf-rtcweb-data-protocol"/>. target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>. The first attribute (<xref target="subsec-sdp-attr-for-dc-par-neg" format="default" sectionFormat="of" derivedContent="Section 5.1"/>) provides for negotiation of
     channel-specific parameters. The second attribute (<xref target="prot_att" format="default" sectionFormat="of" derivedContent="Section 5.2"/>) provides for
     negotiation of subprotocol-specific parameters.</t>
			<t>
      <aside pn="section-5-2">
        <t indent="0" pn="section-5-2.1">
Note: Appendix A <xref target="generic-out-of-band-aspects" format="default" sectionFormat="of" derivedContent="Appendix A"/> provides information
regarding how data channels work in general and
   especially general. In particular, it
   summarizes some key aspects, which aspects that should be considered
   for the negotiation of data channels if DCEP is not used.
</t> used.</t>
      </aside>
      <section title="SDP anchor="subsec-sdp-attr-for-dc-par-neg" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-sdp-dcmap-attribute">SDP DCMAP Attribute " anchor="subsec-sdp-attr-for-dc-par-neg">
				<t>This Attribute</name>
        <t indent="0" pn="section-5.1-1">This section defines a new media level attribute  "a=dcmap:" media-level attribute, "a=dcmap:", that defines the data channel parameters for
      each data channel to be negotiated. </t>
				<t>The
        <t indent="0" pn="section-5.1-2">This attribute is used to create bi-directional bidirectional SCTP data channels
   having the same set of attributes.  The data channel properties
   (reliable/partially
   (reliable / partially reliable, ordered/unordered) need to be suitable per the subprotocol transport requirements.
</t>
        <section title="DCMAP anchor="dcmap-attr-definition" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.1">
          <name slugifiedName="name-dcmap-attribute-syntax">DCMAP Attribute Syntax" anchor="dcmap-attr-definition">
					<t>"a=dcmap:" Syntax</name>
          <t indent="0" pn="section-5.1.1-1">"a=dcmap:" is a media level media-level attribute having the following
          definition and ABNF (Augmented Backus-Naur Form, Form) syntax <xref target="RFC5234"/>) syntax.

       <figure target="RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/>.

          </t>
          <table anchor="dcmap-attrib" align="center" pn="table-1">
            <name slugifiedName="name-adcmap-attribute-definition">"a=dcmap:" Attribute Definition</name>
            <thead>
              <tr>
                <th colspan="2" align="center" rowspan="1">"a=dcmap:" Attribute</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" title="">
							<artwork align="left"><![CDATA[
Formal Syntax:

Name: dcmap

Value: dcmap-value

Usage Level: media

Charset Dependent: no

Syntax: colspan="1" rowspan="1">Name</td>
                <td align="left" colspan="1" rowspan="1">dcmap</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Value</td>
                <td align="left" colspan="1" rowspan="1">dcmap-value</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Usage Level</td>
                <td align="left" colspan="1" rowspan="1">media</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Charset Dependent</td>
                <td align="left" colspan="1" rowspan="1">No</td>
              </tr>
            </tbody>
          </table>
          <t indent="0" pn="section-5.1.1-3">Formal syntax:</t>
          <sourcecode name="abnf-1" type="abnf" markers="false" pn="section-5.1.1-4">
dcmap-value     = dcmap-stream-id
                  [ SP dcmap-opt *(";" dcmap-opt) ]
dcmap-opt       = ordering-opt / subprotocol-opt / label-opt
                  / maxretr-opt / maxtime-opt / priority-opt
                  ; maxretr-opt and maxtime-opt are
                  ; mutually exclusive
                  ;

dcmap-stream-id = 1*5DIGIT
ordering-opt    = "ordered=" ordering-value
ordering-value  = "true" / "false"
subprotocol-opt = "subprotocol=" quoted-string
label-opt       = "label=" quoted-string
maxretr-opt     = "max-retr=" maxretr-value
maxretr-value   = "0" / integer
                  ; number of retransmissions,
                  ; less than 2^32,
                  ; derived from 'Reliability Parameter' of
                  ; [I-D.ietf-rtcweb-data-protocol] [RFC8832]
maxtime-opt     = "max-time=" maxtime-value
maxtime-value   = "0" / integer
                  ; milliseconds,
                  ; less than 2^32,
                  ; derived from 'Reliability Parameter' of
                  ; [I-D.ietf-rtcweb-data-protocol] [RFC8832]
priority-opt    = "priority=" priority-value
priority-value  = "0" / integer
                  ; unsigned integer value indicating the priority of
                  ; the data channel,
                  ; less than 2^16,
                  ; derived from 'Priority' of
                  ; [I-D.ietf-rtcweb-data-protocol] [RFC8832]

quoted-string   = DQUOTE *(quoted-char / escaped-char) DQUOTE
quoted-char     = SP / quoted-visible
quoted-visible  = %x21 / %x23-24 / %x26-7E ; VCHAR without " or %
escaped-char    = "%" HEXDIG HEXDIG
DQUOTE          = <from-RFC5234> &lt;from RFC 5234&gt;
integer         = <from-RFC4566>

Examples: &lt;from RFC 8866&gt;</sourcecode>
          <t indent="0" pn="section-5.1.1-5">Examples:</t>
          <sourcecode name="sdp-1" type="sdp" markers="false" pn="section-5.1.1-6">
a=dcmap:0
a=dcmap:1 subprotocol="bfcp";max-time=60000;priority=512
a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp"
a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128
a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000
]]></artwork>
						</figure>
					</t>
					<t>
						<list style="hanging">
							<t>Note: label="foo%09bar";ordered=true;max-time=15000</sourcecode>
          <aside pn="section-5.1.1-7">
            <t indent="0" pn="section-5.1.1-7.1">Note: The last example (a=dcmap:4) shows a 'label' parameter value
         which
         that contains one non-printable nonprintable 'escaped-char' character
         (the tabulator character).</t>
						</list>
					</t>
					<t>Within
          </aside>
          <t indent="0" pn="section-5.1.1-8">Within an 'a=dcmap:' "a=dcmap:" attribute line's 'dcmap-opt' value value, only one
       'maxretr-opt' parameter or one 'maxtime-opt' parameter may be present.
       Both MUST NOT parameters <bcp14>MUST NOT</bcp14> be present.</t>
        </section>
        <section title="Dcmap-stream-id Parameter" anchor="dcmap-stream-id-param-definition">
					<t>The anchor="dcmap-stream-id-param-definition" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.2">
          <name slugifiedName="name-dcmap-stream-id-parameter">'dcmap-stream-id' Parameter</name>
          <t indent="0" pn="section-5.1.2-1">The 'dcmap-stream-id' parameter indicates the SCTP stream identifier
       within the SCTP association used to form the data channel.</t>
        </section>
        <section title="Label Parameter">
					<t>The numbered="true" removeInRFC="false" toc="include" pn="section-5.1.3">
          <name slugifiedName="name-label-parameter">'label' Parameter</name>
          <t indent="0" pn="section-5.1.3-1">The 'label' parameter indicates the name of the
       channel. It represents a label that can be used to distinguish,
       in the context of the WebRTC API <xref target="WebRtcAPI"/>, target="WebRtcAPI" format="default" sectionFormat="of" derivedContent="WebRtcAPI"/>,
       an RTCDataChannel object from other RTCDataChannel objects.
       This parameter maps to the 'Label' parameter defined in
       <xref target="I-D.ietf-rtcweb-data-protocol"/>. target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>.
       The 'label' parameter is optional. If it is not
       present, then its value defaults to the empty string.
          </t>
					<t>In
          <t indent="0" pn="section-5.1.3-2">In order to communicate with WEbRTC API the label attribute should:
       <list style="symbols">
							<t>Serialize WebRTC API, the 'label' parameter
          should
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1.3-3">
            <li pn="section-5.1.3-3.1">Serialize the WebRTC label as a UTF-8 string <xref target="RFC3629"/>.</t>
							<t>Treat target="RFC3629" format="default" sectionFormat="of" derivedContent="RFC3629"/>.</li>
            <li pn="section-5.1.3-3.2">Treat the UTF-8 serialization as a series of bytes</t>
							<t>For bytes.</li>
            <li pn="section-5.1.3-3.3">
              <t indent="0" pn="section-5.1.3-3.3.1">For each byte in the serialization:

								<list style="symbols">
									<t>If serialization,
              </t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1.3-3.3.2">
                <li pn="section-5.1.3-3.3.2.1">If the byte can be expressed as a `quoted-char`, 'quoted-char', do so</t>
									<t>Otherwise, so.</li>
                <li pn="section-5.1.3-3.3.2.2">Otherwise, express the byte as an `escaped-char`.</t>
								</list>
							</t>
						</list>
					</t>
					<t>Note: 'escaped-char'.</li>
              </ul>
            </li>
          </ul>
          <aside pn="section-5.1.3-4">
            <t indent="0" pn="section-5.1.3-4.1">Note: The empty string MAY can also be explicitly used as a 'label' value,
       such that 'label=""' is equivalent to the 'label' parameter not being
       present at all.
       <xref target="I-D.ietf-rtcweb-data-protocol"/> target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/> allows the DATA_CHANNEL_OPEN
       message's 'Label' value to be an empty string.</t>
          </aside>
        </section>
        <section title="Subprotocol Parameter" anchor="subprotocol-parameter">
					<t>The anchor="subprotocol-parameter" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.4">
          <name slugifiedName="name-subprotocol-parameter">'subprotocol' Parameter</name>
          <t indent="0" pn="section-5.1.4-1">The 'subprotocol' parameter indicates which protocol the
       client expects to exchange via the channel.
       This parameter maps to the 'Protocol' parameter defined in
       <xref target="I-D.ietf-rtcweb-data-protocol"/>.
       <xref target="IANA_subproto_ids"/> target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>.
       <xref target="IANA_subproto_ids" format="default" sectionFormat="of" derivedContent="Section 9.1"/> specifies how values for new subprotocol parameter
       values parameters are registered.
       'subprotocol' is an optional parameter.
       If the 'subprotocol' parameter is not present, then its value
       defaults to an empty string.</t>
					<t>
          <aside pn="section-5.1.4-2">
            <t indent="0" pn="section-5.1.4-2.1"> Note: The empty string MAY can also be
          explicitly used as a 'subprotocol' value,
       such that 'subprotocol=""' is equivalent to the 'subprotocol' parameter not being
       present at all. <xref target="I-D.ietf-rtcweb-data-protocol"/> target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/> allows the
       DATA_CHANNEL_OPEN message's 'Subprotocol' 'Protocol' value to be an empty string.
            </t>
          </aside>
        </section>
        <section title="Max-retr Parameter" anchor="max-retr-param-definition">
					<t>This anchor="max-retr-param-definition" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.5">
          <name slugifiedName="name-max-retr-parameter">'max-retr' Parameter</name>
          <t indent="0" pn="section-5.1.5-1">This parameter indicates that the data channel is partially reliable.
       The 'max-retr' parameter indicates the maximal number of times a user message will
       be retransmitted. The max-retr 'max-retr' parameter is optional. If
       the max-retr 'max-retr' parameter and the max-time 'max-time' parameter are not present, then reliable
       transmission is performed as specified in <xref target="RFC4960"/>. target="RFC4960" format="default" sectionFormat="of" derivedContent="RFC4960"/>.
       This parameter maps to the 'Number of RTX' parameter
       defined in <xref target="I-D.ietf-rtcweb-data-protocol"/>.</t>
				</section>
				<section title="Max-time Parameter">
					<t> target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>.</t>
        </section>
        <section numbered="true" removeInRFC="false" toc="include" pn="section-5.1.6">
          <name slugifiedName="name-max-time-parameter">'max-time' Parameter</name>
          <t indent="0" pn="section-5.1.6-1"> This parameter indicates that the data channel is partially reliable.
       A user message will no longer be transmitted or retransmitted after
       a specified life-time lifetime, given in milliseconds milliseconds, in the 'max-time'
       parameter. The life-time lifetime starts when providing the user message to the protocol stack.
 The max-time 'max-time' parameter is optional. If the max-retr 'max-retr' parameter and the max-time 'max-time' parameter are not present, then reliable
       transmission is performed as specified in <xref target="RFC4960"/>. target="RFC4960" format="default" sectionFormat="of" derivedContent="RFC4960"/>.
       This parameter maps to the 'Lifetime in ms' parameter
       defined in <xref target="I-D.ietf-rtcweb-data-protocol"/>.</t>
				</section>
				<section title="Ordered Parameter" anchor="ordered-param-description">
					<t>The target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>.</t>
        </section>
        <section anchor="ordered-param-description" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.7">
          <name slugifiedName="name-ordered-parameter">'ordered' Parameter</name>
          <t indent="0" pn="section-5.1.7-1">The 'ordered' parameter with value "true" indicates that the receiver will
       dispatch DATA chunks in the data channel to the upper layer
       while preserving the order. The ordered 'ordered' parameter is optional and
       takes two values: values -- "true" for ordered delivery and "false" for unordered delivery --
       with "true" as the default value.
       Any other value is ignored ignored, and the default "ordered=true" is assumed.
       In the absence of this parameter parameter, "ordered=true" is assumed.
       This parameter maps to
       the ordered or unordered data channel types as defined in
       <xref target="I-D.ietf-rtcweb-data-protocol"/>.</t>
				</section>
				<section title="Priority Parameter" anchor="priority-param-description">
					<t>The target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>.</t>
        </section>
        <section anchor="priority-param-description" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.8">
          <name slugifiedName="name-priority-parameter">'priority' Parameter</name>
          <t indent="0" pn="section-5.1.8-1">The 'priority' parameter indicates the data channel's priority
       relative to the  priorities of other data channels, which may
       additionally exist over the same SCTP association.
       The 'priority' parameter maps to the 'Priority' parameter defined in
       <xref target="I-D.ietf-rtcweb-data-protocol"/>. target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>.
       The 'priority' parameter is optional.
       In the absence of this parameter parameter, "priority=256" is assumed.
          </t>
        </section>
        <section title="DCMAP anchor="dcmap-mux-category" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.9">
          <name slugifiedName="name-dcmap-multiplexing-category">DCMAP Multiplexing Category" anchor="dcmap-mux-category">
					<t>The Category</name>
          <t indent="0" pn="section-5.1.9-1">The multiplexing category <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/> target="RFC8859" format="default" sectionFormat="of" derivedContent="RFC8859"/> of the "a=dcmap:" attribute is SPECIAL.
          </t>
					<t>As
          <t indent="0" pn="section-5.1.9-2">As the usage of multiple SCTP associations on top of a single DTLS
       association is outside the scope of <xref target="I-D.ietf-mmusic-sctp-sdp"/>, target="RFC8841" format="default" sectionFormat="of" derivedContent="RFC8841"/>,
       no "a=dcmap:" attribute multiplexing rules are specified for the UDP/DTLS/SCTP and
       TCP/DTLS/SCTP proto values.
       If future extensions of <xref target="I-D.ietf-mmusic-sctp-sdp"/> target="RFC8841" format="default" sectionFormat="of" derivedContent="RFC8841"/> define how to
       negotiate multiplexing of multiple SCTP associations on top of a single DTLS
       association,
       association or how to add multiple SCTP associations to one BUNDLE group, then
       multiplexing rules for the "a=dcmap:" attribute need to be
       defined as well, well -- for instance instance, in an extension of this SDP offer/answer based data channel
       negotiation specification.
          </t>
        </section>
      </section>
			<!-- subsec-sdp-attr-for-dc-par-neg -->
      <section title="SDP anchor="prot_att" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-sdp-dcsa-attribute">SDP DCSA Attribute" anchor="prot_att">
				<t>In Attribute</name>
        <t indent="0" pn="section-5.2-1">In the SDP media description, each data channel declaration MAY
        <bcp14>MAY</bcp14> also be followed by other media level SDP attributes, which are either specifically defined for or
      applied
        apply to the subprotocol in use. corresponding data channel and its subprotocol. Each of
        these attributes is represented by one new "a=dcsa:" attribute line, and
      it includes the contents of a media-level line
        that references another SDP attribute already defined for use with this (sub)protocol in another IETF document.
      Subprotocol specific data
        channel's subprotocol. Instructions for registering attributes MAY also be defined for exclusive use
        with a data channel transport, but MUST use the same syntax
      described here for other subprotocol related attributes.</t>
				<t>Each are given in <xref target="IANA-reg-data-channel-attribs" format="default" sectionFormat="of" derivedContent="Section 9.3"/>.</t>
        <t indent="0" pn="section-5.2-2">Each SDP attribute, attribute that is related to the subprotocol, subprotocol and that would normally
      be used to negotiate the subprotocol using the SDP offer/answer mechanism is replaced with
      an attribute of the form "a=dcsa:stream-id original-attribute", original‑attribute",
      where dcsa "dcsa" stands for "data channel subprotocol attribute",
      stream-id
      "stream-id" is the SCTP stream identifier assigned to this subprotocol
      instance, and original-attribute "original-attribute" represents the contents of the
      subprotocol related
      subprotocol-related attribute to be included.</t>
				<t>The
        <t indent="0" pn="section-5.2-3">The same syntax applies to any other SDP attribute required for
      negotiation of this instance of the subprotocol.</t>
				<t>The
        <t indent="0" pn="section-5.2-4">The detailed offer/answer procedures for the dcsa attribute are
        dependent on the associated sub-protocol. subprotocol. If no offer/answer
        procedures exist for the sub-protocol subprotocol when used outside of the dcsa
        attribute, no specification is needed for use with dcsa. The IANA
        (Internet Assigned Numbers Authority) registration procedures for the WebSocket "WebSocket Subprotocol Name Registry Registry" (<xref target="IANA_subproto_ids"/>) target="IANA_subproto_ids" format="default" sectionFormat="of" derivedContent="Section 9.1"/>) do not strictly require a specification of the offer/answer procedures for the sub-protocol subprotocol when used with dcsa. If the sub-protocol subprotocol has defined offer/answer procedures when used outside of dcsa, such a specification is encouraged to ensure interoperability. If the sub-protocol subprotocol has defined offer/answer procedures when used outside of dcsa, dcsa but no specification exists for the offer/answer procedures for the sub-protocol subprotocol when used with dcsa, implementations SHOULD <bcp14>SHOULD</bcp14> assume the use of the default values for all otherwise-negotiable and applicable sub-protocol subprotocol parameters.
</t>
        <section title="DCSA Syntax" anchor="dcsa-attribute">
					<t>
						<figure anchor="dcsa-attribute" numbered="true" removeInRFC="false" toc="include" pn="section-5.2.1">
          <name slugifiedName="name-dcsa-attribute-syntax">DCSA Attribute Syntax</name>
          <t indent="0" pn="section-5.2.1-1">"a=dcsa:" is a media-level attribute having the following definition and
ABNF (Augmented Backus-Naur Form) syntax <xref target="RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/>.
</t>
          <table anchor="dcsa-attrib" align="center" pn="table-2">
            <name slugifiedName="name-adcsa-attribute-definition">"a=dcsa:" Attribute Definition</name>
            <thead>
              <tr>
                <th colspan="2" align="center" rowspan="1">"a=dcsa:" Attribute</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" title="">
							<artwork align="left"><![CDATA[
Formal Syntax:

Name: dcsa

Value: dcsa-value

Usage Level: media

Charset Dependent: no

Syntax: colspan="1" rowspan="1">Name</td>
                <td align="left" colspan="1" rowspan="1">dcsa</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Value</td>
                <td align="left" colspan="1" rowspan="1">dcsa-value</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Usage Level</td>
                <td align="left" colspan="1" rowspan="1">media</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Charset Dependent</td>
                <td align="left" colspan="1" rowspan="1">No</td>
              </tr>
            </tbody>
          </table>
          <t indent="0" pn="section-5.2.1-3">Formal syntax:</t>
          <sourcecode name="abnf-2" type="abnf" markers="false" pn="section-5.2.1-4">
dcsa-value      = stream-id SP attribute
stream-id       = 1*5DIGIT
attribute       = <from-RFC4566>

Example: &lt;from RFC 8866&gt;</sourcecode>
          <t indent="0" pn="section-5.2.1-5">Example:</t>
          <sourcecode name="sdp-2" type="sdp" markers="false" pn="section-5.2.1-6">
a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp"

a=dcsa:2 accept-types:text/plain
]]></artwork>
						</figure>
					</t>
					<t>Note that the accept-types:text/plain</sourcecode>
          <t indent="0" pn="section-5.2.1-7">The reference to <xref target="I-D.ietf-mmusic-rfc4566bis"/> target="RFC8866" format="default" sectionFormat="of" derivedContent="RFC8866"/> defines where the
      attribute definition can be found;
      it does not provide any limitation limitations on support of attributes
      defined in other documents in accordance with this attribute
      definition. Note however that However, not all SDP attributes are suitable
      as a an "a=dcsa:" parameter. The registry of IANA SDP parameters contains
      the lists of IANA (Internet Assigned Numbers Authority)
      registered session IANA-registered session-level and media level media-level or
      media level only
      media-level-only SDP attributes.</t>
					<t>Thus attributes.
</t>
          <t indent="0" pn="section-5.2.1-8">Thus, in the example above, the original attribute line
      "a=accept-types:text/plain"
      "a=accept‑types:text/plain" is represented by the attribute line
      "a=dcsa:2 accept-types:text/plain", which specifies that this
      instance of the MSRP subprotocol being transported on the SCTP association using
      the data channel with stream id 2 accepts
      plain text
      plaintext files.</t>
					<t>As
          <t indent="0" pn="section-5.2.1-9">As opposed to the data channel "a=dcmap:" attribute parameters,
      these parameters
      are subject to offer/answer negotiation negotiation, following the procedures
      defined in the subprotocol specific subprotocol-specific documents.</t>
					<t>It
          <t indent="0" pn="section-5.2.1-10">It is assumed that in general the usages of subprotocol related media
      level subprotocol-related
      media-level attributes are independent from the subprotocol's transport protocol.
      Such transport protocol independent subprotocol related transport-protocol-independent subprotocol-related attributes are
      used in the same way as defined in the original subprotocol specification,
      also if the subprotocol is transported over a data channel and if the
      attribute is correspondingly embedded in a "a=dcsa" an "a=dcsa:" attribute.
          </t>
					<t>There
          <t indent="0" pn="section-5.2.1-11">There may be cases, cases where the usage of a subprotocol related media level subprotocol-related
      media-level
      attribute depends on the subprotocol's transport protocol.
      In such cases cases, the subprotocol related subprotocol-related usage of the attribute is expected to be
      described for the data channel transport. A data channel specific data-channel-specific usage of a
      subprotocol attribute is expected to be specified in the same document that
      registers the subprotocol's identifier for data channel usage as described in
      <xref target="IANA_subproto_ids"/>.
      </t>
					<t>SDP attributes that are only defined for use at the
   dcsa usage level, SHALL use the dcsa usage level when registering the
   attribute.  If existing media attributes are used in a datachannel
   subprotocol specific way, then a new dcsa usage level
   MUST be defined for the existing media attribute.  Where the SDP
  attribute is applicable to a particular subprotocol/s this SHALL also
   be registered by indicating the applicable subprotocol identifiers
   (see /<xref target="I-D.ietf-mmusic-rfc4566bis"/> section-8.5) along with the dcsa usage level. target="IANA_subproto_ids" format="default" sectionFormat="of" derivedContent="Section 9.1"/>.
          </t>
        </section>
        <section title="DCSA anchor="dcsa-mux-category" numbered="true" removeInRFC="false" toc="include" pn="section-5.2.2">
          <name slugifiedName="name-dcsa-multiplexing-category">DCSA Multiplexing Category" anchor="dcsa-mux-category">
					<t>The Category</name>
          <t indent="0" pn="section-5.2.2-1">The multiplexing category of the "a=dcsa:" attribute is SPECIAL.
          </t>
					<t>As
          <t indent="0" pn="section-5.2.2-2">As the usage of multiple SCTP associations on top of a single DTLS
       association is outside the scope of <xref target="I-D.ietf-mmusic-sctp-sdp"/>, target="RFC8841" format="default" sectionFormat="of" derivedContent="RFC8841"/>,
       no "a=dcsa:" attribute multiplexing rules are specified for the UDP/DTLS/SCTP and
       TCP/DTLS/SCTP
       TCP⁠/DTLS⁠/SCTP proto values.
       If future extensions of <xref target="I-D.ietf-mmusic-sctp-sdp"/> target="RFC8841" format="default" sectionFormat="of" derivedContent="RFC8841"/> define how to
       negotiate multiplexing of multiple SCTP associations on top of a single DTLS
       association,
       association or how to add multiple SCTP associations to one BUNDLE group, then
       multiplexing rules for the "a=dcsa:" attribute need to be
       defined as well, well -- for instance instance, in an extension of this SDP based data channel
       negotiation specification.
          </t>
        </section>
      </section>
			<!-- prot_att -->
		</section>
		<!-- sdp_sync -->
    </section>
    <section title="SDP anchor="section_procedures" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-sdp-offer-answer-procedures">SDP Offer/Answer Procedures" anchor="section_procedures">
			<t>This Procedures</name>
      <t indent="0" pn="section-6-1">This section defines how data channels can be negotiated using the SDP
       offer/answer mechanism. A given media description can describe multiple
       data channels (each represented by a separate SDP dcmap attribute) that
       can be created, modified modified, and closed using different offer/answer exchanges.
       The procedures in this section apply for a given data channel.
</t>
			<t>The
      <t indent="0" pn="section-6-2">The generic offer/answer procedures for negotiating the SCTP association used to realize data channels are defined in <xref target="I-D.ietf-mmusic-sctp-sdp"/>. target="RFC8841" format="default" sectionFormat="of" derivedContent="RFC8841"/>. This section only defines the data channel specific data-channel-specific procedures.</t>
			<t> “Initial offer”
      <t indent="0" pn="section-6-3"> "Initial offer" refers to the offer in which a data channel is
      opened. It can be either the initial offer, offer or a subsequent offer, offer of the associated SDP session.</t>
			<t>The
      <t indent="0" pn="section-6-4">The detailed offer/answer procedures for the dcsa attribute are dependent on the associated sub-protocol subprotocol; see <xref target="prot_att"/>. target="prot_att" format="default" sectionFormat="of" derivedContent="Section 5.2"/>.
</t>
      <section title="Managing anchor="id_mgmt" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-managing-stream-identifiers">Managing Stream Identifiers" anchor="id_mngt">
				<t> Identifiers</name>
        <t indent="0" pn="section-6.1-1">
        In order to avoid SCTP Stream identifier collisions, in alignment with
        <xref target="I-D.ietf-rtcweb-data-protocol"/>, target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>, the endpoint acting as a DTLS client (for
the SCTP association used to realize data channels) MUST <bcp14>MUST</bcp14> use even identifier values,
and the endpoint acting as a DTLS server MUST <bcp14>MUST</bcp14> use odd identifier values. </t>
				<t>SCTP
        <t indent="0" pn="section-6.1-2">SCTP stream identifiers associated with data channels that have been negotiated using DCEP MUST NOT <bcp14>MUST NOT</bcp14> be included in SDP offers and answers.
        </t>
      </section>
			<!-- id_mngt -->
      <section title="Negotiating anchor="param_negotiation" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-negotiating-data-channel-pa">Negotiating Data Channel Parameters" anchor="param_negotiation">
				<t> Parameters</name>
        <t indent="0" pn="section-6.2-1">
   The data channel types defined in <xref target="I-D.ietf-rtcweb-data-protocol"/> target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/> are
   mapped to the dcmap SDP attribute parameters in the following manner manner, where "ordered=true" is the default and may be omitted:

        </t>
				<t>
					<figure align="left" title="">
						<artwork align="left"><![CDATA[
        <sourcecode name="data-channel-items" type="sdp" markers="false" pn="section-6.2-2">
DATA_CHANNEL_RELIABLE
   ordered=true

DATA_CHANNEL_RELIABLE_UNORDERED
   ordered=false

DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT
      ordered=true;max-retr=<number
   ordered=true;max-retr=&lt;number of retransmissions> retransmissions&gt;

DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED
      ordered=false;max-retr=<number
   ordered=false;max-retr=&lt;number of retransmissions> retransmissions&gt;

DATA_CHANNEL_PARTIAL_RELIABLE_TIMED
      ordered=true;max-time=<lifetime
   ordered=true;max-time=&lt;lifetime in milliseconds> milliseconds&gt;

DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED
      ordered=false;max-time=<lifetime
   ordered=false;max-time=&lt;lifetime in milliseconds>
]]></artwork>
					</figure>
				</t>
				<t> milliseconds&gt;</sourcecode>
        <t indent="0" pn="section-6.2-3">
  By definition max-retr definition, 'max-retr' and max-time 'max-time' are mutually exclusive,
   so both MUST NOT <bcp14>MUST NOT</bcp14> be present in the "a=dcmap:" attribute
   line.  If an SDP offer contains both of these parameters parameters, then the
   receiver of such an SDP offer MUST <bcp14>MUST</bcp14> reject the SDP offer.  If an SDP
   answer contains both of these parameters parameters, then the offerer MUST <bcp14>MUST</bcp14> treat
   the associated SDP offer/answer as failed.  </t>
      </section>
			<!-- ="Negotiating Data Channel Parameters" -->
      <section title="Generating anchor="opendc" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-generating-the-initial-offe">Generating the Initial Offer for A a Data Channel" anchor="opendc">
				<t>When Channel</name>
        <t indent="0" pn="section-6.3-1">When an offerer sends an initial offer, in order to negotiate an SCTP stream for a data channel, the offerer:

       <list style="symbols">
						<t>SHALL offerer

        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-2">
          <li pn="section-6.3-2.1">
            <bcp14>SHALL</bcp14> include an SDP dcmap attribute (<xref target="sdp_synt"/>
          (Sections <xref target="subsec-sdp-attr-for-dc-par-neg" format="counter" sectionFormat="of" derivedContent="5.1"/> and  <xref target="param_negotiation"/>) target="param_negotiation" format="counter" sectionFormat="of" derivedContent="6.2"/>) associated with the data channel in the “m=” "m=" section representing the SCTP association used to realize the data channel; channel, and
       </t>
						<t>MAY
       </li>
          <li pn="section-6.3-2.2">
            <bcp14>MAY</bcp14> include one or more SDP dcsa attributes (<xref target="prot_att"/>) target="prot_att" format="default" sectionFormat="of" derivedContent="Section 5.2"/>) associated with the
      data channel. The value of the stream-id 'stream-id' part of each attribute SHALL <bcp14>SHALL</bcp14> match the dcmap-stream-id 'dcmap-stream-id' value of the dcmap attribute.
       </t>
					</list>
				</t>
       </li>
        </ul>
      </section>
      <section title="Generating SDP Answer">
				<t>When numbered="true" removeInRFC="false" toc="include" pn="section-6.4">
        <name slugifiedName="name-generating-the-sdp-answer">Generating the SDP Answer</name>
        <t indent="0" pn="section-6.4-1">When an answerer receives an offer that includes an “m=" "m=" section
        for an SCTP association, that the offer describes an SCTP stream for a data channel, if the answerer accepts the data channel it:

      <list style="symbols">
						<t>SHALL channel, it
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.4-2">
          <li pn="section-6.4-2.1">
            <bcp14>SHALL</bcp14> include an SDP dcmap attribute (<xref target="sdp_synt"/>
          (Sections <xref target="subsec-sdp-attr-for-dc-par-neg" format="counter" sectionFormat="of" derivedContent="5.1"/> and  <xref target="param_negotiation"/>) target="param_negotiation" format="counter" sectionFormat="of" derivedContent="6.2"/>)
      associated
with the data channel in the "m=" section representing the SCTP association used
to realize the data channel. The value of the dcmap-stream-id, max-retr 'dcmap-stream-id', 'max-retr', and max-time 'max-time'
values of the dcmap attribute SHALL <bcp14>SHALL</bcp14> be identical to the value used for the data channel
in the offer; offer, and

</t>
						<t>MAY
</li>
          <li pn="section-6.4-2.2">
            <bcp14>MAY</bcp14> include one or more SDP dcsa attributes (<xref target="prot_att"/>) target="prot_att" format="default" sectionFormat="of" derivedContent="Section 5.2"/>) associated with the
      data channel.

</t>
					</list>
				</t>

</li>
        </ul>
      </section>
      <section title="Offerer numbered="true" removeInRFC="false" toc="include" pn="section-6.5">
        <name slugifiedName="name-offerer-processing-of-the-s">Offerer Processing of the SDP Answer">
				<t>An Answer</name>
        <t indent="0" pn="section-6.5-1">An offerer receiving an SDP answer performs the following:

      <list style="symbols">
						<t>SHALL

        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-2">
          <li pn="section-6.5-2.1">It <bcp14>SHALL</bcp14> close any created data channels as described in
       <xref target="close-dc"/> target="close-dc" format="default" sectionFormat="of" derivedContent="Section 6.6.1"/>
       for which the expected "a=dcmap:" attributes are not
       present in the SDP answer. If the SDP answer has no "a=dcmap" attribute "a=dcmap:" attributes, either the peer does not support "a=dcmap:" attributes or
            it rejected all the data channels. In either case case, the offerer
            closes all the SDP offered data channels offered by SDP that were open at the time of the offer.
            The DTLS association and SCTP association will still be setup. set up. At this
   point
   point, the offerer may use DCEP negotiation <xref target="I-D.ietf-rtcweb-data-protocol"/> target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/> to open data channels</t>
					</list>
				</t>
				<t>Each channels.</li>
        </ul>
        <t indent="0" pn="section-6.5-3">Each agent application MUST <bcp14>MUST</bcp14> wait to send data until it has
     confirmation that the data channel at the peer is instantiated.
     For WebRTC, this is when both data channel stacks have channel
     parameters instantiated. This occurs:

     <list style="symbols">
						<t>At instantiated and occurs as follows:

        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-4">
          <li pn="section-6.5-4.1">At both peers when a data channel is created without a previously
      established SCTP association, as soon as the SCTP association
      is successfully established.</t>
						<t>At established.</li>
          <li pn="section-6.5-4.2">At the agent receiving an SDP offer for which there is an
      established SCTP association, as soon as it creates the
      negotiated data channel based on information
      signaled in the SDP offer.</t>
						<t>At offer.</li>
          <li pn="section-6.5-4.3">At the agent sending an SDP offer to create a new data channel for which there is an established SCTP
      association, when it receives the SDP answer confirming acceptance
      of the data channel or when it begins to receive data on the
      data channel from the peer, whichever occurs first.</t>
					</list>
				</t> first.</li>
        </ul>
      </section>
			<!-- opendc -->
      <section title="Modifying the Session">
				<t>When numbered="true" removeInRFC="false" toc="include" pn="section-6.6">
        <name slugifiedName="name-modifying-the-session">Modifying the Session</name>
        <t indent="0" pn="section-6.6-1">When an offer offerer sends a subsequent offer, offer that includes information for
   a previously negotiated data channel, unless the offerer intends to
   close the data channel (<xref target="close-dc"/>), target="close-dc" format="default" sectionFormat="of" derivedContent="Section 6.6.1"/>), the offerer SHALL <bcp14>SHALL</bcp14> include the
   previously negotiated SDP attributes and attribute values associated with the
   data channel. The answerer may reject the offer. The means for rejecting an offer are dependent on
   the higher layer higher-layer protocol.  The offer/answer exchange is atomic; if the answer is rejected, the session reverts to the state prior to the
   offer <xref target="RFC3264"/>. target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/>.

        </t>
        <section title="Closing anchor="close-dc" numbered="true" removeInRFC="false" toc="include" pn="section-6.6.1">
          <name slugifiedName="name-closing-a-data-channel">Closing a Data Channel" anchor="close-dc">
					<t>In Channel</name>
          <t indent="0" pn="section-6.6.1-1">In order to close a data channel, the endpoint that wants to
          close
   SHALL send the data channel
   <bcp14>SHALL</bcp14> send an SCTP SSN reset Reset message <xref target="RFC6525"/>, target="RFC6525" format="default" sectionFormat="of" derivedContent="RFC6525"/>, following the procedures procedure in section 6.7 of <xref target="I-D.ietf-rtcweb-data-channel"/>. target="RFC8831" sectionFormat="of" section="6.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8831#section-6.7" derivedContent="RFC8831"/>.
In addition, if the closed data channel was negotiated using the offer/answer
mechanism <xref target="opendc"/>, (<xref target="opendc" format="default" sectionFormat="of" derivedContent="Section 6.3"/>), the endpoint that closed the data channel SHALL
<bcp14>SHALL</bcp14> send a subsequent offer in which it either: does one of the following:
</t>
					<t>
						<list style="symbols">
							<t>
   removes
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.6.1-2">
            <li pn="section-6.6.1-2.1">Removes the SDP dcmap attribute and SDP dcsa attributes
            associated with the closed data channel. Once the endpoint
            receives a successful answer, the SCTP stream identifier value can
            later be used for a new data channel (negotiated using DCTP either SCTP
            or using the offer/answer mechanism); or</t>
							<t>after mechanism), or
</li>
            <li pn="section-6.6.1-2.2">After a reset has been performed re-uses performed, reuses the SCTP stream used for the closed data channel for a new data channel, using following the procedures procedure in <xref target="opendc"/>. target="opendc" format="default" sectionFormat="of" derivedContent="Section 6.3"/>. The offerer SHALL <bcp14>SHALL</bcp14> use a different SDP dcmap attribute value for the data channel using the same SCTP stream.

	</t>
						</list>
					</t>
        </li>
          </ul>
        </section>
				<!-- Closing a Data Channel -->
      </section>
      <section title="Various anchor="various_SDP_OA_considerations" numbered="true" removeInRFC="false" toc="include" pn="section-6.7">
        <name slugifiedName="name-various-sdp-offer-answer-co">Various SDP Offer/Answer Considerations" anchor="various_SDP_OA_considerations">
				<t>
					<list>
						<t>An Considerations</name>
        <t indent="0" pn="section-6.7-1">An SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:" attributes.
        <list style="symbols">
								<t>This attributes:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.7-2">
          <li pn="section-6.7-2.1">This is considered an error case. In this case case, the receiver of such an
            SDP offer or answer MUST <bcp14>MUST</bcp14> discard this the "a=dcsa:" attributes.
         </t>
							</list>
						</t>
						<t>SDP
         </li>
        </ul>
        <t indent="0" pn="section-6.7-3">An SDP offer or answer has an "a=dcsa" attribute, "a=dcsa:" attribute whose subprotocol attribute
       is unknown.
        <list style="symbols">
								<t>The unknown:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.7-4">
          <li pn="section-6.7-4.1">The receiver of such an SDP offer or answer SHOULD <bcp14>SHOULD</bcp14> ignore this
         entire "a=dcsa" "a=dcsa:" attribute line.
         </t>
							</list>
						</t>
						<t>SDP
         </li>
        </ul>
        <t indent="0" pn="section-6.7-5">An SDP offer or answer has an "a=dcsa" attribute, "a=dcsa:" attribute whose subprotocol attribute
       is known, known but whose subprotocol attribute semantic is not known for the
       data channel transport case.
        <list style="symbols">
								<t>The case:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.7-6">
          <li pn="section-6.7-6.1">The receiver of such an SDP offer or answer SHOULD <bcp14>SHOULD</bcp14> ignore this
         entire "a=dcsa" "a=dcsa:" attribute line.
         </t>
							</list>
						</t>
					</list>
				</t>
         </li>
        </ul>
      </section>
			<!-- various SDP offer/answer ... -->
    </section>
		<!-- Procedures -->
    <section title="Examples" anchor="examples">
			<figure align="left" title="Example 1" anchor="example1">
				<artwork align="left"><![CDATA[
SDP offer:

  m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
  c=IN IP6 2001:db8::3
  a=max-message-size:100000
  a=sctp-port:5000
  a=setup:actpass
  a=fingerprint:SHA-1 \
      4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
  a=tls-id:abc3de65cddef001be82
  a=dcmap:0 subprotocol="bfcp";label="bfcp"

SDP answer:

  m=application 10002 UDP/DTLS/SCTP webrtc-datachannel
  c=IN IP6 2001:db8::1
  a=max-message-size:100000
  a=sctp-port:5002
  a=setup:passive
  a=fingerprint:SHA-1 \
      5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
  a=tls-id:dcb3ae65cddef0532d42
]]></artwork>
			</figure>
			<t>In the anchor="examples" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-examples">Examples</name>
      <t indent="0" pn="section-7-1"><xref target="example1" format="default" sectionFormat="of" derivedContent="Figure 1"/> shows an example in <xref target="example1"/> of an SDP offer and answer
      where the SDP answerer rejected rejects the data channel
   with stream id 0 either for explicit reasons or because it does not
   understand the "a=dcmap:" attribute.
   As a result result, the offerer will close the data channel created with the
   SDP offer/answer negotiation option.
   The SCTP association will still be setup set up over DTLS.
   At this point point, the offerer or the answerer may use DCEP negotiation to open data
   channels.</t>
      <figure anchor="example1" align="left" title="Example 2" anchor="example2">
				<artwork align="left"><![CDATA[
SDP offer: suppress-title="false" pn="figure-1">
        <name slugifiedName="name-example-1">Example 1</name>
        <sourcecode name="example-1-sdp-offer" type="sdp" markers="false" pn="section-7-2.1">
  m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
  c=IN IP4 192.0.2.1 IP6 2001:db8::3
  a=max-message-size:100000
  a=sctp-port:5000
  a=setup:actpass
  a=fingerprint:SHA-1 \
      4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
  a=tls-id:abc3de65cddef001be82
  a=dcmap:0 subprotocol="bfcp";label="bfcp"
  a=dcmap:2 subprotocol="msrp";label="msrp"
  a=dcsa:2 accept-types:message/cpim text/plain
  a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc

SDP answer: subprotocol="bfcp";label="bfcp"</sourcecode>
        <sourcecode name="example-1-sdp-answer" type="sdp" markers="false" pn="section-7-2.2">
  m=application 10002 UDP/DTLS/SCTP webrtc-datachannel
  c=IN IP4 192.0.2.2 IP6 2001:db8::1
  a=max-message-size:100000
  a=sctp-port:5002
  a=setup:passive
  a=fingerprint:SHA-1 \
      5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
  a=tls-id:dcb3ae65cddef0532d42
  a=dcmap:2 subprotocol="msrp";label="msrp"
  a=dcsa:2 accept-types:message/cpim text/plain
  a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc
]]></artwork>
  a=tls-id:dcb3ae65cddef0532d42</sourcecode>
      </figure>
			<t>In the
      <t indent="0" pn="section-7-3"><xref target="example2" format="default" sectionFormat="of" derivedContent="Figure 2"/> shows an example in <xref target="example2"/> of an SDP offer and answer
      where the SDP offer contains data channels for BFCP
   (Binary Floor Control Protocol) and
   MSRP subprotocols. The SDP answer rejected rejects BFCP and accepted accepts MSRP.
   So, the offerer closes the data channel for BFCP BFCP, and both the offerer
   and the answerer may start using the MSRP data channel
   (after the SCTP association is set up). set up).
   The data channel with stream id 0 is free and can be used for future
   DCEP or SDP offer/answer negotiation.</t>
			<t>Continuing the example in <xref target="example2"/>.</t>
      <figure anchor="example2" align="left" title="Example 3" anchor="example3">
				<artwork align="left"><![CDATA[
Subsequent SDP offer: suppress-title="false" pn="figure-2">
        <name slugifiedName="name-example-2">Example 2</name>
        <sourcecode name="example-2-sdp-offer" type="sdp" markers="false" pn="section-7-4.1">
  m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
  c=IN IP4 192.0.2.1
  a=max-message-size:100000
  a=sctp-port:5000
  a=setup:actpass
  a=fingerprint:SHA-1 \
      4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
  a=tls-id:abc3de65cddef001be82
  a=dcmap:4
  a=dcmap:0 subprotocol="bfcp";label="bfcp"
  a=dcmap:2 subprotocol="msrp";label="msrp"
  a=dcsa:4
  a=dcsa:2 accept-types:message/cpim text/plain
  a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc

Subsequent SDP answer:
  a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc</sourcecode>
        <sourcecode name="example-2-sdp-answer" type="sdp" markers="false" pn="section-7-4.2">
  m=application 10002 UDP/DTLS/SCTP webrtc-datachannel
  c=IN IP4 192.0.2.2
  a=max-message-size:100000
  a=sctp-port:5002
  a=setup:passive
  a=fingerprint:SHA-1 \
      5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
  a=tls-id:dcb3ae65cddef0532d42
  a=dcmap:4
  a=dcmap:2 subprotocol="msrp";label="msrp"
  a=dcsa:4
  a=dcsa:2 accept-types:message/cpim text/plain
  a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc
]]></artwork>
  a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc</sourcecode>
      </figure>
			<t>The
      <t indent="0" pn="section-7-5">The example in <xref target="example3"/> target="example3" format="default" sectionFormat="of" derivedContent="Figure 3"/> is a continuation of the example in <xref target="example2"/>. target="example2" format="default" sectionFormat="of" derivedContent="Figure 2"/>.
   The SDP offerer now removes the MSRP data channel with stream id 2, 2
   but opens a new MSRP data channel with stream id 4.
   The answerer accepts the entire offer.
   As a result result, the offerer closes the earlier previously negotiated MSRP related MSRP-related data channel channel,
   and both the offerer and the answerer may start using new the MSRP related new MSRP-related data
      channel.</t>
      <figure anchor="example3" align="left" suppress-title="false" pn="figure-3">
        <name slugifiedName="name-example-3">Example 3</name>
        <sourcecode name="example-3-sdp-offer" type="sdp" markers="false" pn="section-7-6.1">
  m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
  c=IN IP4 192.0.2.1
  a=max-message-size:100000
  a=sctp-port:5000
  a=setup:actpass
  a=fingerprint:SHA-1 \
      4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
  a=tls-id:abc3de65cddef001be82
  a=dcmap:4 subprotocol="msrp";label="msrp"
  a=dcsa:4 accept-types:message/cpim text/plain
  a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc</sourcecode>
        <sourcecode name="example-3-sdp-answer" type="sdp" markers="false" pn="section-7-6.2">
  m=application 10002 UDP/DTLS/SCTP webrtc-datachannel
  c=IN IP4 192.0.2.2
  a=max-message-size:100000
  a=sctp-port:5002
  a=setup:passive
  a=fingerprint:SHA-1 \
      5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
  a=tls-id:dcb3ae65cddef0532d42
  a=dcmap:4 subprotocol="msrp";label="msrp"
  a=dcsa:4 accept-types:message/cpim text/plain
  a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc</sourcecode>
      </figure>
    </section>
		<!-- Examples -->
		<section title="Security Considerations" anchor="sec-cons">
			<t>This
    <section anchor="sec-cons" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">This document specifies new SDP attributes used in the negotiation of the DATA data channel parameters. </t>
			<t>
      <t indent="0" pn="section-8-2">
These parameter parameters are negotiated as part of opening a an SCTP channel over DTLS as specified in <xref target="I-D.ietf-mmusic-sctp-sdp"/>. target="RFC8841" format="default" sectionFormat="of" derivedContent="RFC8841"/>. Each
subprotocol may come with it’s its own security considerations that need to be documented as part of the subprotocol definition.
Otherwise
Otherwise, this document does not add any security considerations to the ones those specified in <xref target="I-D.ietf-mmusic-sctp-sdp"/>
			</t>
			<t>Error target="RFC8841" format="default" sectionFormat="of" derivedContent="RFC8841"/>.
      </t>
      <t indent="0" pn="section-8-3">Error cases like such as the use of unknown parameter values or violation violations
      of the odd/even rule MUST (<xref target="id_mgmt" format="default" sectionFormat="of" derivedContent="Section 6.1"/>) <bcp14>MUST</bcp14>
   be handled by closing the corresponding Data Channel.</t> data channel.</t>
    </section>
    <section title="IANA Considerations" anchor="IANA">
			<section title="Subprotocol Identifiers" anchor="IANA_subproto_ids">
				<t>Registration anchor="IANA" numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="IANA_subproto_ids" numbered="true" removeInRFC="false" toc="include" pn="section-9.1">
        <name slugifiedName="name-subprotocol-identifiers">Subprotocol Identifiers</name>
        <t indent="0" pn="section-9.1-1">Registration of new subprotocol identifiers is performed using the existing IANA
    "WebSocket Subprotocol Name Registry" table.</t>
				<t>The
        <t indent="0" pn="section-9.1-2">The following text should be has been added following below the title of the table.</t>
				<t>"This
        <t indent="0" pn="section-9.1-3">"This table also includes subprotocol identifiers specified for usage within a
    WebRTC data channel."</t>
				<t>The following reference should be
        <t indent="0" pn="section-9.1-4">This document (RFC 8864) has been added to under the heading reference:
    "RFC XXXX".</t>
				<t>This "Reference" list for
        the registry.</t>
        <t indent="0" pn="section-9.1-5">This document assigns no new values to this table.</t>
				<t>A
        <t indent="0" pn="section-9.1-6">A subprotocol may simultaneously be defined for data channel transport
    and for Websocket WebSocket transport.
    In such a case case, the "Subprotocol Definition" and "Reference" cells in the
    subprotocol's row of the IANA "WebSocket Subprotocol Name Registry" table should
    contain two entries.
    One entry in each of these cells should refer to the Websocket related WebSocket-related
    subprotocol specification, and the other entry should refer to the data
    channel related
    data-channel-related subprotocol specification.
        </t>
				<t>NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC.</t>
      </section>
      <section title="New SDP Attributes">
				<section title="dcmap" anchor="IANA-reg-dcmap">
					<t>NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC.</t>
					<t>This numbered="true" removeInRFC="false" toc="include" pn="section-9.2">
        <name slugifiedName="name-new-sdp-attributes">New SDP Attributes</name>
        <section anchor="IANA-reg-dcmap" numbered="true" removeInRFC="false" toc="include" pn="section-9.2.1">
          <name slugifiedName="name-dcmap">dcmap</name>
          <t indent="0" pn="section-9.2.1-1">This document defines a new SDP media-level attribute "a=dcmap:" attribute, "a=dcmap:", as follows:
          </t>
					<texttable title="">
						<ttcol align="left" width="35%"/>
						<ttcol align="left" width="65%"/>
						<c>Contact name:</c>
						<c>IESG</c>
						<c>Contact email:</c>
						<c>iesg@ietf.org</c>
						<c>Attribute name:</c>
						<c>dcmap</c>
						<c>Attribute syntax:</c>
						<c>As per <xref target="dcmap-attr-definition"/>
						</c>
						<c>Attribute semantics:</c>
						<c>As per <xref target="dcmap-attr-definition"/>
						</c>
						<c>Usage level:</c>
						<c>media</c>
						<c>Charset dependent:</c>
						<c>No</c>
						<c>Purpose:</c>
						<c>Define data channel specific parameters</c>
						<c>Appropriate values:</c>
						<c>As
          <table anchor="dcmap-iana" align="center" pn="table-3">
            <name slugifiedName="name-new-adcmap-attribute">New "a=dcmap:" Attribute</name>
            <thead>
              <tr>
                <th colspan="2" align="center" rowspan="1">"a=dcmap:"</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">Contact name</td>
                <td align="left" colspan="1" rowspan="1">IESG</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Contact email</td>
                <td align="left" colspan="1" rowspan="1">iesg@ietf.org</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Attribute name</td>
                <td align="left" colspan="1" rowspan="1">dcmap</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Attribute syntax</td>
                <td align="left" colspan="1" rowspan="1">As per <xref target="dcmap-attr-definition" format="default" sectionFormat="of" derivedContent="Section 5.1.1"/>
                </td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Attribute semantics</td>
                <td align="left" colspan="1" rowspan="1">As per <xref target="dcmap-attr-definition" format="default" sectionFormat="of" derivedContent="Section 5.1.1"/>
                </td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Usage level</td>
                <td align="left" colspan="1" rowspan="1">media</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Charset dependent</td>
                <td align="left" colspan="1" rowspan="1">No</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Purpose</td>
                <td align="left" colspan="1" rowspan="1">To define data-channel-specific parameters</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Appropriate values</td>
                <td align="left" colspan="1" rowspan="1">As per <xref target="dcmap-attr-definition"/>
						</c>
						<c>O/A procedures:</c>
						<c>As target="dcmap-attr-definition" format="default" sectionFormat="of" derivedContent="Section 5.1.1"/>
                </td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">O/A procedures</td>
                <td align="left" colspan="1" rowspan="1">SDP offer/answer procedures as per <xref target="section_procedures"/>
						</c>
						<c>Mux category:</c>
						<c>SPECIAL. target="section_procedures" format="default" sectionFormat="of" derivedContent="Section 6"/>
                </td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Mux category</td>
                <td align="left" colspan="1" rowspan="1">SPECIAL. See <xref target="dcmap-mux-category"/>
						</c>
						<c>Reference:</c>
						<c>RFCXXXX</c>
					</texttable>
				</section>
				<section title="dcsa" anchor="IANA-reg-dcsa">
					<t>NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC.</t>
					<t>This target="dcmap-mux-category" format="default" sectionFormat="of" derivedContent="Section 5.1.9"/>
                </td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Reference</td>
                <td align="left" colspan="1" rowspan="1">RFC 8864</td>
              </tr>
            </tbody>
          </table>
        </section>
        <section anchor="IANA-reg-dcsa" numbered="true" removeInRFC="false" toc="include" pn="section-9.2.2">
          <name slugifiedName="name-dcsa">dcsa</name>
          <t indent="0" pn="section-9.2.2-1">This document defines a new SDP media-level attribute "a=dcsa:" attribute, "a=dcsa:", as follows:
          </t>
					<texttable title="">
						<ttcol align="left" width="35%"/>
						<ttcol align="left" width="65%"/>
						<c>Contact name:</c>
						<c>IESG</c>
						<c>Contact email:</c>
						<c>iesg@ietf.org</c>
						<c>Attribute name:</c>
						<c>dcsa</c>
						<c>Attribute syntax:</c>
						<c>As
          <table anchor="dcsa-iana" align="center" pn="table-4">
            <name slugifiedName="name-new-adcsa-attribute">New "a=dcsa:" Attribute</name>
            <thead>
              <tr>
                <th colspan="2" align="center" rowspan="1">"a=dcsa:"</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">Contact name</td>
                <td align="left" colspan="1" rowspan="1">IESG</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Contact email</td>
                <td align="left" colspan="1" rowspan="1">iesg@ietf.org</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Attribute name</td>
                <td align="left" colspan="1" rowspan="1">dcsa</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Attribute syntax</td>
                <td align="left" colspan="1" rowspan="1">As per <xref target="dcsa-attribute"/>
						</c>
						<c>Attribute semantics:</c>
						<c>As target="dcsa-attribute" format="default" sectionFormat="of" derivedContent="Section 5.2.1"/>
                </td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Attribute semantics</td>
                <td align="left" colspan="1" rowspan="1">As per <xref target="dcsa-attribute"/>
						</c>
						<c>Usage level:</c>
						<c>media</c>
						<c>Charset dependent:</c>
						<c>No</c>
						<c>Purpose:</c>
						<c>Define target="dcsa-attribute" format="default" sectionFormat="of" derivedContent="Section 5.2.1"/>
                </td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Usage level</td>
                <td align="left" colspan="1" rowspan="1">media</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Charset dependent</td>
                <td align="left" colspan="1" rowspan="1">No</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Purpose</td>
                <td align="left" colspan="1" rowspan="1">To define attributes that are specific to data channel subprotocol specific attributes</c>
						<c>Appropriate values:</c>
						<c>As subprotocols</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Appropriate values</td>
                <td align="left" colspan="1" rowspan="1">As per <xref target="dcsa-attribute"/>
						</c>
						<c>O/A procedures:</c>
						<c>As target="dcsa-attribute" format="default" sectionFormat="of" derivedContent="Section 5.2.1"/>
                </td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">O/A procedures</td>
                <td align="left" colspan="1" rowspan="1">SDP offer/answer procedures as per <xref target="section_procedures"/>
						</c>
						<c>Mux category:</c>
						<c>SPECIAL. target="section_procedures" format="default" sectionFormat="of" derivedContent="Section 6"/>
                </td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Mux category</td>
                <td align="left" colspan="1" rowspan="1">SPECIAL. See <xref target="dcsa-mux-category"/>
						</c>
						<c>Reference:</c>
						<c>RFCXXXX</c>
					</texttable>
				</section>
			</section> target="dcsa-mux-category" format="default" sectionFormat="of" derivedContent="Section 5.2.2"/>
                </td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Reference</td>
                <td align="left" colspan="1" rowspan="1">RFC 8864</td>
              </tr>
            </tbody>
          </table>
        </section>
		<section title="Contributors">
			<t>Juergen Stoetzer-Bradler co-authored this document.</t>
      </section>
      <section title="Acknowledgments">
			<t>The authors wish to acknowledge the borrowing of ideas from other
   internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley
   and Gavin Llewellyn, and to thank Flemming Andreasen, Christian Groves,
   Gunnar Hellstrom,  Paul Kyzivat, Jonathan Lennox,
   Uwe Rauschenbach and Roman Shpount anchor="IANA-reg-data-channel-attribs" numbered="true" removeInRFC="false" toc="include" pn="section-9.3">
        <name slugifiedName="name-registering-attributes-for-">Registering Attributes for their invaluable comments.</t>
			<t>Special thanks to Christer Holmberg Use with Data Channels</name>
        <t indent="0" pn="section-9.3-1">When a subprotocol is defined for helping finish the document and cleaning use over data channels with
        the SDP offer/answer section.</t>
		</section>
		<section title="CHANGE LOG">
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15'">
				<t>
					<list style="symbols">
						<t>Editorial changes  separate sections for offer/answer procedures.</t>
						<t>Update security section.</t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14'">
				<t>
					<list style="symbols">
						<t>Change "dtls-id" to "tls-id" and assign 20 octet long values</t>
						<t>Remove of RFC4566bis draft from list of normative references.
   </t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12'">
				<t>
					<list style="symbols">
						<t>Modification of Keith's address information.
   </t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11'">
				<t>
					<list style="symbols">
						<t>dcmap-stream-id syntax change to limit size to 5 digits.
   </t>
						<t>Add missing 'x' prefix to quoted-visible syntax.
   </t>
						<t>Align mechanism, any SDP offerer and answerer handling when both max-retr and max-time are present.
   </t>
						<t>Use of TEST-NET-1 ip addresses in examples.
   </t>
						<t>Add missing a=dtls-id in one example.
   </t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10'">
				<t>
					<list style="symbols">
						<t>Removal of attributes that may be
        negotiated using the "a=connection" "a=dcsa:" attribute lines from all SDP examples.
   </t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09'">
				<t>
					<list style="symbols">
						<t>In <bcp14>MUST</bcp14> be added to the introduction:
    <list style="symbols">
								<t>Replacement IANA
        "attribute-name registry (formerly "att-field")", as specified in
        <xref target="RFC8866" sectionFormat="comma" section="8.2.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8866#section-8.2.4" derivedContent="RFC8866"/>.  This
        document specifies that new Usage Levels of the sentence "The RTCWeb working group has defined form "dcsa (foo)"
        (where "foo" is a placeholder for the concept of
     bi-directional data channels running on top subprotocol name) should be
        registered by documents that specify negotiation of SCTP/DTLS (SCTP over the Datagram
     Transport Layer Security protocol)" with "The RTCWeb working group particular
        subprotocols.</t>
        <t indent="0" pn="section-9.3-2">IANA has defined the
     concept of bi-directional data channels running on top of updated the Stream Control
     Transmission Protocol (SCTP)".
     </t>
								<t>Addition of following sentences "attribute-name (formerly "att-field")"
        registry to point to this document.</t>
      </section>
    </section>
  </middle>
  <back>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the second paragraph: "These procedures requirements in the specification.  These words are
     based on generic SDP offer/answer negotiation rules for SCTP
     based media transport often capitalized. This document defines these words as specified they should be interpreted in <xref target="I-D.ietf-mmusic-sctp-sdp"/> IETF documents.  This document specifies an Internet Best Current Practices for the SDP "m" line proto values UDP/DTLS/SCTP Internet Community, and TCP/DTLS/SCTP. requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3264" target="https://www.rfc-editor.org/info/rfc3264" quoteTitle="true" derivedAnchor="RFC3264">
          <front>
            <title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2002" month="June"/>
            <abstract>
              <t indent="0">This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them.  In the future, data channels could be defined over other SCTP based protocols, such as
     SCTP over IP. However, corresponding potential model, one participant offers the other "m" line proto values are not
     considered in this document."
     </t>
							</list>
						</t>
						<t>Replacement a description of "DTLS connection" with "DTLS association" throughout the document.
   </t>
						<t>In sections <xref target="dcmap-mux-category"/> desired session from their perspective, and
   <xref target="dcsa-mux-category"/> removal of the sentences "This document also
   does not specify multiplexing rules for this attribute for SCTP or
   SCTP/DTLS proto values".
   </t>
						<t>In the text related to "Subsequent SDP answer" in section
   <xref target="various_SDP_OA_considerations"/> replacement of "The DTLS/SCTP
   association remains open ..." other participant answers with "The SCTP association remains open ...".
   </t>
						<t>In the text after the second SDP answer desired session from their perspective.  This offer/answer model is most useful in section
   <xref target="examples"/> replacement of "... (after SCTP/DTLS association unicast sessions where information from both participants is setup)"
   with "... (after needed for the SCTP association complete view of the session.  The offer/answer model is used by protocols like the Session Initiation Protocol (SIP).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3264"/>
          <seriesInfo name="DOI" value="10.17487/RFC3264"/>
        </reference>
        <reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3629" quoteTitle="true" derivedAnchor="RFC3629">
          <front>
            <title>UTF-8, a transformation format of ISO 10646</title>
            <author initials="F." surname="Yergeau" fullname="F. Yergeau">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="November"/>
            <abstract>
              <t indent="0">ISO/IEC 10646-1 defines a large character set up)".
   </t>
						<t>Addition called the Universal Character Set (UCS) which encompasses most of draft-ietf-mmusic-dtls-sdp to the list world's writing systems.  The originally proposed encodings of informative
   references.
   </t>
						<t>Addition of "a=dtls-id" attribute lines the UCS, however, were not compatible with many current applications and protocols, and this has led to the SDP offer/answer examples in
   <xref target="examples"/>.
   </t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08'">
				<t>
					<list style="symbols">
						<t>Addition development of definition UTF-8, the object of "data channel subprotocol" to
   <xref target="terminology"/> as proposed on this memo.  UTF-8 has the MMUSIC list,
   https://www.ietf.org/mail-archive/web/mmusic/current/msg15827.html.
   </t>
						<t>Addition characteristic of RFC4566bis draft preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to list other values.  This memo obsoletes and replaces RFC 2279.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="63"/>
          <seriesInfo name="RFC" value="3629"/>
          <seriesInfo name="DOI" value="10.17487/RFC3629"/>
        </reference>
        <reference anchor="RFC4960" target="https://www.rfc-editor.org/info/rfc4960" quoteTitle="true" derivedAnchor="RFC4960">
          <front>
            <title>Stream Control Transmission Protocol</title>
            <author initials="R." surname="Stewart" fullname="R. Stewart" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="September"/>
            <abstract>
              <t indent="0">This document obsoletes RFC 2960 and RFC 3309.  It describes the Stream Control Transmission Protocol (SCTP).  SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of normative references.
   </t>
						<t>Updates broader applications.</t>
              <t indent="0">SCTP is a reliable transport protocol operating on top of tables in <xref target="IANA-reg-dcmap"/> and
   <xref target="IANA-reg-dcsa"/> a connectionless packet network such as per section 8.2.4
   of RFC4566bis draft.
   </t>
						<t>Addition IP.  It offers the following services to its users:</t>
              <t indent="0">--  acknowledged error-free non-duplicated transfer of new "new-usage-level">.
   </t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07'">
				<t>
					<list style="symbols">
						<t>Addition user data,</t>
              <t indent="0">--  data fragmentation to conform to discovered path MTU size,</t>
              <t indent="0">--  sequenced delivery of two new paragraphs to <xref target="dcsa-attribute"/> regarding
   subprotocol attribute relationship user messages within multiple streams, with transport protocol.
   </t>
						<t>Addition an option for order-of-arrival delivery of individual user messages,</t>
              <t indent="0">--  optional bundling of multiple user messages into a note to <xref target="IANA_subproto_ids"/> regarding subprotocols
   simultaneously defined for data channel and Websocket usage.
   </t>
						<t>Addition single SCTP packet, and</t>
              <t indent="0">--  network-level fault tolerance through supporting of two further SDP offer/answer considerations multi-homing at either or both ends of an association.</t>
              <t indent="0"> The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4960"/>
          <seriesInfo name="DOI" value="10.17487/RFC4960"/>
        </reference>
        <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234" quoteTitle="true" derivedAnchor="RFC5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author initials="D." surname="Crocker" fullname="D. Crocker" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Overell" fullname="P. Overell">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="January"/>
            <abstract>
              <t indent="0">Internet technical specifications often need to
    <xref target="various_SDP_OA_considerations"/> regarding unknown subprotocol
    attributes 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 known subprotocol attributes simplicity with unknown data channel transport
    related semantic.
   </t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06'">
				<t>
					<list style="symbols">
						<t>Changes addressing Christian Groves's WGLC review comments raised in
   http://www.ietf.org/mail-archive/web/mmusic/current/msg15357.html and
   http://www.ietf.org/mail-archive/web/mmusic/current/msg15359.html.
   </t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05'">
				<t>
					<list style="symbols">
						<t>In IANA registration <xref target="IANA-reg-dcmap"/> reasonable representational power.  The differences between standard BNF and
   <xref target="IANA-reg-dcsa"/> replacement of contact name ABNF involve naming rules, repetition, alternatives, order-independence, and e-mail address
   with "MMUSIC Chairs" value ranges.  This specification also supplies additional rule definitions and "mmusic-chairs@ietf.org".
   </t>
						<t>In <xref target="dcsa-attribute"/> replacement encoding for a core lexical analyzer of "Thus in the example above, type common to several Internet specifications.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
        </reference>
        <reference anchor="RFC6525" target="https://www.rfc-editor.org/info/rfc6525" quoteTitle="true" derivedAnchor="RFC6525">
          <front>
            <title>Stream Control Transmission Protocol (SCTP) Stream Reconfiguration</title>
            <author initials="R." surname="Stewart" fullname="R. Stewart">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Tuexen" fullname="M. Tuexen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Lei" fullname="P. Lei">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="February"/>
            <abstract>
              <t indent="0">Many applications that use the
   original attribute line "a=accept-
   types:text/plain" is represented by Stream Control Transmission Protocol (SCTP) want the attribute line "a=dcsa:2
   accept-types:text/plain", which specifies that this instance ability to "reset" a stream.  The intention of MSRP
   being transported on resetting a stream is to set the SCTP association using numbering sequence of the data channel with stream id 2 accepts plain text files." back to 'zero' with "... which specifies a corresponding notification to the application layer that the reset has been performed.  Applications requiring this
   instance of feature want it so that they can "reuse" streams for different purposes but still utilize the MSRP subprotocol being transported ...".
   </t>
						<t>The last paragraph of <xref target="dcsa-attribute"/> started with
   "Note: This document does not provide stream sequence number so that the application can track the message flows.  Thus, without this feature, a complete specification ...".
   Removal of "Note:" and move new use of this paragraph an old stream would result in message numbers greater than expected, unless there is a protocol mechanism to "reset the introduction in
   <xref target="introduction"/> as last paragraph.
   </t>
						<t>
							<xref target="prot_att"/>'s headline was "Subprotocol Specific Attributes".
   Change of this headline streams back to "Other Media Level Attributes" and adaptations of zero".  This document also includes methods for resetting the first
   paragraph of this section transmission sequence numbers, adding additional streams, and the first paragraph resetting all stream sequence numbers.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6525"/>
          <seriesInfo name="DOI" value="10.17487/RFC6525"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of <xref target="dcsa-attribute"/> Uppercase vs Lowercase in order to clarify RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that not only those attributes may be
   encapsulated used in a "dcsa" attribute, which are specifically defined for the
   subprotocol, but that also other attributes may be encapsulated if
   they are related protocol  specifications.  This document aims to reduce the specific subprotocol instance.
   </t>
						<t>Move of the last but one paragraph of <xref target="dcsa-attribute"/> starting with
   "The same syntax applies to ..." right in front ambiguity by clarifying that only UPPERCASE usage of the formal syntax definition of key words have the
   "dcsa" attribute.
   </t>
						<t>Modifications of the text in <xref target="dcmap-mux-category"/> and
   <xref target="dcsa-mux-category"/> in order not to explicitly restrict usage of the
   "a=dcmap:" and "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/SCTP"
   or "TCP/DTLS/SCTP".
   </t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04'">
				<t>
					<list style="symbols">
						<t>In <xref target="subprotocol-parameter"/> the first (and only) paragraph was
    "The 'subprotocol' parameter indicates which protocol the
    client expects to exchange via the channel.
    'subprotocol' is an optional parameter.
    If the 'subprotocol' parameter is not present, then its value
    defaults to the empty string."
    Replacement of this paragraph with following two paragraphs:
    <list style="symbols">
								<t> The 'subprotocol' parameter indicates which protocol the
      client expects to exchange via the channel.
      This parameter maps to the 'Protocol' parameter defined in
      <xref target="I-D.ietf-rtcweb-data-protocol"/>.
      <xref target="IANA_subproto_ids"/> specifies how new subprotocol parameter
      values are registered.
      'subprotocol' is an optional parameter.
      If the 'subprotocol' parameter is not present, then its value
      defaults to the empty string.
     </t>
								<t>Note: The empty string MAY also be explicitly used as 'subprotocol' value,
      such that 'subprotocol=""' is equivalent to the 'subprotocol' parameter not being
      present at all. <xref target="I-D.ietf-rtcweb-data-protocol"/> allows the
      DATA_CHANNEL_OPEN message's 'subprotocol' value to be an empty string.
     </t>
							</list>
						</t>
						<t>Addition of <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/>
    to list the of normative references.
   </t>
						<t>Addition of dcmap attribute specific IANA registration
    <xref target="IANA-reg-dcmap"/>.
   </t>
						<t>Addition of dcsa attribute specific IANA registration
    <xref target="IANA-reg-dcsa"/>.
   </t>
						<t>Addition of new <xref target="dcmap-mux-category"/> describing the mux category
    of the dcmap SDP attribute. This section and the new "a=dcsa:" attribute related
    mux category section are similar to the "Mux Category" sections of
    the "a=sctp-port:" and "a=max-message-size:" attributes in
    <xref target="I-D.ietf-mmusic-sctp-sdp"/>.
   </t>
						<t>Addition of new <xref target="dcsa-mux-category"/> describing the mux category
    of the dcsa SDP attribute.
   </t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03'">
				<t>
					<list style="symbols">
						<t>In <xref target="introduction"/> replacement of
   "RTCWeb leaves it open for other applications to use data channels and its in-band
   DCEP or out-of-band non-DCEP protocols for creating them" with
   "... to use data channels and its in-band DCEP or other in-band or out-of-band
   protocols for creating them".
   Additionally replacement of
   "In particular, the SDP offer generated by the application
   includes no channel-specific information" with
   "... generated by the RTCweb data channel stack includes
   no channel-specific information".
   </t>
						<t>Move of former section 5 ("Data Channels") to new
   <xref target="generic-out-of-band-aspects"/> and removal of JavaScript API specific
   discussions from this moved text (like mentioning of data channel stack specific
   states). Therefore former section 6 ("SDP Offer/Answer Negotiation") is now
   <xref target="sdp_synt"/>.
   </t>
						<t>In <xref target="sdp_synt"/>:
    <list style="symbols">
								<t>Relacement of <xref target="sdp_synt"/>'s
     first paragraph
     "This section defines a method of non-DCEP negotiation by which two
     clients can negotiate data channel-specific and subprotocol-specific
     parameters, using the out-of-band SDP offer/answer exchange.  This
     SDP extension can only be used with the SDP offer/answer model." with
     "This section defines an SDP extension by which
     two clients can negotiate data channel-specific and subprotocol-specific
     parameters without using DCEP <xref target="I-D.ietf-rtcweb-data-protocol"/>.
     This SDP extension only defines usage in the context of SDP offer/answer."
     </t>
								<t>Addition of new paragraph:
     "<xref target="generic-out-of-band-aspects"/> provides information how data channels
     work in general and especially summarizes some key aspects, which should be
     considered for the negotiation of data channels if DCEP is not used."
     </t>
							</list>
						</t>
						<t>In <xref target="subsec-sdp-attr-for-dc-par-neg"/> replacement of "The intention of
   exchanging these attributes is to create data channels on both the peers with the same
   set of attributes without actually using the DCEP
   <xref target="I-D.ietf-rtcweb-data-protocol"/>" with "The intention in exchanging
   these attributes is to create, on two peers, without use of DCEP
   <xref target="I-D.ietf-rtcweb-data-protocol"/>,
   matched pairs of oppositely directed data channels having the same set of attributes".
   </t>
						<t>In <xref target="max-retr-param-definition"/> replacement of "The 'max-retr'
   parameter indicates the maximal number a user message will be retransmitted" with "The
   'max-retr' parameter indicates the maximal number of times a user message will
   be retransmitted".
   </t>
						<t>In <xref target="id_mngt"/> replacement of "However, an SDP offer/answer exchange
   MUST NOT be initiated if the associated SCTP stream is already negotiated via DCEP"
   with "However, an SCTP stream MUST NOT be referenced in a dcmap or dcsa
   attribute of an SDP offer/answer exchange if the associated SCTP stream has already
   been negotiated via DCEP".
   </t>
						<t>In the examples in <xref target="examples"/> addition of the previously missing
   colons to the "a=sctp-port" attribute lines.
   </t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02'">
				<t>
					<list style="symbols">
						<t>Move of reference draft-ietf-rtcweb-jsep from the list of normative
  references to the list of informative references. Remover in -07 since not referenced</t>
						<t>Addition of IANA SDP parameters to the list of informative
  references
  and addition of following two sentences to the first paragraph after the ABNF
  definition: "Note however that not all SDP attributes are suitable
  as "a=dcsa:" parameter. IANA SDP parameters contains
  the lists of IANA registered session and media level or
  media level only SDP attributes."</t>
						<t>In the introduction replacement of last sentence
  "This document defines SDP-based out-of-band negotiation procedures
   to establish data channels for transport of well-defined subprotocols"
  with
  "This document defines SDP offer/answer negotiation procedures
   to establish data channels for transport of well-defined subprotocols,
   to enable out-of-band negotiation".
  </t>
						<t>Throughout the document replacement of "external negotiation" with
  "SDP offer/answer negotiation" and removal of term "external negotiation" from the
  terminology list in <xref target="terminology"/>.</t>
						<t> Throughout the document replacement of "internal negotiation" with
  "DCEP" and removal of terms "internal negotiation" and "in-band negotiation"
  from the terminology list in <xref target="terminology"/>.</t>
						<t>Addition of "SCTP Stream Sequence Number (SSN)" to the list of terms.</t>
						<t>In <xref target="id_mngt"/> replacement of sentence
  "However, a single stream is managed using one method at a time." with
  "However, an SDP offer/answer exchange MUST NOT be initiated
  if the associated SCTP stream is already negotiated via DCEP".</t>
						<t>In <xref target="param_negotiation"/> replacement of sentence
  "By definition max-retr and max-time are mutually exclusive, so only one of
  them can be present in a=dcmap" with
  "By definition max-retr and max-time are mutually exclusive,
  so aBoth MUST NOT be present in a=dcmap".</t>
						<t>Move of reference <xref target="WebRtcAPI"/> from list of normative references
  to list of informative references.</t>
						<t>Removal of almost all text parts, which discussed JavaScript or other API specific
  aspects. Such API specific aspects were mainly discussed in sub-sections of Section 5
  and <xref target="sdp_synt"/>
  of draft-ietf-mmusic-data-channel-sdpneg-02.</t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01'">
				<t>
					<list style="symbols">
						<t>New <xref target="appl_statement"/> regarding applicability to
   SDP offer/answer only.</t>
						<t>Addition of new <xref target="IANA_subproto_ids"/> "Subprotocol identifiers" as
   subsection of the "IANA Considerations" related <xref target="IANA"/>.
   Also removal of the temporary note
   "To be completed.  As [I-D.ietf-rtcweb-data-protocol] this document should refer to
   IANA's WebSocket Subprotocol Name Registry defined in <xref target="RFC6455"/>"</t>
						<t> In <xref target="param_negotiation"/>:
    <list style="symbols">
								<t>In the first paragraph
     replacement of the sentence "If an SDP offer
     contains both of these parameters then such an SDP offer will be rejected." with "If
     an SDP offer contains both of these parameters then the receiver of such an SDP
     offer MUST reject the SDP offer." </t>
								<t>In the second paragraph
     capitalization of "shall" and "may" such that both sentences now read:
     "The SDP answer SHALL echo the same subprotocol, max-retr, max-time,
     ordered parameters, if those were present in the offer, and MAY include
     a label parameter. They MAY appear in any order, which could be
     different from the SDP offer, in the SDP answer."</t>
								<t>In the third paragraph
     replacement of the sentence
     "The same information MUST be replicated without changes in any subsequent offer or
     answer, as long as the data channel is still opened at the time of offer or answer
     generation." with
     "When sending a subsequent offer or an answer, and for as long as the data channel
     is still open, the sender MUST replicate the same information.".</t>
							</list>
						</t>
						<t>In <xref target="param_negotiation"/> the mapping of data channel types defined in
   <xref target="I-D.ietf-rtcweb-data-protocol"/> to the SDP "a=dcmap" attribute
   parameters were illustrated using example "a=dcmap" attribute lines.
   Replacement of these example "a=dcmap" attribute lines with just the "a=dcmap"
   attribute parameters being relevant for the channel type.</t>
						<t>In <xref target="various_SDP_OA_considerations"/> the description of bullet
   point "SDP offer has no a=dcmap attributes - Initial SDP offer:" was
   "Initial SDP offer: No data channel negotiated yet."
   Replacement of this description with
   "Initial SDP offer: No data channel is negotiated yet.
   The DTLS connection and SCTP association is
   negotiated and, if agreed, established as per
   <xref target="I-D.ietf-mmusic-sctp-sdp"/>."</t>
						<t>In <xref target="various_SDP_OA_considerations"/> in both bullet points related to
   "Subsequent SDP offer" and "Subsequent SDP answer" replacement of
   "All the externally negotiated data channels must be closed now." with
   "All the externally negotiated data channels are expected to be closed now.".</t>
						<t>In <xref target="ext_open"/>'s sixth paragraph
   replacement of the two occurrences of "must" with "MUST".</t>
						<t>In <xref target="dcmap-attr-definition"/> in the definition of the ABNF rule
   "dcmap-opt" there was a comment saying that
   "Only maxretr-opt or maxtime-opt is present. Both MUST NOT be present."
   Removal of the second normative sentence and instead addition of following new
   paragraph to the end of this section:
   "Within an 'a=dcmap' attribute line's 'dcmap-opt' value only one
   'maxretr-opt' parameter or one 'maxtime-opt' parameter is present.
   Both MUST NOT be present."</t>
						<t>In <xref target="ordered-param-description"/> replacement of the first sentence
   "The 'ordered' parameter with value "true" indicates that DATA chunks in the channel
   MUST be dispatched to the upper layer by the receiver while preserving the order."
   with
   "The 'ordered' parameter with value "true" indicates that the receiver MUST dispatch
   DATA chunks in the data channel to the upper layer while preserving the order.".</t>
						<t>In <xref target="opendc"/>'s first paragraph replacement of the one occurrence of
   "must" with "..., it MUST wait until ...".</t>
						<t>In <xref target="close-dc"/>:
    <list style="symbols">
								<t>In the second paragraph replacement of "must" with "... whether this closing MUST
     in addition ..."</t>
								<t>In the third paragraph replacement of the sentence
     "The port value for the "m" line SHOULD NOT be changed (e.g., to zero)
     when closing a data channel ..." with
     "The offerer SHOULD NOT change the port value for the "m" line (e.g., to zero) when
     closing a data channel ...".</t>
								<t>In the last but two paragraph replacement of the sentence
     "... then an SDP offer which excludes this closed data channel SHOULD be generated."
     with
     "... then the client SHOULD generate an SDP offer which excludes this closed data
     channel.".</t>
								<t>In the last but one paragraph replacement of "must" with
     "The application MUST also close...".</t>
							</list>
						</t>
						<t>In <xref target="prot_att"/> addition of following note after the formal definition
   of the 'a=dcsa' attribute:
   "Note that the above reference to RFC 4566 defines were the
   attribute definition can be found;
   it does not provide any limitation on support of attributes
   defined in other documents in accordance with this attribute
   definition."</t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00'">
				<t>
					<list style="symbols">
						<t>In <xref target="terminology"/> "WebRTC data channel" was defined as
   "A bidirectional channel consisting of paired
   SCTP outbound and inbound streams."
   Replacement of this definition with
   "Data channel: A WebRTC data channel as specified in
   <xref target="I-D.ietf-rtcweb-data-channel"/>", and consistent usage
   of "data channel" in the remainder of the document including the
   document's headline."</t>
						<t>In Section 5 removal of following note:
   'OPEN ISSUE: The syntax in <xref target="I-D.ietf-mmusic-sctp-sdp"/> may
   change as that document progresses. In particular we expect
   "webrtc-datachannel" to become a more general term.'</t>
						<t>Consistent usage of '"m" line' in whole document as per RFC4566.</t>
						<t>In <xref target="subsec-sdp-attr-for-dc-par-neg"/>
   removal of the example dcmap attribute line
   'a=dcmap:2 subprotocol="bfcp";label="channel 2' as there are already
   four examples right after the ABNF rules in
   <xref target="dcmap-attr-definition"/>.
   Corresponding removal of following related note:
   "Note: This document does not provide a complete specification
   of how to negotiate the use of a WebRTC data channel to transport BFCP.
   Procedures specific to each subprotocol such as BFCP will be
   documented elsewhere. The use of BFCP is only an example of how
   the generic procedures described herein might apply to a specific
   subprotocol."</t>
						<t>In <xref target="subsec-sdp-attr-for-dc-par-neg"/>
   removal of following note:
   "Note: This attribute is derived from attribute "webrtc-DataChannel",
   which was defined in old version 03 of the
   following draft, but which was removed along with any support for SDP
   external negotiation in subsequent versions:
   <xref target="I-D.ietf-mmusic-sctp-sdp"/>."</t>
						<t>Insertion of following new sentence to the beginning of
   <xref target="dcmap-attr-definition"/>:
   "dcmap is a media level attribute having following ABNF syntax:"</t>
						<t>Insertion of new <xref target="dcmap-stream-id-param-definition"/>
   containing the dcmap-stream-id specifying sentence, which previously
   was placed right before the formal ABNF rules.
   Removal of the sentence 'Stream is a mandatory
   parameter and is noted directly after the "a=dcmap:" attribute's
   colon' as this information is part of the ABNF specification.</t>
						<t>In <xref target="dcmap-attr-definition"/> modification of the
   'ordering-value' values from "0" or "1" to "true" or "false".
   Corresponding text modifications in <xref target="ordered-param-description"/>.</t>
						<t>In <xref target="dcmap-attr-definition"/> the ABNF definition of "quoted-string"
   referred to rule name "escaped-char", which was not defined.
   Instead a rule with name "escaped" was defined. Renamed that rule's name
   to "escaped-char".</t>
						<t>Insertion of a dedicated note right after the "a=dcmap:4" attribute example
   in <xref target="dcmap-attr-definition"/> regarding the non-printable
   "escaped-char" character within the "label" value.</t>
						<t>In <xref target="prot_att"/>'s second paragraph replacement of
   "sctp stream identifier" with "SCTP stream identifier".</t>
						<t>In first paragraph of <xref target="id_mngt"/> replacement of first two sentences
   'For the SDP-based external negotiation described in this document,
   the initial offerer based "SCTP over DTLS" owns by convention the
   even stream identifiers whereas the initial answerer owns the odd stream
   identifiers.  This ownership is invariant for the whole
   lifetime of the signaling session, e.g. it does not change if the
   initial answerer sends a new offer to the initial offerer.'
   with
   'If an SDP offer/answer exchange
   (could be the initial or a subsequent one)
   results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media description being
   accepted, and if this SDP offer/answer exchange results in the
   establishment of a new SCTP association, then the SDP offerer owns the
   even SCTP stream ids of this new SCTP association and the answerer owns
   the odd SCTP stream identifiers.
   If this "m" line is removed from the signaling session (its port number
   set to zero), and if usage of this or of a new UDP/DTLS/SCTP or
   TCP/DTLS/SCTP based "m" line is renegotiated later on,
   then the even and odd SCTP stream identifier
   ownership is redetermined as well as described above.'</t>
						<t>In <xref target="opendc"/> the first action of an SDP answerer,
   when receiving an SDP offer, was described as
   "Applies the SDP offer.  Note that the browser  ignores data channel
   specific attributes in the SDP."
   Replacement of these two sentences with
   "Parses and applies the SDP offer. Note that the typical parser
   normally ignores unknown SDP attributes, which includes data
   channel related attributes."</t>
						<t>In <xref target="opendc"/> the second sentence of the third
   SDP answerer action was
   "Note that the browser  is asked to create data
   channels with stream identifiers not "owned" by the agent.".
   Replacement of this sentence with
   "Note that the agent is asked to
   create data channels with SCTP stream identifiers
   contained in the SDP offer if the SDP offer is accepted."</t>
						<t>In <xref target="close-dc"/> the third paragraph began with
   "A data channel can be closed  by sending a new SDP offer which
   excludes the dcmap and dcsa attribute lines for the data channel.
   The port value for the m line SHOULD NOT be changed (e.g., to zero)
   when closing a data channel (unless all data channels are being
   closed and the SCTP association is no longer needed), since this
   would close the SCTP association and impact all of the data channels.
   If the answerer accepts the SDP offer then it MUST also exclude the
   corresponding attribute lines in the answer. ..."
   Replacement of this part with
   "The intention to close a data channel can be signaled
   by sending a new SDP offer which
   excludes the "a=dcmap:" and "a=dcsa:" attribute lines  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831" quoteTitle="true" derivedAnchor="RFC8831">
          <front>
            <title>WebRTC Data Channels</title>
            <author initials="R" surname="Jesup" fullname="Randell Jesup">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Loreto" fullname="Salvatore Loreto">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Tüxen" fullname="Michael Tüxen">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8831"/>
          <seriesInfo name="DOI" value="10.17487/RFC8831"/>
        </reference>
        <reference anchor="RFC8832" target="https://www.rfc-editor.org/info/rfc8832" quoteTitle="true" derivedAnchor="RFC8832">
          <front>
            <title>WebRTC Data Channel Establishment Protocol</title>
            <author initials="R." surname="Jesup" fullname="Randell Jesup">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Loreto" fullname="Salvatore Loreto">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Tüxen" fullname="Michael Tüxen">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8832"/>
          <seriesInfo name="DOI" value="10.17487/RFC8832"/>
        </reference>
        <reference anchor="RFC8841" target="https://www.rfc-editor.org/info/rfc8841" quoteTitle="true" derivedAnchor="RFC8841">
          <front>
            <title>Session Description Protocol (SDP) Offer/Answer Procedures for the data channel.
   The port value Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport</title>
            <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Shpount" fullname="Roman Shpount">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Loreto" fullname="Salvatore Loreto">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8841"/>
          <seriesInfo name="DOI" value="10.17487/RFC8841"/>
        </reference>
        <reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8859" quoteTitle="true" derivedAnchor="RFC8859">
          <front>
            <title>A Framework for Session Description Protocol (SDP) Attributes When Multiplexing</title>
            <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8859"/>
          <seriesInfo name="DOI" value="10.17487/RFC8859"/>
        </reference>
        <reference anchor="RFC8866" target="https://www.rfc-editor.org/info/rfc8866" quoteTitle="true" derivedAnchor="RFC8866">
          <front>
            <title>SDP: Session Description Protocol</title>
            <author initials="A" surname="Begen" fullname="Ali Begen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P" surname="Kyzivat" fullname="Paul Kyzivat">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Perkins" fullname="Colin Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Handley" fullname="Mark Handley">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8866"/>
          <seriesInfo name="DOI" value="10.17487/RFC8866"/>
        </reference>
      </references>
      <references pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC4975" target="https://www.rfc-editor.org/info/rfc4975" quoteTitle="true" derivedAnchor="RFC4975">
          <front>
            <title>The Message Session Relay Protocol (MSRP)</title>
            <author initials="B." surname="Campbell" fullname="B. Campbell" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Mahy" fullname="R. Mahy" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Jennings" fullname="C. Jennings" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="September"/>
            <abstract>
              <t indent="0">This document describes the "m" line SHOULD NOT be changed (e.g., to zero)
   when closing a data channel (unless all data channels are being
   closed and the SCTP association is no longer needed), since this
   would close the SCTP association and impact all of the data channels.
   If the answerer accepts the SDP offer then it MUST close those data channels
   whose "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the received
   SDP offer, unless those data channels were already closed,
   and it MUST also exclude the
   corresponding attribute lines in the answer."</t>
						<t>In <xref target="close-dc"/> the hanging text after the third paragraph was
   "This delayed close is to  handle cases where Message Session Relay Protocol, a successful SDP
   answer is not received, in which case the state of session should
   be kept per the last successful SDP offer/answer."
   Replacement of this sentence with
   "This delayed closure is RECOMMENDED in order
   to handle cases where protocol for transmitting a successful SDP answer is not received, in
   which case the state of the session SHOULD be kept per the last
   successful SDP offer/answer."</t>
						<t>Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects
   <xref target="subsec-sdp-attr-for-dc-par-neg"/> contained already
   procedural descriptions related to data channel reliability negotiation.
   Creation of new <xref target="param_negotiation"/> and moval series of
   reliability negotiation related text to this new section.</t>
					</list>
				</t>
			</section>
			<section title="Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02'">
				<t>
					<list style="symbols">
						<t>Removal of note "ACTION ITEM" from section "subprotocol parameter".
   As <xref target="I-D.ietf-rtcweb-data-protocol"/> this document should refer to IANA's
   WebSocket Subprotocol Name Registry defined in <xref target="RFC6455"/>
						</t>
						<t>In whole document, replacement of "unreliable" with "partially reliable",
   which is used in <xref target="I-D.ietf-rtcweb-data-channel"/> and in
   <xref target="I-D.ietf-rtcweb-data-protocol"/> in most places.</t>
						<t>Clarification of the semantic if the "max-retr" parameter is not present instant messages in
   an "a=dcmap" attribute line. In section "max-retr parameter" the sentence
   "The max-retr parameter is optional with default value unbounded"
   was replaced with "The max-retr parameter is optional. If the max-retr parameter is not present, then the maximal number context of
   retransmissions is determined as per the generic SCTP retransmission
   rules a session.  Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as specified in <xref target="RFC4960"/>".</t>
						<t>Clarification of the semantic if the "max-time" parameter is not present in
   an "a=dcmap" attribute line. In section "max-time parameter" the sentence
   "The max-time parameter is optional with default value unbounded"
   was replaced with "The max-time parameter is optional. If
   the max-time parameter is not present, then the generic SCTP
   retransmission timing rules apply as specified Session Initiation Protocol.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4975"/>
          <seriesInfo name="DOI" value="10.17487/RFC4975"/>
        </reference>
        <reference anchor="RFC6455" target="https://www.rfc-editor.org/info/rfc6455" quoteTitle="true" derivedAnchor="RFC6455">
          <front>
            <title>The WebSocket Protocol</title>
            <author initials="I." surname="Fette" fullname="I. Fette">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Melnikov" fullname="A. Melnikov">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="December"/>
            <abstract>
              <t indent="0">The WebSocket Protocol enables two-way communication between a client running untrusted code in <xref target="RFC4960"/>".</t>
						<t>In section "label parameter" the sentence "Label is a mandatory parameter."
   was removed and following new sentences (including the note) were added:
   "The 'label' parameter is optional. If it is not
   present, then its value defaults controlled environment to the empty string.
   Note: a remote host that has opted-in to communications from that code.  The empty string may also be explicitly security model used as 'label' value,
   such that 'label=""' for this is equivalent to the 'label' parameter not being
   present at all.
   <xref target="I-D.ietf-rtcweb-data-protocol"/> allows the DATA_CHANNEL_OPEN
   message's 'Label' value to be origin-based security model commonly used by web browsers.  The protocol consists of an empty string."</t>
						<t>In section "subprotocol parameter" the sentence
   "subprotocol opening handshake followed by basic message framing, layered over TCP.  The goal of this technology is to provide a mandatory parameter." was replaced mechanism for browser-based applications that need two-way communication with
   "'subprotocol' is an optional
   parameter.  If the 'subprotocol' parameter is servers that does not present, then its
   value defaults to the empty string."</t>
						<t>In the "Examples" section, in the first two SDP offer examples in
   the "a=dcmap" attribute lines 'label="BGCP"' was replaced with 'label="bfcp"'.</t>
						<t>In all examples, the "m" line proto value "DTLS/SCTP" was replaced with
   "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were replaced with
   "a=max-message-size" attribute lines, as per draft-ietf-mmusic-sctp-sdp-12.</t>
					</list>
				</t>
			</section>
			<section title="Changes against '-01'">
				<t>
					<list style="symbols">
						<t>Formal syntax for dcmap and dcsa attribute lines. </t>
						<t>Making subprotocol as an optional parameter in dcmap. </t>
						<t>Specifying disallowed parameter combinations for max-time and max-retr. </t>
						<t>Clarifications rely on WebRTC data channel close procedures. </t>
					</list>
				</t>
			</section>
			<section title="Changes against '-00'">
				<t>
					<list style="symbols">
						<t> Revisions to identify difference between internal and external
    negotiation and their usage.</t>
						<t>Introduction of more generic terminology, e.g. "application" instead of
    "browser".</t>
						<t>Clarification of how "max-retr and max-time affect the usage of
    unreliable and reliable WebRTC data channels.</t>
						<t>Updates of examples to take into account the SDP syntax changes
    introduced with draft-ietf-mmusic-sctp-sdp-07.</t>
						<t>Removal of the SCTP port number from the "a=dcmap" and "a=dcsa" attributes
    as this is now contained in the a=sctp-port attribute, opening multiple HTTP connections (e.g., using XMLHttpRequest or &lt;iframe&gt;s and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP association
    on top of the DTLS connection.</t>
					</list>
				</t>
			</section>
		</section>
	</middle>
	<back>
		<references title="Normative References">
   &RFC2119;
   &RFC4960;
   &RFC8174;
   &RFC3264;
   &RFC5234;
   &RFC6525;
   &RFC3629;
   &DATAREQ;
   &SDPBIS;
   &SDPSCTP;
   &SDPMUXATTR;
   &DATAPROTO;
  </references>
		<references title="Informative References">

     &RFC4582;
   &RFC4975;
   &RFC6455;
   &CLUEDATA;
   &MSRPDATA; long polling).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6455"/>
          <seriesInfo name="DOI" value="10.17487/RFC6455"/>
        </reference>
        <reference anchor="WebRtcAPI" target="https://www.w3.org/TR/2018/CR-webrtc-20180927/"> anchor="RFC8850" target="https://www.rfc-editor.org/info/rfc8850" quoteTitle="true" derivedAnchor="RFC8850">
          <front>
					<title>
WebRTC 1.0: Real-time Communication Between Browsers
</title>
            <title>Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel</title>
            <author initials="A." surname="Bergkvist" fullname="Adam Bergkvist">
						<organization/> initials="C." surname="Holmberg" fullname="Christer Holmberg">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8850"/>
          <seriesInfo name="DOI" value="10.17487/RFC8850"/>
        </reference>
        <reference anchor="RFC8855" target="https://www.rfc-editor.org/info/rfc8855" quoteTitle="true" derivedAnchor="RFC8855">
          <front>
            <title>The Binary Floor Control Protocol (BFCP)</title>
            <author initials="D." surname="Burnett" fullname="Daniel Burnett">
						<organization/> initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Drage" fullname="Keith Drage">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Kristensen" fullname="Tom Kristensen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Ott" fullname="Jörg Ott">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Jennings" fullname="Cullen Jennings">
						<organization/> surname="Eckel" fullname="Charles Eckel">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8855"/>
          <seriesInfo name="DOI" value="10.17487/RFC8855"/>
        </reference>
        <reference anchor="RFC8873" target="https://www.rfc-editor.org/info/rfc8873" quoteTitle="true" derivedAnchor="RFC8873">
          <front>
            <title>Message Session Relay Protocol (MSRP) over Data Channels</title>
            <author initials="A." surname="Narayanan" fullname="Anant Narayanan">
						<organization/> initials="JM." surname="Recio" fullname="Jose Recio" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Aboba" fullname="Bernard Aboba">
						<organization/> initials="C" surname="Holmberg" fullname="Christer Holmberg">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8873"/>
          <seriesInfo name="DOI" value="10.17487/RFC8873"/>
        </reference>
        <reference anchor="T38" target="https://www.itu.int/rec/T-REC-T.38-201511-I/en" quoteTitle="true" derivedAnchor="T38">
          <front>
            <title>Procedures for real-time Group 3 facsimile communication over IP networks</title>
            <author>
              <organization showOnFrontPage="true">International Telecommunication Union</organization>
            </author>
            <date month="November" year="2015"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="T.38"/>
        </reference>
        <reference anchor="WebRtcAPI" target="https://www.w3.org/TR/webrtc/" quoteTitle="true" derivedAnchor="WebRtcAPI">
          <front>
            <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
            <author initials="T." surname="Brandstetter" fullname="Taylor Brandstetter">
						<organization/> initials="C." surname="Jennings" fullname="Cullen Jennings">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." initials="H." surname="Boström" fullname="Henrik Boström">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J-I." surname="Bruaroey" fullname="Jan-Ivar Bruaroey">
						<organization/>
              <organization showOnFrontPage="true"/>
            </author>
					<date month="September" day="27" year="2018"/>
            <date/>
          </front>
				<seriesInfo name="World Wide Web Consortium CR" value="CR-webrtc-20180927"/>
				<format type="HTML" target="https://www.w3.org/TR/2018/CR-webrtc-20180927"/>
          <refcontent>W3C Proposed Recommendation</refcontent>
        </reference>
      </references>
    </references>
    <section title="Generic anchor="generic-out-of-band-aspects" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-generic-data-channel-negoti">Generic Data Channel Negotiation Aspects When when Not Using DCEP" anchor="generic-out-of-band-aspects">
			<t>This DCEP</name>
      <t indent="0" pn="section-appendix.a-1">This appendix summarizes how data channels work in general and discusses
   some key aspects, which aspects that should be considered for the out-of-band negotiation of data
   channels if DCEP is not used.</t>
			<t>A
      <t indent="0" pn="section-appendix.a-2">A WebRTC application creates a data channel
   by providing a number of setup parameters (subprotocol, label,
   maximal number of retransmissions, maximal retransmission time, order of delivery,
   priority). The application also specifies
   if whether
   it wants to make use of the negotiation using the DCEP
   <xref target="I-D.ietf-rtcweb-data-protocol"/>, target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/> or if the application
   intends to negotiate data channels using the SDP offer/answer protocol.</t>
			<t>In
      <t indent="0" pn="section-appendix.a-3">In any case, the SDP offer generated by the application is per
   <xref target="I-D.ietf-mmusic-sctp-sdp"/>. target="RFC8841" format="default" sectionFormat="of" derivedContent="RFC8841"/>. In brief, it contains one
   "m"
   "m=" line for the SCTP association on top of which the data channels will run:</t>
			<figure align="left" title="">
				<artwork align="left"><![CDATA[ run:
</t>
      <sourcecode name="app-a-sdp-example" type="sdp" markers="false" pn="section-appendix.a-4">
m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 192.0.2.1
a=max-message-size:100000
a=sctp-port:5000
a=tls-id:abc3de65cddef001be82
a=setup:actpass
a=fingerprint:SHA-1 \
    4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
]]></artwork>
			</figure>
			<t>Note:
    4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB</sourcecode>
      <aside pn="section-appendix.a-5">
        <t indent="0" pn="section-appendix.a-5.1">Note: A WebRTC application will only use "m" the "m=" line format "webrtc-datachannel", "webrtc-datachannel"
   and will not use other formats in the "m" "m=" line for other protocols
   such as t38. T.38 <xref target="I-D.ietf-mmusic-sctp-sdp"/> target="T38" format="default" sectionFormat="of" derivedContent="T38"/>.
   <xref target="RFC8841" format="default" sectionFormat="of" derivedContent="RFC8841"/> supports only one SCTP
   association to be established on top of a DTLS association.
        </t>
			<t>Note:
      </aside>
      <aside pn="section-appendix.a-6">
        <t indent="0" pn="section-appendix.a-6.1">Note: The above SDP media description does not contain any channel-specific
   information.</t>
      </aside>
      <section title="Stream anchor="si_num" numbered="true" removeInRFC="false" toc="include" pn="section-a.1">
        <name slugifiedName="name-stream-identifier-numbering">Stream Identifier Numbering" anchor="si_num">
				<t>Independently Numbering</name>
        <t indent="0" pn="section-a.1-1">Independently from the requested type of negotiation, the application
    creating a data channel can either pass (1) pass the stream identifier to the data channel stack to assign
    to the data channel or else let (2) let the data channel stack pick
    one identifier from the unused ones.</t>
				<t>To
        <t indent="0" pn="section-a.1-2">Moreover, to avoid glare situations <xref target="RFC3264"/>, target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/>, each endpoint can moreover own an
    exclusive set of stream identifiers, in which case an endpoint can
    only create a data channel with a stream identifier it owns.</t>
				<t>Which
        <t indent="0" pn="section-a.1-3">Which set of stream identifiers is owned by which endpoint is
    determined by convention or other means.

     <list style="hanging">
						<t>Note:For

        </t>
        <aside pn="section-a.1-4">
          <t indent="0" pn="section-a.1-4.1">Note: For data channels negotiated with the DCEP, one endpoint owns by
      convention the even stream identifiers, whereas the other owns the
      odd stream identifiers, as defined in
      <xref target="I-D.ietf-rtcweb-data-protocol"/>.</t>
						<t>Note:For target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>.</t>
        </aside>
        <aside pn="section-a.1-5">
          <t indent="0" pn="section-a.1-5.1">Note: For data channels negotiated via  different a protocol  from other than DCEP,
      no convention is defined by default.</t>
					</list>
				</t>
        </aside>
      </section>
      <section title="Generic anchor="sec-gen-ext-neg" numbered="true" removeInRFC="false" toc="include" pn="section-a.2">
        <name slugifiedName="name-generic-data-channel-negotia">Generic Data Channel Negotiation Not Using DCEP" anchor="sec-gen-ext-neg"> DCEP</name>
        <section title="Overview">
					<t>DCEP numbered="true" removeInRFC="false" toc="include" pn="section-a.2.1">
          <name slugifiedName="name-overview">Overview</name>
          <t indent="0" pn="section-a.2.1-1">DCEP negotiation only provides for negotiation of data channel
     transport parameters and does not provide for negotiation of subprotocol
     specific
     subprotocol-specific parameters. DCEP-less Non-DCEP data channel negotiation can be defined to
     allow negotiation of parameters beyond those handled by DCEP,
     e.g., parameters specific to the subprotocol instantiated on a
     particular data channel.</t>
					<t>The
          <t indent="0" pn="section-a.2.1-2">The following procedures are common to all methods of data channel
     negotiation not using DCEP, whether in-band (communicated using proprietary means on
     an already established already-established data channel) or out-of-band (using the SDP
     offer/answer mechanism or
     some other protocol associated with the signaling channel).</t>
        </section>
        <section title="Opening anchor="ext_open" numbered="true" removeInRFC="false" toc="include" pn="section-a.2.2">
          <name slugifiedName="name-opening-a-data-channel">Opening a Data Channel" anchor="ext_open">
					<t>In Channel</name>
          <t indent="0" pn="section-a.2.2-1">In the case of DCEP-less non-DCEP negotiation, the endpoint application has the
     option to fully control the stream identifier assignments. However However,
     these assignments have to coexist with the assignments controlled by
     the data channel stack for the DCEP negotiated data channels negotiated using DCEP (if
     any). It is the responsibility of the application to ensure consistent
     assignment of stream identifiers.</t>
					<t>When
          <t indent="0" pn="section-a.2.2-2">When the application requests that the creation of a new data channel to
     be set up via DCEP-less non-DCEP negotiation, the data channel stack creates
     the data channel locally without sending any DATA_CHANNEL_OPEN message messages
     in-band.
     However, even if the ICE (Interactive Connectivity Establishment),
     DTLS
     DTLS, and SCTP procedures were already successfully
     completed, the application can't send data on this data channel until the
     negotiation is complete with the peer. peer is complete. This is because the peer needs
     to be aware of and accept the usage of this data channel. The
     peer, after accepting the data channel offer, can start sending data
     immediately. This implies that the offerer may receive data channel
     subprotocol messages
     before the negotiation is complete complete, and the application should be
     ready to handle it.</t>
					<t>If
          <t indent="0" pn="section-a.2.2-3">If the peer rejects the data channel part of the offer offer, then it
     doesn't have to do anything anything, as the data channel was not created using
     the stack. The offerer offerer, on the other hand hand, needs to close the data
     channel that was opened by invoking relevant data channel stack API
     procedures.</t>
					<t>It
          <t indent="0" pn="section-a.2.2-4">It is also worth noting that a data channel stack implementation may
     not provide any API APIs to create and close data channels; instead instead, the
     data channels may be used on the fly as needed needed, just by communicating
     via non-DCEP means or by even by having some local configuration/assumptions
     on both of the peers.</t>
					<t>The
          <t indent="0" pn="section-a.2.2-5">The application then negotiates the data channel
     properties and subprotocol properties with the peer's application
     using a mechanism different from DCEP.</t>
					<t>The
          <t indent="0" pn="section-a.2.2-6">The peer then symmetrically creates a data channel
     with these negotiated data channel properties. This is the only way
     for the peer's data channel stack to know which properties to apply
     when transmitting data on this channel.
     The data channel stack must
     allow data channel creation with any non-conflicting nonconflicting stream identifier
     so that both peers can create the data channel with the same
     stream identifier.
          </t>
        </section>
        <section title="Closing numbered="true" removeInRFC="false" toc="include" pn="section-a.2.3">
          <name slugifiedName="name-closing-a-data-channel-2">Closing a Data Channel">
					<t>When Channel</name>
          <t indent="0" pn="section-a.2.3-1">When the application requests the closing of a
     data channel negotiated without DCEP,
     the data channel stack always performs an SCTP SSN
     reset
     Reset for this channel.</t>
					<t>Depending
          <t indent="0" pn="section-a.2.3-2">Depending upon the method used for DCEP-less non-DCEP negotiation and the
     subprotocol associated with the data channel, the closing of the data channel might in
     addition also be signaled to the peer via SDP offer/answer negotiation.</t>
        </section>
      </section>
			<!-- sec-gen-ext-neg -->
		</section>
		<!-- generic-out-of-band-aspects -->
    </section>
    <section anchor="acknowledgements" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.b-1">The authors wish to acknowledge the borrowing of ideas from other
   draft documents by <contact fullname="Salvatore Loreto"/>, <contact fullname="Gonzalo Camarillo"/>, <contact fullname="Peter Dunkley"/>, and
   <contact fullname="Gavin Llewellyn"/>. The authors also wish to thank <contact fullname="Flemming Andreasen"/>, <contact fullname="Christian Groves"/>,
   <contact fullname="Gunnar Hellström"/>, <contact fullname="Paul    Kyzivat"/>, <contact fullname="Jonathan Lennox"/>,
   <contact fullname="Uwe Rauschenbach"/>, and <contact fullname="Roman Shpount"/> for their invaluable comments.</t>
      <t indent="0" pn="section-appendix.b-2">Special thanks to <contact fullname="Christer Holmberg"/> for helping
      finish the document and cleaning up <xref target="section_procedures" format="default" sectionFormat="of" derivedContent="Section 6"/>.
</t>
    </section>
    <section anchor="contributors" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-contributors">Contributors</name>
      <t indent="0" pn="section-appendix.c-1"><contact fullname="Juergen Stoetzer-Bradler"/> made significant
      contributions to this document and should be considered a coauthor.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="K." surname="Drage" fullname="Keith Drage">
        <organization showOnFrontPage="true">Unaffiliated</organization>
        <address>
          <email>drageke@ntlworld.com</email>
        </address>
      </author>
      <author initials="M." surname="Makaraju" fullname="Maridi R. Makaraju (Raju)">
        <organization showOnFrontPage="true">Unaffiliated</organization>
        <address>
          <email>mmraju@gmail.com</email>
        </address>
      </author>
      <author fullname="Richard Ejzak" initials="R." surname="Ejzak">
        <organization showOnFrontPage="true">Unaffiliated</organization>
        <address>
          <email>richard.ejzak@gmail.com</email>
        </address>
      </author>
      <author fullname="Jerome Marcon" initials="J." surname="Marcon">
        <organization showOnFrontPage="true">Unaffiliated</organization>
        <address>
          <email>jeromee.marcon@free.fr</email>
        </address>
      </author>
      <author initials="R." surname="Even" fullname="Roni Even" role="editor">
        <organization showOnFrontPage="true"/>
        <address>
          <email>ron.even.tlv@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>