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

Christer Holmberg <christer.holmberg@ericsson.com> Sun, 25 August 2019 14:12 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 1E56D12029C for <mmusic@ietfa.amsl.com>; Sun, 25 Aug 2019 07:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 QDB-KTiFvBtZ for <mmusic@ietfa.amsl.com>; Sun, 25 Aug 2019 07:12:25 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60065.outbound.protection.outlook.com [40.107.6.65]) (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 292B1120144 for <mmusic@ietf.org>; Sun, 25 Aug 2019 07:12:24 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QvSZ4d1Go1/VhZnHFDmJfyon3FFOCQNwFSjWsxPmaokdikiTr51IWZPdp6HTBswlXnRg+Dy5EPm2RxSMy/fsv+cn2rPDFdxwfRsimT/5ly4H7Y4mmRu2+KkoWB9IrJgfTJJy7AAbT41TL78TaTGa+rmmltOMso8ogGnqO6qZAREKx8G9wO1BPluqTS0Rkvo68UTnzUdB5uJ9CtM07kl8ja0mq9ojJ4776NsGhF1hmh4dRL5ywD+flqjUFz6KoC8x184VYWmo+gRyQ8CSFZt/wzISG1UrwG6UseLszPI0tplOo9wsCEM/d5ZJlPWx4T+6Ufcts1GKGODPKXyOEOv5BA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4vcVu3Zi5hDQM6riprx/opA41wsSK/+Tpt3CQpitw5s=; b=Dif5ei6ezfYWOYBKriYdlo4XxIGB+omatRhuGExfbXcXB0Yr4P+bnfJJhqrhE8q/5BqwZPrAGKJXWYfKOu16Wk8I14+T2Y0N1DhWcQUfex47Ig83HC9wSXm7tOC2qHFVwI/0NQ9x9FYTZW1+/zLhXxZ5v0gTnFb+BhBhI9BpqiJAY1Ke85iKu3tW/naJtrkq5iUY/VQqB8v4lZ/EqEv8W5GzWc7MSW8cUws3vTREO0S7Bq2Y8SwFmgJZV7rVKEMrY1vaMkzZqsNZY/z/A/ZMgB9S6HEpJZ7L8K1JizjEXMH/ViflJbe3Hn8ihccrf2KEYBnx6lY0O8Oxm3UQuiBDOA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4vcVu3Zi5hDQM6riprx/opA41wsSK/+Tpt3CQpitw5s=; b=T4jhmVse299m3fbNS8C4U1mTDNGkB9d1OJ9hPha8VG3EiVF7vp7brgyEI1medZpVSu+l4Exns2HImVmwvrYmoJBG+cUb4Tf1ypL5BUU5l39p/FYaZmOIrQR/s9hftuV/eRH7QXnPUU8KwfItLZRhE7RbLoqlSvf8S//ee3Yfdf8=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3098.eurprd07.prod.outlook.com (10.170.244.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.12; Sun, 25 Aug 2019 14:12:16 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::f0a1:2199:7816:ff8d]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::f0a1:2199:7816:ff8d%6]) with mapi id 15.20.2220.013; Sun, 25 Aug 2019 14:12:15 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= <gunnar.hellstrom@omnitor.se>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - language indication
Thread-Index: AQHVWl4QuYQwHBaR0ECBil5zMJd716cKEjDAgAGVqQCAAC2KsA==
Date: Sun, 25 Aug 2019 14:12:15 +0000
Message-ID: <HE1PR07MB3161BFE14DF8F1127ABF497093A60@HE1PR07MB3161.eurprd07.prod.outlook.com>
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com> <CAOW+2duTuUc8FXT-BEhJioUnPsOkzYJddK=xAp1oWiBQCKM2vg@mail.gmail.com> <HE1PR07MB3161874ED292FA17015EF95E93AE0@HE1PR07MB3161.eurprd07.prod.outlook.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>
In-Reply-To: <57a01757-8a67-0f48-df63-4cd5e1584f37@omnitor.se>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [79.134.118.162]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 78df781e-7e9c-46c8-58c9-08d729663b96
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3098;
x-ms-traffictypediagnostic: HE1PR07MB3098:
x-microsoft-antispam-prvs: <HE1PR07MB3098A977FB29E03029EA9C5493A60@HE1PR07MB3098.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 01401330D1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(346002)(376002)(366004)(396003)(189003)(199004)(53936002)(486006)(186003)(8936002)(44832011)(26005)(2906002)(7736002)(305945005)(446003)(316002)(110136005)(74316002)(6506007)(2501003)(102836004)(476003)(14454004)(11346002)(71190400001)(71200400001)(66066001)(14444005)(256004)(8676002)(81156014)(81166006)(25786009)(33656002)(478600001)(3846002)(6116002)(66556008)(64756008)(66446008)(66476007)(76176011)(66946007)(55016002)(99286004)(7696005)(9686003)(52536014)(5660300002)(6436002)(76116006)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3098; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: +i7O3LVGm2JjIv+Baf8Eq+mDgvP7UUFf0fpgYdVI9AlptwHA1kDINPPDnXUMvKHcqlb28KYBldFbDY1RVOJmE45Ir28x/0KuCYuJ0Li58+NVFrYaJyKpqMpKHlXdE1LPWz1ZGZ6lXIpIYNBhSTlpf8F+oPiEZJr+4Vk/fg21Fl0bKZfWJp7UibGUgdkJko8YrMUQhjizvaYCRT7VyTFtZoM2b1jHmxAjYK1ZR0pA4AdonOME+Iq54Egs0Ai/PhbVRjZfgkUnSFNTX1HUQSTHqzA/VkoOM7xb2O3T0bioNTq/fugRgG991D7MfNDAsEzYqD4fugdFtdwoSffFW0Xu+y5Etw2IJ4p5V8v+BlvVgUai3HgyXHfUmE4EaqAR8yDXbQ9URt5iWsTnqAxnyxGxAMyte9z/U1sWnSSctcnN/ZE=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 78df781e-7e9c-46c8-58c9-08d729663b96
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2019 14:12:15.7077 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: UV3IOiWnZwhXQBx33CWrRA4MDRAyM8Wh3nfckBwRtCp/FvtYi7MDvzrYRi7UHLoLrpfJ8qBTR1Ciz8KzelSmadPeDiQkBwq6sje/h/mds9Y=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3098
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/f423vzgbJ-Q0V7IqwezEdQTmSwk>
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: Sun, 25 Aug 2019 14:12:28 -0000

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.

>>> -EDITORs NOTE - There may be a need for IANA registration of this way 
>>> to use the human language attributes.
>>>
>>> RFC 8373 was created partly to satisfy a dependency from 3GPP 
>>> requiring negotiation of language per media. We knew that the T140 
>>> text data channel was about to be specified, but we could not request 
>>> IANA to register the use of the
>>> hlang- attributes because of the state of the t140-usage-data channel 
>>> draft, so the registration request was deleted from RFC 8373. It needs to be completed now.
>> Not sure I follow. The attributes have been registered with IANA, and BCP47 is referenced for the attribute values. What else is needed?
>See below
>
> ---

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

(Of course, the text above should have been included in draft-data-channel-sdpneg, because in future one might use the lang attributes for other types of data channels than T.140. The draft is in the RFC EQ, and I don't think we want to bring it back to the WG, but maybe the t140 draft updates draft-data-channel-sdpneg too)

---

12b: Allow use of hlang-attributes in dsca parameter values.

>>> RFC 8373 registers SDP parameter att-values hlang-send and hlang-recv 
>>> only for media-level use. The registration requirements in rfc4566bis require 
>>> us to register the use also on dsca(subprotocol) level for the t140 subprotocol.
>>>
>>> I am not sure how to express that registration. The attributes and 
>>> values are as defined in RFC 8373. We just need to add a usage level for 
>>> SDP att-values hlang-send and hlang-recv for media "application  / webrtc-datachannel"
>>>
>>>     o  Usage Level: Add the following
>>>      dcsa(subprotocol).
>>>          dcsa(t140)  for written media.
>>>
>>> I would appreciate guidance on how this should be expressed in IANA considerations.
>>
>> I don't think that is needed. We haven't registered other attributes that are carried within a dsca attribute either. 
>> From an SDP perspective, the attributes will still be used for media-level.
>
> Yes, the sdpneg draft, section 9.2.2 seems to indicate that attributes already specified for media level are allowed 
> to be used at dsca level without specific registration if the use is not modified from its original use at media level.
>
> But rfc4566bis, section 8.2.4.2 about updates to existing attributes requires us to register if there is a change to the 
> semantics of the original attribute. Maybe we should view as modified semantics the use together with m=application
> and the need to look at the subprotocol T140 to understand that it is about written language indications.

I personally don't think there is a change to the semantics of the original attribute. But, I'm sure we'll sort out the IANA stuff, once we get everything else done :)

Regards,

Christer