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

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

Hi Christer,

Den 2019-08-26 kl. 09:30, skrev Christer Holmberg:
> 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.

Proposal:

Change 3.3. header from Example to Examples

Add at the end of 3.3 the following:

Another example is an offer for a T.140 data channel from an 
organisation offering real-time text conversation in Spanish and 
Esperanto, and an answer accepting Esperanto.

Offer:

  m=application 911 UDP/DTLS/SCTP webrtc-datachannel
        c=IN IP6 2001:db8::3
        a=max-message-size:1000
        a=sctp-port 5000
        a=dcmap:1 label="ACME customer service";subprotocol="t140"
        a=dcsa:1 fmtp:-
        a=dsca:1 hlang-send:es eo
        a=dsca:1 hlang-recv:es eo

Answer:

m=application 911 UDP/DTLS/SCTP webrtc-datachannel
        c=IN IP6 2001:db8::3
        a=max-message-size:1000
        a=sctp-port 5000
        a=dcmap:1 label="ACME customer service";subprotocol="t140"
        a=dcsa:1 fmtp:-
        a=dsca:1 hlang-send:eo
        a=dsca:1 hlang-recv:eo

(Christer, can you please insert the variations needed in the answer to 
make it a realistic example of offer - answer.)

>
> ---
>
> 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.)
Agreed. It was discussed but not included in the final result.
>
>>     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.

Yes, I agree, it can be read your way.

But I read "A specification that defines a subprotocol that uses the 
attributes MUST specify the modality for that subprotocol." as if only 
one modality was tied to a specific subprotocol identity.

Can we change the sentence to "A specification that defines a 
subprotocol that uses the attributes MUST specify how the modality is 
deducted for languages used with that subprotocol."


Regards

Gunnar

>
> Regards,
>
> Christer
>
>   
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]