--- 1/draft-ietf-mmusic-data-channel-sdpneg-25.txt 2019-04-23 02:13:10.032699299 -0700 +++ 2/draft-ietf-mmusic-data-channel-sdpneg-26.txt 2019-04-23 02:13:10.112701390 -0700 @@ -1,24 +1,24 @@ MMUSIC K. Drage Internet-Draft Unaffiliated Intended status: Standards Track M. Makaraju -Expires: September 20, 2019 Nokia +Expires: October 25, 2019 Nokia R. Ejzak J. Marcon Unaffiliated R. Even, Ed. Huawei - March 19, 2019 + April 23, 2019 SDP-based Data Channel Negotiation - draft-ietf-mmusic-data-channel-sdpneg-25 + draft-ietf-mmusic-data-channel-sdpneg-26 Abstract 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. Status of This Memo @@ -29,21 +29,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 20, 2019. + This Internet-Draft will expire on October 25, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,92 +58,92 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 5. SDP Data Channel Attributes . . . . . . . . . . . . . . . . . 6 5.1. SDP DCMAP Attribute . . . . . . . . . . . . . . . . . . . 6 5.1.1. DCMAP Attribute Syntax . . . . . . . . . . . . . . . 6 5.1.2. Dcmap-stream-id Parameter . . . . . . . . . . . . . . 8 5.1.3. Label Parameter . . . . . . . . . . . . . . . . . . . 8 5.1.4. Subprotocol Parameter . . . . . . . . . . . . . . . . 8 - 5.1.5. Max-retr Parameter . . . . . . . . . . . . . . . . . 8 + 5.1.5. Max-retr Parameter . . . . . . . . . . . . . . . . . 9 5.1.6. Max-time Parameter . . . . . . . . . . . . . . . . . 9 5.1.7. Ordered Parameter . . . . . . . . . . . . . . . . . . 9 5.1.8. Priority Parameter . . . . . . . . . . . . . . . . . 9 - 5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 9 + 5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 10 5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10 - 5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 10 + 5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 11 5.2.2. DCSA Multiplexing Category . . . . . . . . . . . . . 12 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 6.1. Managing Stream Identifiers . . . . . . . . . . . . . . . 13 6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13 6.3. Generating the Initial Offer for A Data Channel . . . . . 14 6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14 - 6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 14 + 6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 15 6.6. Modifying the Session . . . . . . . . . . . . . . . . . . 15 - 6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 15 + 6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 16 6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 16 - 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 19 - 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19 - 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 19 - 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 20 - 9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 20 + 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 20 + 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 20 + 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 20 + 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 - 12. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 12. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 22 12.1. Changes against 'draft-ietf-mmusic-data-channel- - sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 21 + sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 22 + 12.2. Changes against 'draft-ietf-mmusic-data-channel- - sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 21 + sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 22 12.3. Changes against 'draft-ietf-mmusic-data-channel- - sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 21 + sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 22 12.4. Changes against 'draft-ietf-mmusic-data-channel- - sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 21 + sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 22 12.5. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 22 12.6. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 22 12.7. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 23 12.8. Changes against 'draft-ietf-mmusic-data-channel- - sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 23 + sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 24 12.9. Changes against 'draft-ietf-mmusic-data-channel- - sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 23 + sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 24 12.10. Changes against 'draft-ietf-mmusic-data-channel- - sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 23 + sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 24 12.11. Changes against 'draft-ietf-mmusic-data-channel- - sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 24 + sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 25 12.12. Changes against 'draft-ietf-mmusic-data-channel- - sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 25 + sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 26 12.13. Changes against 'draft-ietf-mmusic-data-channel- - sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 26 + sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 27 12.14. Changes against 'draft-ietf-mmusic-data-channel- - sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 27 + sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 28 12.15. Changes against 'draft-ietf-mmusic-data-channel- - sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 29 + sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 30 12.16. Changes against 'draft-ejzak-mmusic-data-channel- - sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 32 - 12.17. Changes against '-01' . . . . . . . . . . . . . . . . . 33 - 12.18. Changes against '-00' . . . . . . . . . . . . . . . . . 33 + sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 33 + 12.17. Changes against '-01' . . . . . . . . . . . . . . . . . 34 + 12.18. Changes against '-00' . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . 34 - 13.2. Informative References . . . . . . . . . . . . . . . . . 35 + 13.2. Informative References . . . . . . . . . . . . . . . . . 36 Appendix A. Generic Data Channel Negotiation Aspects When Not Using DCEP . . . . . . . . . . . . . . . . . . . . . 36 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 37 - A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 37 - A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37 - A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 37 - A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 38 + A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 38 + A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 38 + A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 38 + A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction The concept of establishing a bi-directional data channel running on top of the Stream Control Transmission Protocol (SCTP) is in [I-D.ietf-rtcweb-data-channel] allowing applications to use data channels. An in-band Data Channel Establishment Protocol (DCEP) is in [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of- band protocols may be used for establishing data channels. Each data @@ -191,22 +191,22 @@ Data channel stack: An entity which, upon application request, runs the data channel protocol to keep track of states, sending and receiving data. If the application is a browser based JavaScript application then this stack resides in the browser. If the application is a native application then this stack resides in the application and is accessible via some sort of APIs. Data channel properties: 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...). + channel (e.g., stream identifier, reliability, order of delivery, + etc.). Data channel subprotocol: The application protocol which is transported over a single data channel. Data channel subprotocol messages are sent as data channel payload over an established data channel. 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 and data channel subprotocol properties. In this case the data channel subprotocols may be identified by the values of the "subprotocol" parameters of the SDP "a=dcmap" attribute as @@ -325,38 +325,50 @@ 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 Note: The last example (a=dcmap:4) shows a 'label' parameter value which contains one non-printable 'escaped-char' character (the tabulator character). Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one - 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be + 'maxretr-opt' parameter or one 'maxtime-opt' parameter may be present. Both MUST NOT be present. 5.1.2. Dcmap-stream-id Parameter The 'dcmap-stream-id' parameter indicates the SCTP stream identifier within the SCTP association used to form the data channel. 5.1.3. Label Parameter 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 [WebRtcAPI], an RTCDataChannel object from other RTCDataChannel objects. This parameter maps to the 'Label' parameter defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is optional. If it is not present, then its value defaults to the empty string. + In order to communicate with WEbRTC API the label attribute should: + + o Serialize the WebRTC label as a UTF-8 string [RFC3629]. + + o Treat the UTF-8 serialization as a series of bytes + + o For each byte in the serialization: + + * If the byte can be expressed as a `quoted-char`, do so + + * Otherwise, express the byte as an `escaped-char`. + Note: The empty string MAY also be explicitly used as a 'label' value, such that 'label=""' is equivalent to the 'label' parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 5.1.4. Subprotocol Parameter 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]. @@ -371,33 +383,33 @@ allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an empty string. 5.1.5. Max-retr Parameter 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 parameter is optional. If the max-retr parameter and the max-time parameter are not present, then reliable transmission is performed as specified in [RFC4960]. - This parameter maps to the 'Number of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 5.1.6. Max-time Parameter 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 given in milliseconds in the 'max-time' - parameter. The max-time parameter is optional. If the max-retr - parameter and the max-time parameter are not present, then reliable - transmission is performed as specified in [RFC4960]. This parameter - maps to the 'Lifetime in ms' parameter defined in + parameter. The life-time starts when providing the user message to + the protocol stack. The max-time parameter is optional. If the max- + retr parameter and the max-time parameter are not present, then + reliable transmission is performed as specified in [RFC4960]. This + parameter maps to the 'Lifetime in ms' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 5.1.7. Ordered Parameter 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 parameter is optional and takes two values: "true" for ordered and "false" for unordered delivery with "true" as the default value. Any other value is ignored and default "ordered=true" is assumed. In the absence of @@ -431,25 +443,24 @@ well, for instance in an extension of this SDP offer/answer based data channel negotiation specification. 5.2. SDP DCSA Attribute In the SDP media description, each data channel declaration MAY also be followed by other media level SDP attributes, which are either specifically defined for or applied to the subprotocol 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 (Internet Engineering - Task Force) document. Subprotocol specific attributes MAY also be - defined for exclusive use with data channel transport, but MUST use - the same syntax described here for other subprotocol related - attributes. + for use with this (sub)protocol in another IETF document. + Subprotocol specific attributes MAY also be defined for exclusive use + with data channel transport, but MUST use the same syntax described + here for other subprotocol related attributes. Each SDP attribute, related to the subprotocol, that would normally be used to negotiate the subprotocol using SDP offer/answer is replaced with an attribute of the form "a=dcsa:stream-id original- attribute", where dcsa stands for "data channel subprotocol attribute", stream-id is the SCTP stream identifier assigned to this subprotocol instance, and original-attribute represents the contents of the subprotocol related attribute to be included. The same syntax applies to any other SDP attribute required for @@ -477,20 +490,21 @@ Value: dcsa-value Usage Level: media Charset Dependent: no Syntax: dcsa-value = stream-id SP attribute + stream-id = 1*5DIGIT attribute = Example: a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" a=dcsa:2 accept-types:text/plain Note that the reference to [I-D.ietf-mmusic-rfc4566bis] defines where the attribute definition can be found; it does not provide any @@ -520,20 +534,30 @@ in a "a=dcsa" attribute. There may be cases, where the usage of a subprotocol related media level attribute depends on the subprotocol's transport protocol. In such cases the subprotocol related usage of the attribute is expected to be described for the data channel transport. A 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 Section 9.1. + 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 + /[I-D.ietf-mmusic-rfc4566bis] section-8.5) along with the dcsa usage + level. + 5.2.2. DCSA Multiplexing Category The multiplexing category of the "a=dcsa:" attribute is SPECIAL. As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no "a=dcsa:" attribute multiplexing rules are specified for the UDP/DTLS/SCTP and TCP/DTLS/SCTP 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 association, or @@ -562,23 +586,21 @@ The detailed offer/answer procedures for the dcsa attribute are dependent on the associated sub-protocol see Section 5.2. 6.1. Managing Stream Identifiers In order to avoid SCTP Stream identifier collisions, in alignment with [I-D.ietf-rtcweb-data-protocol], the endpoint acting as DTLS client (for the SCTP association used to realize data channels) MUST use even identifier values, and the endpoint acting as DTLS server - MUST use odd identifier values. SCTP stream identifiers associated - with data channels that have been negotiated using DCEP MUST NOT be - included in SDP offers and answers. + MUST use odd identifier values. SCTP stream identifiers associated with data channels that have been negotiated using DCEP MUST NOT be included in SDP offers and answers. 6.2. Negotiating Data Channel Parameters The data channel types defined in [I-D.ietf-rtcweb-data-protocol] are mapped to the dcmap SDP attribute parameters in the following manner where "ordered=true" is the default and may be omitted: @@ -662,30 +684,31 @@ o 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. o 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. - Note: DCEP is not used, that is neither the SDP offerer nor the SDP - answerer send an in-band DCEP DATA_CHANNEL_OPEN message. - 6.6. Modifying the Session When an offer sends a subsequent offer, that includes information for a previously negotiated data channel, unless the offerer intends to close the data channel (Section 6.6.1), the offerer SHALL include the previously negotiated SDP attributes and attribute values associated - with the data channel. + with the data channel. The answerer may reject the offer. The means + for rejecting an offer are dependent on the higher layer protocol. + + The offer/answer exchange is atomic; if the answer is rejected, the + session reverts to the state prior to the offer [RFC3264]. 6.6.1. Closing a Data Channel In order to close a data channel, the endpoint that wants to close SHALL send the SCTP SSN reset message [RFC6525], following the procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In addition, if the closed data channel was negotiated using the offer/ answer mechanism Section 6.3, the endpoint that closed the data channel SHALL send a subsequent offer in which it either: @@ -721,33 +744,33 @@ not known for the data channel transport case. * The receiver of such an SDP offer or answer SHOULD ignore this entire "a=dcsa" attribute line. 7. Examples SDP offer: m=application 10001 UDP/DTLS/SCTP webrtc-datachannel - c=IN IP6 IP6 2001:db8::3 + 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 IP6 2001:db8::1 + 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 Figure 1: Example 1 In the example in Figure 1 the SDP answerer rejected the data channel @@ -884,21 +907,21 @@ 9.2.1. dcmap NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC. This document defines a new SDP media-level attribute "a=dcmap:" as follows: +-----------------------+-------------------------------------------+ - | Contact name: | IESG Chairs | + | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | dcmap | | Attribute syntax: | As per Section 5.1.1 | | Attribute semantics: | As per Section 5.1.1 | | Usage level: | media | | Charset dependent: | No | | Purpose: | Define data channel specific parameters | | Appropriate values: | As per Section 5.1.1 | | O/A procedures: | As per Section 6 | | Mux category: | SPECIAL. See Section 5.1.9 | @@ -907,54 +930,35 @@ 9.2.2. dcsa NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC. This document defines a new SDP media-level attribute "a=dcsa:" as follows: +-----------------------+-------------------------------------------+ - | Contact name: | IESG Chairs | + | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | dcsa | | Attribute syntax: | As per Section 5.2.1 | | Attribute semantics: | As per Section 5.2.1 | | Usage level: | media | | Charset dependent: | No | | Purpose: | Define data channel subprotocol specific | | | attributes | | Appropriate values: | As per Section 5.2.1 | | O/A procedures: | As per Section 6 | | Mux category: | SPECIAL. See Section 5.2.2 | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ -9.3. New Usage Level - - This document introduces a new "Data Channel Subprotocol Attribute" - (dcsa) usage level of the SDP media description to the IANA SDP att- - field registry. 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 (Section 5.2.1), 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 Section 9.1) along with the dcsa usage level. E.g. - - +-----------------------+-------------------------------------------+ - | ... | ... | - | Usage level: | dcsa(msrp) | - | ... | ... | - +-----------------------+-------------------------------------------+ - 10. Contributors Juergen Stoetzer-Bradler co-authored this document. 11. Acknowledgments 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 @@ -1044,21 +1048,21 @@ o Addition of definition of "data channel subprotocol" to Section 3 as proposed on the MMUSIC list, https://www.ietf.org/mail- archive/web/mmusic/current/msg15827.html. o Addition of RFC4566bis draft to list of normative references. o Updates of tables in Section 9.2.1 and Section 9.2.2 as per section 8.2.4 of RFC4566bis draft. - o Addition of new Section 9.3. + o Addition of new "new-usage-level">. 12.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' o Addition of two new paragraphs to Section 5.2.1 regarding subprotocol attribute relationship with transport protocol. o Addition of a note to Section 9.1 regarding subprotocols simultaneously defined for data channel and Websocket usage. o Addition of two further SDP offer/answer considerations to @@ -1606,20 +1607,24 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November + 2003, . + [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control @@ -1628,27 +1633,27 @@ . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 13.2. Informative References [I-D.ietf-clue-datachannel] Holmberg, C., "CLUE Protocol data channel", draft-ietf- - clue-datachannel-15 (work in progress), August 2018. + clue-datachannel-17 (work in progress), April 2019. [I-D.ietf-mmusic-msrp-usage-data-channel] Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., Marcon, J., and J. Recio, "MSRP over Data Channels", - draft-ietf-mmusic-msrp-usage-data-channel-09 (work in - progress), May 2018. + draft-ietf-mmusic-msrp-usage-data-channel-10 (work in + progress), April 2019. [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, November 2006, . [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, .