Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)

"Roni Even (A)" <roni.even@huawei.com> Mon, 15 April 2019 09:48 UTC

Return-Path: <roni.even@huawei.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 7D406120158; Mon, 15 Apr 2019 02:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level:
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 EuOh7UacoVTK; Mon, 15 Apr 2019 02:48:05 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 BA13712003F; Mon, 15 Apr 2019 02:48:04 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id D7C158BB2A4E058B5E28; Mon, 15 Apr 2019 10:48:02 +0100 (IST)
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 15 Apr 2019 10:48:02 +0100
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 15 Apr 2019 10:48:02 +0100
Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Mon, 15 Apr 2019 10:48:01 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0415.000; Mon, 15 Apr 2019 17:47:54 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
CC: "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" <draft-ietf-mmusic-data-channel-sdpneg@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>
Thread-Topic: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
Thread-Index: AQHU66fNA40h4UsP7kq3a/Vv5QT6waY9BUHg
Date: Mon, 15 Apr 2019 09:47:54 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDC132@dggemm526-mbx.china.huawei.com>
References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com> <HE1PR0701MB252226AB6D1CBCD2DFEFB4AB952D0@HE1PR0701MB2522.eurprd07.prod.outlook.com> <b1b54496-2f51-511b-9ef8-6c5b6a085640@nostrum.com> <6E58094ECC8D8344914996DAD28F1CCD18CDC02D@dggemm526-mbx.china.huawei.com> <HE1PR0701MB2522A34E3190EF29659B1178952B0@HE1PR0701MB2522.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0701MB2522A34E3190EF29659B1178952B0@HE1PR0701MB2522.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.102]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD18CDC132dggemm526mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/XcmiQpCu14vBdlU6vYP9-WbdNDs>
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
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, 15 Apr 2019 09:48:09 -0000

Hi Magnus,
The current ABNF for quoted string is a double quoted string of bytes where non printable characters are escaped using %.  So do you suggest that if need to convert to UTF-8 . the quoted string should be a string of bytes without the escape char?
When receiving the label or subprotocol from WebRTC you need to serialize so that it will be converted to a quoted string.

Roni

From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Monday, April 15, 2019 11:26 AM
To: Roni Even (A)
Cc: mmusic-chairs@ietf.org; draft-ietf-mmusic-data-channel-sdpneg@ietf.org; mmusic@ietf.org; Adam Roach; The IESG
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)

Hi,

I think you need to split this into two parts. One is the general quoting of the UTF-8 string in the label parameter. The other part is the serialization of the WebRTC label into an UTF-8 string.

Also, I don't get my head around the USVString if that has any additional data in addition to the sequence of the Unicode scalar values and if there are any action that are needed to be done in the seralization to an UTF-8 string?

Cheers

Magnus


On 2019-04-15 07:04, Roni Even (A) wrote:
Hi Magnus,
I responded to your comments and this is currently the only open comment from all the comments that we got  that I need to address

I think that the text proposed by Adam make sense so I suggest adding to section 5.1.3 the following text




"In order to communicate with WEbRTC API the label attribute should

  *   Serialize the WebRTC label as a UTF-8 string
  *   Treat the UTF-8 serialization as a series of bytes
  *   For each byte in the serialization:

     *   If the byte can be expressed as a `quoted-char`, do so
     *   Otherwise, express the byte as an `escaped-char`.
"

Does this sound reasonable to you

Regards
Roni


From: Adam Roach [mailto:adam@nostrum.com]
Sent: Tuesday, April 09, 2019 7:50 PM
To: Magnus Westerlund; The IESG
Cc: mmusic-chairs@ietf.org<mailto:mmusic-chairs@ietf.org>; draft-ietf-mmusic-data-channel-sdpneg@ietf.org<mailto:draft-ietf-mmusic-data-channel-sdpneg@ietf.org>; mmusic@ietf.org<mailto:mmusic@ietf.org>
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)

On 4/9/19 4:00 AM, Magnus Westerlund wrote:
On 2019-04-08 17:55, Adam Roach wrote:
On 4/5/19 7:04 AM, Magnus Westerlund via Datatracker wrote:

----------------------------------------------------------------------

DISCUSS:

----------------------------------------------------------------------



There might be a serious issue in label definition.



5.1.3.  Label Parameter



   The 'label' parameter indicates the name of the channel.  It

   represents a label that can be used to distinguish, in the context of

   the WebRTC API [WebRtcAPI], an RTCDataChannel object from other

   RTCDataChannel objects.  This parameter maps to the 'Label' parameter

   defined in [I-D.ietf-rtcweb-data-protocol].  The 'label' parameter is

   optional.  If it is not present, then its value defaults to the empty

   string.



  label-opt       = "label=" quoted-string

  quoted-string   = DQUOTE *(quoted-char / escaped-char) DQUOTE

  quoted-char     = SP / quoted-visible

  quoted-visible  = %x21 / %x23-24 / %x26-7E ; VCHAR without " or %

  escaped-char    = "%" HEXDIG HEXDIG



I interpret that as the intention is to enable the SDP Attribute to carry the

label as defined in W3C API. That value is in the current candidatate

specification an https://www.w3.org/TR/webrtc/ as an USVSsting

(https://heycam.github.io/webidl/#idl-USVString<https://protect2.fireeye.com/url?k=1d146270-419dcd1b-1d1422eb-0cc47ad93ea2-445522e31aeacf26&u=https://heycam.github.io/webidl/#idl-USVString>)tring>). And in the reference version

of the WebRTC API as an DOMstring. Both are not limited to ASCII and may

contain any Unicode characters. Thus the escaping mechanism defined appear to

be insufficient.



I think the "quoted-string" need a definition of what type of string this truly

are so that it is clear what a character in the string is.



In addition the specification of escaping is undersspecified. I would recommend

at least adding discussion of the need and how to escape DQUOTE and % that can

be relatively common operations.



I can see that this could benefit from some explicit detail about how to convert the cited USVString string into the "quoted-string" construct defined here. I think this roughly consists of:

  *   Serialize the WebRTC label as a UTF-8 string
  *   Treat the UTF-8 serialization as a series of bytes
  *   For each byte in the serialization:

     *   If the byte can be expressed as a `quoted-char`, do so
     *   Otherwise, express the byte as an `escaped-char`.

Would including text to that effect satisfy your concern?

Yes it would be clear what is expected. However, I fail to understand why one need to ASCIIify and escape the UTF-8 encoded characters where one could simply define the label value as an UTF-8 string something that is compatible with SDP specification. Wouldn't that reduce the set of characters needing escaping to a much smaller set.



That's a little tricky. RFC 4566: "SDP also allows other character sets such as ISO 8859-1 to be used when desired."

Even if we just constrain this to SIP, RFC 3261: "When no explicit charset parameter is provided by the sender, media subtypes of the 'text' type are defined to have a default charset value of 'UTF-8'."

So there's a bias towards UTF-8, but no strict requirement.

I'd support a short document that deprecated non-UTF-8 encodings of SDP so that specifications like this one could simply assume that the full character set can be used directly, but that's not the current state of affairs.

/a



--



Magnus Westerlund



----------------------------------------------------------------------

Network Architecture & Protocols, Ericsson Research

----------------------------------------------------------------------

Ericsson AB                 | Phone  +46 10 7148287

Torshamnsgatan 23           | Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>

----------------------------------------------------------------------