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

Magnus Westerlund <> Tue, 16 April 2019 10:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B835112047E; Tue, 16 Apr 2019 03:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OHorK6dVVkpZ; Tue, 16 Apr 2019 03:04:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 257D4120128; Tue, 16 Apr 2019 03:04:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RXItOdim92wCAmi/e5nrTvCWIGTwIFfIq79gsxNG6Ww=; b=M5qSBcMPsgv+p70iHBQUF/d4suv2cIN9VNNQeO+wwxqMf7pzwbyE4nMl5l8erO+xAtFJHgM3z0rWailoIAAZN9PiZHaLulGEmFrLqqSXev057xRS66a7Uat49a4s3TGXS/e/NCLQcUnIGE0qDrwoqWEQPYhOwXEu/hGFghuneJc=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.8; Tue, 16 Apr 2019 10:04:25 +0000
Received: from ([fe80::b161:fb77:e4ea:4723]) by ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1813.009; Tue, 16 Apr 2019 10:04:25 +0000
From: Magnus Westerlund <>
To: Adam Roach <>, "Roni Even (A)" <>
CC: "" <>, "" <>, "" <>, The IESG <>
Thread-Topic: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
Thread-Index: AQHU66fNA40h4UsP7kq3a/Vv5QT6wQ==
Date: Tue, 16 Apr 2019 10:04:25 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
Accept-Language: sv-SE, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 508412b0-785a-4e89-430f-08d6c252e7fc
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2667;
x-ms-traffictypediagnostic: HE1PR0701MB2667:
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 000947967F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(136003)(376002)(346002)(199004)(189003)(106356001)(55016002)(93886005)(478600001)(2906002)(8676002)(44832011)(97736004)(105586002)(486006)(52536014)(66066001)(86362001)(7736002)(6436002)(305945005)(53936002)(33656002)(9686003)(14454004)(229853002)(74316002)(6506007)(81166006)(81156014)(7696005)(5660300002)(476003)(14444005)(76176011)(99286004)(4326008)(8936002)(102836004)(446003)(53546011)(186003)(68736007)(110136005)(54906003)(71200400001)(71190400001)(25786009)(3846002)(26005)(6116002)(316002)(256004)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2667;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Ddu/2XOO6eY1qZ3qi3YZpucZBUZo9o4CMN+451Nfc3IO//zyYviGvWZRyH18ICkPjple0O3NAk9AUCaVP27JTRpEhDVqo93xhkV/Et+7xozU0AZAM7D2Dx/x19Qx+jyQLmNd2h8I2XqlYNoNM3DTN8JqEocRn9GEb/S3wDa9WXw1X6h1STbnTWnktJVfi0kdIENQ5k8Wkav68PmnqC3UgZLHDIPNJhjYyFxlN75x7wYk/2Q7jcjEjmTAfITqpb45w2rQYSCMZIXU9n4zmgFCaaSmj6U1j67zXnknPKNUaIGQhrhNq2id67pkMnbZFSCmUxO6OUMhwEsoaVDBLDdzGxxDq0EJe/jO2m8UIuCCa4mRLtmn2cll7ygoKy64qu4oPXaNqvn7Q1iGXJG6gXUK3GA+c8s++3CSlD98n/WXXQs=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 508412b0-785a-4e89-430f-08d6c252e7fc
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 10:04:25.3408 (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-Transport-CrossTenantHeadersStamped: HE1PR0701MB2667
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, 16 Apr 2019 10:04:32 -0000

On 2019-04-15 23:53, Adam Roach wrote:
> On 4/15/19 3:25 AM, Magnus Westerlund wrote:
>> 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.
> I'm not sure what you mean by the second operation ("the other part") 
> here. A USVString represents a sequence of Unicode codepoints ("USV" 
> stands for "Unicode Scalar Values"). The procedure for going from a 
> sequence of Unicode code points to a UTF-8 string is defined in RFC 
> 3629. Are you simply asking for a reference to RFC 3629 here?

The reason I was asking for a split is that the SDP attributes parameter
label takes an UTF-8 string. While in the specific case of WebRTC there
is a mapping from W3C specs USVString to this UTF-8 string. Thus, I want
to ensure that there is a seperation between what basically a mapping
from the W3C API, which possibly should be done by W3C rather than IETF.
And the general operation that needs to be applied for any UTF-8 String
used as Data channel label.

If RFC 3629 defines the procedure then lets reference it.

>> 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?
> I'm pretty comfortable asserting that the answers are "no" and "no" 
> respectively. While it's not part of the spec, MDN (which hews very 
> close to an "as built" description of web standards) makes this pretty 
> clear: "USVString is equivalent to DOMString except for not allowing 
> unpaired surrogate codepoints."

Okay, if that is the case, then I guess not more are really needed.


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: