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

[Christer Holmberg <[e-mail]>]

Hi,
    
>    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 am fine using Esperanto. Maybe my old teacher will read the draft and remember me :)

---
    
>    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.

If we want to change the identical requirement we need to raise it in RTCWEB. 

It's probably a good idea to also ask them if they think 'label' is good for indicating source in the first place.

Regards,

Christer

    



    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]