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

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

Hi Christer,

I have met people who communicate with email in Esperanto. So Esperanto 
is used. But if you want to have a more common language in the example, 
you may exchange eo with for example it for Italian.

---

I just discovered in the draft-ietf-rtcweb-data-channel draft section 
6.4 that the "label" is supposed to be identical in the offar and 
answer. We agreed to insert text somewhere that "label" can be used to 
indicate source. With the requirement that it shall be identical, it is 
only half true that it can indicate source. I forgot where we had that 
wording, so please check its relevance while you edit the resulting 
modifications.

Nothing new inline.

Regards

Gunnar

Den 2019-08-26 kl. 11:28, skrev Christer Holmberg:
> Hi Gunnar,
>
> 12. At the end of 3.2, add the following about language negotiation
>
> ...
>
>>>> 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.)
>    
> If we want to keep it realistic, should we really use Esperanto? :)
>
> One of my teachers in high school was a big fan of Esperanto, and claimed that it will take over English as the number one world language. But, that was only 30 years ago, so I guess there is still time :)
>
> ---
>
> 12a: Allow use of hlang- attributes together with m=application media declarations
>      
> ...
>
>>>>> 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.
> I think anything "implicit" should be forbidden in IETF standards - it always creates problems sooner or later....
>
>   >>>     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."
>     
>   Will fix.
>
>   Regards,
>
>   Christer
>
>   
>      
>      Regards
>      
>      Gunnar
>      
>      >
>      > Regards,
>      >
>      > Christer
>      >
>      >
>      >
>      > _______________________________________________
>      > mmusic mailing list
>      > [e-mail]
>      > https://www.ietf.org/mailman/listinfo/mmusic
>      
>      --
>      -----------------------------------------
>      Gunnar Hellström
>      Omnitor
>      [e-mail]
>      [phone]
>      
>      
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

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