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

Adam Roach <> Tue, 09 April 2019 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F33C120899; Tue, 9 Apr 2019 09:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.678
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: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AZ1xtsE5ZXnN; Tue, 9 Apr 2019 09:50:54 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6726120885; Tue, 9 Apr 2019 09:50:41 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (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
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; 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: Host [] claimed to be
To: Magnus Westerlund <>, The IESG <>
Cc: "" <>, "" <>, "" <>
References: <> <> <>
From: Adam Roach <>
Message-ID: <>
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: <>
Content-Type: multipart/alternative; boundary="------------9C9991A020B5A28C0B289A71"
Content-Language: en-US
Archived-At: <>
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:
>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> 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  as an USVSsting
>>> ( 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