Subject: Re: [MMUSIC] Data channel dcsa attribute usage and IANA - change in 4566bis

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Aug 2019 16:39:16 +0000

Hi,

>>>> I think that dcsa(subprotocol) would have been enough, at least 
>>>> based on channel-sdpneg document, maybe Paul can help
>>>     
>>>     I'm sorry that this is coming up so late. In retrospect I think it
>>>     deserved more discussion about how this is to work. IIRC this got tucked
>>>     in quite some time ago, early in the definition of dcsa.
>>>     
>>>     I don't recall why both forms are shown. I don't know what "dcsa" alone
>>>>     would mean. The guess it could be a wildcard meaning that it can be used
>>>     with all subprotocols. But that doesn't make any sense to me.
>>    
>> I was also first thinking whether dcsa without subprotocol it was some kind 
>> of "wildcard", but there is no such thing defined in data-channel-sdpneg: each 
>> subprotocol will have to define register its usage of attributes inside dcsa.
>> 
>>>     So I'm inclined to only use the "dcsa(subprotocol)" form. Perhaps we
>>>     should file an errata against rfc4566bis as soon as it becomes an RFC.
>>    
>> Isn't this a fix that the RFC Editor can be requested to do? There is no reason 
>> to bring the draft back to the WG etc.
>> 
>> After all, this is not a technical change, only an administrative.
>
> Yes, I think so.
>
> I was just now reviewing IANA changes for 4566bis, and asked them to 
> change "dcsa, dcsa(setup)" to "dcsa(setup)".

In section 8.2.4.1, you also need to modify the following bullet:

   o  Usage Level: Usage level(s) of the attribute.  This MUST be one or
      more of the following: session, media, source, dcsa and
      dcsa(subprotocol).  For a definition of source level attributes,
      see [RFC5576].  For a definition of dcsa attributes see:
      [I-D.ietf-mmusic-data-channel-sdpneg].

s/dcsa and dcsa(subprotocol)/dcsa(subprotocol)

Regards,

Christer

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Aug 2019 13:14:05 -0400

> s/dcsa and dcsa(subprotocol)/dcsa(subprotocol)

I guess it is a question of whether this sort of change can be made 
during Auth48.

Flemming? Adam?

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Fri, 30 Aug 2019 09:02:54 +0300

Hi,
I think that dcsa level is valid for general use of an attribute and this
can be specified in a general document and not for a specific sub protocol
Roni

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Christer
> Holmberg
> Sent: Thursday, August 29, 2019 7:39 PM
> To: Paul Kyzivat; [email-masked]
> Subject: Re: [MMUSIC] Data channel dcsa attribute usage and IANA - change
in
> 4566bis
> >> I was also first thinking whether dcsa without subprotocol it was
> >> some kind of "wildcard", but there is no such thing defined in
> >> data-channel-sdpneg: each subprotocol will have to define register its
usage
> of attributes inside dcsa.
> >>
> >> Isn't this a fix that the RFC Editor can be requested to do? There is
> >> no reason to bring the draft back to the WG etc.
> >>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Aug 2019 06:28:33 +0000

Hi,

>    can be specified in a general document and not for a specific sub protocol
 
That is not described anywhere.

My suggestion is that the only "general use" data channel attributes are dcmap and dcsa. But, anything inside a dcsa attribute needs to be registered for a specific subprotocol.

Regards,

Christer
    
    in
    usage

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 30 Aug 2019 11:23:01 +0200

Hi,

Let me introduce another example to check if realistic cases are well 
covered:

I think that there are a number of existing attributes on media level 
that would be applicable on dcsa level without any extra specification. 
They cannot be called "subprotocol specific" as sdpneg requires IANA 
registration for. Can we use such attributes right away in a dcsa 
attribute without registration?

An example may be the mid attribute on media level, used together with 
the group session level attribute, both specified in RFC 5888.

We could want to use it to indicate that an RTP media and a data channel 
are alternatives and do not need to be both accepted.

E.g. a total conversation application offers a video stream, an audio 
stream, an RTP text media stream with type t140 and a T.140 data channel 
under application/webrtc-datachannel media subprotocol t140.

The two t140 streams should be seen as alternatives, so it would be 
desirable to define two groups, one with video audio and RTP text media 
and another group with video audio and T.140 data channel, and let the 
answering party decide which group to accept. For this, we would need to

Do we need to IANA register such attributes ( as "mid" in this example ) 
for use together with a specific media and subprotocol even if the use 
follows the generally intended pattern? If so, each specified data 
channel subprotocol must make an analysis of all already defined sdp 
attributes and try to assess their applicability for the subprotocol.

