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

[Gunnar Hellström <[e-mail]>]

Hi,

I have found some text in sdpneg that seems to be intended for keeping 
the work reasonable regarding dcsa attribute registration, when a new 
data channel is specified.

It is for example section 5.2.1 "DCSA Syntax" in 
draft-ietf-mmusic-data-channel-sdpneg

saying:
"

It is assumed that in general the usages of subprotocol related media
    level attributes are independent from the subprotocol's transport
    protocol.  Such 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" attribute.

"
It seems as if we can identify a subprotocol that is used earlier with 
some other transport, and now is to be specified for a webrtc data 
channel transport, then the attributes used before can also be used for 
the data channel by using a dcsa attribute. Registration seems not be 
needed.

Examples used are bfcp and msrp.

We are now discussing a T.140 data channel for Real-Time text.

I get the impression that attributes that can be used with the 
RTP/TEXT/t140  RTP transport (RFC 4103) related to the presentation and 
application level can be applied and used also in a dcsa attribute in a 
T.140 data channel sdp declaration.

The protocol name t140 is used for both RTP and data channel transports.

It seems to me that the information in the introduction of 
draft-holmberg-mmusic-t140-usage-data-channel would be sufficient to 
indicate that attributes possible to use for RFC 4103 are directly 
usable in an SDP specification of a T.140 data channel. Right?

hlang-send and hlang-recv attributes are exceptions, because it needs to 
be specified that application/webrtc-datachannel/t140 is carrying 
written language modality.

But for other media level attributes usable together with text/t140 
media would be usable together with application/webrtc-datachannel/t140 
channels without registration.  a practical example could be RFC 4796 
media contents attribute.

Regards

Gunnar






Den 2019-08-31 kl. 00:30, skrev Christer Holmberg:
> 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.
>>>> 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.
>>> 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 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.
>>
>> 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.
> 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
>
>     
>     
>>> On 30/08/2019, 12.23, "Gunnar Hellström" <[e-mail]> wrote:
>>>
>>>        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
>>>        
>>>        Den 2019-08-30 kl. 08:28, skrev Christer Holmberg:
>>>        > 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
>>>        >
>>>        > 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
>>>        >
>>>        >      > -----Original Message-----
>>>        >      > From: mmusic [mailto:[e-mail]] On Behalf Of Christer
>>>        >      > Holmberg
>>>        >      > Sent: Thursday, August 29, 2019 7:39 PM
>>>        >      > To: Paul Kyzivat; [e-mail]
>>>        >      > Subject: Re: [MMUSIC] Data channel dcsa attribute usage and IANA - change
>>>        >      in
>>>        >      > 4566bis
>>>        >      >
>>>        >      > 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
>>>        >      > _______________________________________________
>>>        >      > mmusic mailing list
>>>        >      > [e-mail]
>>>        >      > https://www.ietf.org/mailman/listinfo/mmusic
>>>        >
>>>        >
>>>        >
>>>        > _______________________________________________
>>>        > mmusic mailing list
>>>        > [e-mail]
>>>        > https://www.ietf.org/mailman/listinfo/mmusic
>>>        
>>>        --
>>>        
>>>        
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> --
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> [e-mail]
> [phone]
>
-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]