Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - language indication

[Christer Holmberg <[e-mail]>]

Hi Gunnar,

12. At the end of 3.2, add the following about language negotiation
 
>>>> The users may be interested to negotiate language to use during the
>>>> real-time text session. This is done by including specifications of
>>>> language capabilities in the media descriptors for the t140 data
>>>> channels by use of dsca attributes hlang-send and hlang-recv
>>>> according to RFC 8373 [RFC8373]. The format is as follows:
>>>> a=dsca:id hlang-send:language
>>>> a=dsca:id hlang-send:language
>>>> The negotiation is performed as indicated in RFC8373.
>>> Whoops, there was a copy-paste error there. the second dsca attribute was intended to be:
>>>
>>> a=dsca:id hlang-recv:language
>>> also, the value may be a list of space separated language tags, so it would be more correct to say:
>>>
>>> a=dsca:id hlang-send:language(s)
>>> a=dsca:id hlang-recv:language(s)
>>>
>>> This is a bit informal way to specify the format. Do you think it is acceptable? The reader should 
>>> anyway look into RFC 8373 for the complete specification.
>> I don't think we need to say anything how to specify. draft-data-channel-sdpneg defines how to convey
>> SDP attributes in the dsca attribute, and 8873 defines the format of the hdland-send/recv attributes.
> We could include an example instead.

Yes.

---

12a: Allow use of hlang- attributes together with m=application media declarations
  
>>>>> RFC 8373 has a statement in section 5.3 saying:
>>>>> "This document does not define the use of language tags in media
>>>>> other than interactive streams of audio, video, and text (such as "message" or "application").
>>>>> Such use could be supported by future work or by application agreement."
>>>>>
>>>>> The reason for this limitation is that it must be clear for what
>>>>> modality (spoken or written or signed ) the language is intended to
>>>>> be used. For audio, text and video, RFC 8373 defines the implicit
>>>>> relation audio=spoken, text=written, video=signed, but for
>>>>> "application" there is no such implicit relation and it is in our case the subprotocol T140 that
>>>>> we can be sure carries written language modality. So, we just need to specify in the draft that
>>>>> for media "application  / webrtc-datachannel" and subprotocol "t140", the language modality
>>>>> is "written".  It may in fact be evident from the context.
>>>> I will look into it, but it seems like a useful clarification to make.
>>> Yes, it may be sufficient with a clear statement that for m=application / webrtc-datachannel
>>> subprotocol T140, language indications according to RFC 8373 are allowed and indicate written
>>> language media. But that is a kind of extension over what RFC 8373 specified because the use
>>> for a=application was excluded there. Do we need to make IANA aware of that extension in some way?
>> Not sure about IANA, but it might be an update to 8373.
>>
>> The problem is that we are not defining usage of the lang attributes, and modality, for the 'application/webrtc-datachannel' media type: 
>> we are defining modality and usage of the attributes for a specific data channel.
>>
>> So, maybe something like:
>>
>>       "This document updates RFC 8373, by defining how the SDP hlang-send and hlang-recv attributes are used for
>>         the "application/webrtc-datachannel" media type.
>>
>>        SDP endpoints MUST NOT include the attributes directly in the m= section associated with the
>>        'application/webrtc-datachannel' media type. Instead, the attributes MUST be associated with
>>        individual data channels, using the  SDP dcsa attribute. A specification that defines a subprotocol
>>        that uses the attributes MUST specify the modality for that subprotocol.
>>
>>        For T.140 data channels the modality is 'written'."
>    
>    This works for the T140 data channel, but another subprotocol may be 
>    able to carry more than one media type and therefore have some other 
>    indication of what media type is used. An example is the msrp data 
>    channel that can carry messages with different modalities.
  
Sure, and the text says that each subprotocol specification need to define what the modality is.

(Of course, it would have been great if 8373 would have defined a way to explicitly indicate the modality, instead of implicitly retrieve it from the media type.)

>    So, yes, it is tempting to say that we extend RFC 8373 in general, but 
>    we can do in in a fully specified way only for the T140 data channel.
>    
>    How would you express that?

Using the suggested text above :)

- It updates 8373 by allowing usage of the lang attributes for application/webrtc-datachannel media types.
- It updates draft-data-channel-sdpneg, by indicating that the modality must be defined for each data channel that
  uses the lang attributes. In draft-t140-data-channel we then define the modality for T.140 data channels.

Regards,

Christer