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

Adam Roach <adam@nostrum.com> Tue, 09 April 2019 16:50 UTC

Return-Path: <adam@nostrum.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 4F33C120899; Tue, 9 Apr 2019 09:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 AZ1xtsE5ZXnN; Tue, 9 Apr 2019 09:50:54 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6726120885; Tue, 9 Apr 2019 09:50:41 -0700 (PDT)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x39GoYf4078176 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 Apr 2019 11:50:36 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554828637; bh=R93NQEFIm/SGxvQKoAVth7Hh+DBAR3RzbyPdwazWCjQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=W1MQX9tB/qNvqc+cou1NnxukBlXUyXbCUFNXpTJRjZ2YTgkNUskgcxZY/TqTcp29u kXAsLRiwbIrRmAfAgmD2xIzUjIp6ga1v+vQjSiI8VUJ0uV26qTr2V/rDp5uTs/QR9V 32ey5Jx5Sukhg1hcCkZhxan4DWBEWXfruUXzDAoE=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, The IESG <iesg@ietf.org>
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>
References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com> <HE1PR0701MB252226AB6D1CBCD2DFEFB4AB952D0@HE1PR0701MB2522.eurprd07.prod.outlook.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <b1b54496-2f51-511b-9ef8-6c5b6a085640@nostrum.com>
Date: Tue, 9 Apr 2019 11:50:29 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <HE1PR0701MB252226AB6D1CBCD2DFEFB4AB952D0@HE1PR0701MB2522.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------9C9991A020B5A28C0B289A71"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/uLYasOAw1LYg8uqjMeNiqcktmoo>
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: Tue, 09 Apr 2019 16:50:57 -0000

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 anhttps://www.w3.org/TR/webrtc/  as an USVSsting
>>> (https://heycam.github.io/webidl/#idl-USVString). 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:
>>       o If the byte can be expressed as a `quoted-char`, do so
>>       o 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