text: draft-ietf-mmusic-data-channel-sdpneg-06
  10.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05'
  10.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04'
  10.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03'
  10.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02'
  10.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01'
  10.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00'
  10.7. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02'
  10.8. Changes against '-01'
  10.9. Changes against '-00'
  This document makes use of MSRP in many of the 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 sub-protocol such as MSRP will be documented elsewhere. The use of MSRP in some examples is only to show how the generic procedures described herein might apply to a specific sub-protocol.
  As the usage of multiple SCTP associations on top of a single DTLS connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no "a=dcmap:" attribute multiplexing rules are specified for the UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. This document does also not specify multiplexing rules for this attribute for SCTP or SCTP/DTLS proto values. If future extensions of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of multiple SCTP associations on top of a single DTLS connection, 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, for instance in an extension of this SDP based data channel negotiation specification.
  The 'subprotocol' parameter indicates which protocol the client expects to exchange via the channel. This parameter maps to the 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. Section 8.1 specifies how new sub-protocol parameter values are registered. 'Subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its value defaults to the empty string.
  In the SDP, each data channel declaration MAY also be followed by other media level SDP attributes, which are either specifically defined for or applied to the sub-protocol in use. Each of these attributes is represented by one new attribute line, and it includes the contents of a media-level SDP attribute already defined for use with this (sub-)protocol in another IETF specification. Sub-protocol specific attributes MAY also be defined for exclusive use with data channel transport, but SHOULD use the same syntax described here for other sub-protocol related attributes.
  Each sub-protocol related SDP attribute that would normally be used to negotiate the sub-protocol using SDP is replaced with an attribute of the form "a=dcsa:stream-id original-attribute", where dcsa stands for "data channel sub-protocol attribute", stream-id is the SCTP stream identifier assigned to this sub-protocol instance, and original-attribute represents the contents of the sub-protocol related attribute to be included.
  Thus in the example above, the original attribute line "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 sub-protocol being transported on the SCTP association using the data channel with stream id 2 accepts plain text files.
  The SDP answer SHALL echo the same sub-protocol, 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.
  Registration of new sub-protocol identifiers is performed using the existing IANA table "WebSocket Subprotocol Name Registry".
  In Section 5.1.2.1 replacement of "Thus in the example above, the original attribute line "a=accept- types:text/plain" is represented by the attribute line "a=dcsa:2 accept-types:text/plain", which specifies that this instance of MSRP being transported on the SCTP association using the data channel with stream id 2 accepts plain text files." with "... which specifies that this instance of the MSRP sub-protocol being transported ...".
  Section 5.1.2's headline was "Sub-Protocol Specific Attributes". Change of this headline to "Other Media Level Attributes" and adaptations of the first paragraph of this section and the first paragraph of Section 5.1.2.1 in order to clarify that not only those attributes may be encapsulated in a "dcsa" attribute, which are specifically defined for the sub-protocol, but that also other attributes may be encapsulated if they are related to the specific sub-protocol instance.
  [I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C. and E. Rescorla, Javascript Session Establishment Protocol", Internet-Draft draft-ietf-rtcweb-jsep-12, October 2015.