Is there anything in current drafts or RFCs claiming that we need or do 
not need to register such use?

Regards

Gunnar

--

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Aug 2019 09:40:28 +0000

Hi,

Based on the discussions we've had, my understanding is that you do need to register each attribute for the subprotocol where you want to use it.

IF we want to register attributes that ANY subprotocol by default can use, that should have been done in the data-channel-sdpneg draft.

Regarding 'mid' and grouping of data channels, I think that shall be done in a separate draft, as a separate task. Such draft can then update the registry for whatever subprotocols (t140 etc) that may use it.

Regards,

Christer

On 30/08/2019, 12.23, "Gunnar Hellström" <[email-masked]> wrote:

    Hi,

    

    

    
    Regards
    
    Gunnar

    --

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Aug 2019 10:59:22 -0400

> Regarding 'mid' and grouping of data channels, I think that shall be done in a separate draft, as a separate task. Such draft can then update the registry for whatever subprotocols (t140 etc) that…

I agree.

MID is an interesting case. Working out how data channels fit into the 
grouping framework is going to take some work and specification. We 
shouldn't assume it is obvious and implicit.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Aug 2019 15:43:11 +0000

Hi,

>> Regarding 'mid' and grouping of data channels, I think that shall be done in a separate draft, as a separate task. Such draft can then update the 
>> registry for whatever subprotocols (t140 etc) that may use it.
>
> I agree.
>
> MID is an interesting case. Working out how data channels fit into the grouping framework is going to take some work and
> specification. We shouldn't assume it is obvious and implicit.

I was actually thinking about grouping of data channels at some point. In my opinion including a 'mid' attribute in a 'dcsa' attribute would not be the right way, as the grouping is for the whole data channel and not only the subprotocol. Instead there should be a new 'did' (data channel id) attribute that can be used directly, similar to dcmap and dcsa.

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 30 Aug 2019 23:33:13 +0200

Hi,

>> specification. We shouldn't assume it is obvious and implicit.
Right, the discussion below shows part of the complexity.
> I was actually thinking about grouping of data channels at some point. In my opinion including a 'mid' attribute in a 'dcsa' attribute would not be the right way, as the grouping is for the whole d…

Well, maybe, but then the values of 'mid' and 'did' must share the same 
value space, so that a stream in a specific data channel with a specific 
subprotocol specified in an m-section can be specified to be an 
alternative to a classic media stream specified in a media declaration. 
( like my example)

Why could the 'mid' not be specified for the right m-section and then a 
rule saying that the SCTP media declaration needs to be included when 
the grouping is evaluated to form the final SDP.

Anyway --- we will not solve this now.

Or maybe we can use the grouping and 'mid' attributes as you say on the 
SCTP media level for a case where only one data channel is declared. It 
is only if we have more than one data channel specified that it gets 
complicated.

Regards

Gunnar

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Aug 2019 22:30:47 +0000

Hi,

>>>> Regarding 'mid' and grouping of data channels, I think that shall be 
>>>> done in a separate draft, as a separate task. Such draft can then update the registry for whatever subprotocols (t140 etc) that may use it.
>>> I agree.
>>>
>>> MID is an interesting case. Working out how data channels fit into 
>>> the grouping framework is going to take some work and specification. We shouldn't assume it is obvious and implicit.
>> I was actually thinking about grouping of data channels at some point. In my opinion including a 'mid' attribute in a 'dcsa' attribute 
>> would not be the right way, as the grouping is for the whole data channel and not only the subprotocol. Instead there should be a 
>> new 'did' (data channel id) attribute that can be used directly, similar to dcmap and dcsa.
>
> Well, maybe, but then the values of 'mid' and 'did' must share the same value space, so that a stream in a specific data channel with
> a specific subprotocol specified in an m-section can be specified to be an alternative to a classic media stream specified in a media declaration. 
> ( like my example)
>
> Why could the 'mid' not be specified for the right m-section and then a rule saying that the SCTP media declaration needs to be included
> when the grouping is evaluated to form the final SDP.
>
> Or maybe we can use the grouping and 'mid' attributes as you say on the SCTP media level for a case where only one data channel 
> is declared. It is only if we have more than one data channel specified that it gets complicated.

I assume you can use 'mid' with an SCTP m= section already today. I don't think RFC 5888 restricts it RTP. Obviously you may have to define a new 'group' attribute token that fits the semantic of your group,

Regards,

Christer