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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Mon, 26 August 2019 08:58 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7AE120025 for <mmusic@ietfa.amsl.com>; Mon, 26 Aug 2019 01:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaIFsx_kOQaX for <mmusic@ietfa.amsl.com>; Mon, 26 Aug 2019 01:58:30 -0700 (PDT)
Received: from bin-mail-out-05.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25DB120048 for <mmusic@ietf.org>; Mon, 26 Aug 2019 01:58:29 -0700 (PDT)
X-Halon-ID: a5422dcb-c7df-11e9-837a-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id a5422dcb-c7df-11e9-837a-0050569116f7; Mon, 26 Aug 2019 10:58:18 +0200 (CEST)
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com> <665185b6-c1e7-62c3-4e3b-e9374d23bfd5@omnitor.se> <DF010721-81CD-40DE-A848-DE4D36836FDA@ericsson.com> <ED158CF5-E059-482B-8D7E-934BA2C753A1@ericsson.com> <2201665d-5054-1872-d208-a0fe2d26095c@omnitor.se> <VI1PR07MB3167055C995D17D4BA9E36DE93A50@VI1PR07MB3167.eurprd07.prod.outlook.com> <8d14b055-8405-4a4f-174d-d7580bea348c@omnitor.se> <0DA1248C-41FC-4155-A578-29A19883857C@ericsson.com> <a91850b9-6e86-058f-dddd-3f856bcd6710@omnitor.se> <DBC532B8-38DC-4140-B7C4-0B6853F0EF77@ericsson.com> <6fcf46a6-544d-027c-97c7-5c0e08caa555@omnitor.se> <c8761f5d-f73b-8c94-9c5e-f378e262a7b1@omnitor.se> <HE1PR07MB3161354CC40B66BEA6E4CBC593A70@HE1PR07MB3161.eurprd07.prod.outlook.com> <57a01757-8a67-0f48-df63-4cd5e1584f37@omnitor.se> <HE1PR07MB3161BFE14DF8F1127ABF497093A60@HE1PR07MB3161.eurprd07.prod.outlook.com> <bb828fd1-3d97-7d2b-78fb-8cf44137b4c6@omnitor.se> <34A2F227-2C19-473B-A16E-C3546023CFB3@ericsson.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <3fc86c8f-f7f9-5741-35f5-19303dd05e67@omnitor.se>
Date: Mon, 26 Aug 2019 10:58:25 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <34A2F227-2C19-473B-A16E-C3546023CFB3@ericsson.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/9Sz_YdwOqOi_wleb8LJcuaTTerI>
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - language indication
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2019 08:58:35 -0000

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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288