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

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Fri, 05 Apr 2019 05:04:40 -0700

Magnus Westerlund has entered the following ballot position for
draft-ietf-mmusic-data-channel-sdpneg-25: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/

----------------------------------------------------------------------
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). 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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 5.1.3:

Is it correct that there are no limiation on the lenght of the label? So it
will okay if I use the more than 450k words of J.R.R.R Tolkien's Lords of the
Ring as label?

[WebRtcAPI]
Is it really the intention to point to the very old version of the API from
2015? The current candidate specification is available here:
https://www.w3.org/TR/webrtc/ and are from 2018.

---

From: Adam Roach <[email-masked]>
Date: Mon, 8 Apr 2019 10:55:21 -0500

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?

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 9 Apr 2019 09:00:18 +0000

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

5.1.3.  Label Parameter

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`.

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.

Cheers

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: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------

---

From: Adam Roach <[email-masked]>
Date: Tue, 9 Apr 2019 11:50:29 -0500

On 4/9/19 4:00 AM, Magnus Westerlund wrote:
>>> specification anhttps://www.w3.org/TR/webrtc/  as an USVSsting
>> 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:
>>
> 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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 10 Apr 2019 08:18:23 +0000

On 2019-04-09 18:51, Adam Roach wrote:
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:

5.1.3.  Label Parameter

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

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.

Is this something that actually should be addressed in4566bis?

Anyway, I am fine with the previous outline for solution as my issue was that it was not clear how to get the intended labels into the SDP when desired in a way that is interoperable. So I will remove my discuss when the document has been addressed.

cheers

Magnus Westerlund

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Apr 2019 12:29:40 -0500

> Is this something that actually should be addressed in4566bis? 

It's in IETF last call, but we can pause processing until the WG has 
time to consider the issue. Do you want me to ask the MMUSIC chairs to 
take this question to the working group?

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 11 Apr 2019 07:57:30 +0000

> take this question to the working group?
For 4566bis I hope the WG could discuss this before the IETF last call
ends. It will run for another 2 week isn't it so there is time for that.

I don't have a strong view if holding up the data-channel-sdpneg doc for
a week or two while this is discussed is the right answer or not. I
think the major point here is there actual problems of using UTF-8 text
fields in SDP Attributes in the relevant deployment environments. And
for this particular document will a change create significant
interoperability issues?

I see some benefit is letting the WG provide input into this matter
before it is to late and it can be done with only minor delay in
progressing the data channel document.

I will send a separate email as IETF last call comment on 4566bis.

Cheers

Magnus

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 11 Apr 2019 08:01:05 +0000

Hi,
I looked at https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-09 there label is defined

Label: Variable Length (sequence of characters)
      The name of the Data Channel as a UTF-8 encoded string as
      specified in [RFC3629<https://tools.ietf.org/html/rfc3629>].  This may be an empty string.

Also protocol is specified there as
  Protocol: Variable Length (sequence of characters)
      If this is an empty string the protocol is unspecified.  If it is
      a non-empty string, it specifies a protocol registered in the
      'WebSocket Subprotocol Name Registry' created in [RFC6455<https://tools.ietf.org/html/rfc6455>].  This
      string is UTF-8 encoded as specified in [RFC3629<https://tools.ietf.org/html/rfc3629>].

This will map to w3c https://www.w3.org/TR/webrtc/  USVString defined for both protocol and label.  This made me wonder since the sub-protocol identifier in RFC6455 defines as a token (RFC2616) which in my understanding is ASCII.

draft-ietf-mmusic-data-channel-sdpneg-25 defies both as quoted string . Note that the mmusic document is referenced by CLUE data channel using SDP.

I think that taking Adam's suggestion make sense. I also think that specifying SDP values to only use UTF-8 may have issues with registration in IANA

So we can add to section 5.1.3

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

"

Is this OK?

Roni

From: Magnus Westerlund [mailto:[email-masked]]
Sent: Wednesday, April 10, 2019 11:18 AM
To: Adam Roach; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)

DISCUSS:

5.1.3.  Label Parameter

   string.

be insufficient.

cheers

Magnus Westerlund

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Apr 2019 10:58:33 -0500

> ends. It will run for another 2 week isn't it so there is time for that.

Well, technically, it ends tomorrow, but you are correct that we don't 
have a formal telechat until the 25th. I'm going to hold off creating a 
ballot until the conversation you just started in MMUSIC has time to 
conclude.

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 12 Apr 2019 09:06:43 +0000

> ballot until the conversation you just started in MMUSIC has time to 
I have submitted an IETF last call comment as individual on the issue. I
managed to missinterpret the number of days in IETF LC as the days letf,
sorry about that if it caused any confusion.

I would also note that the next IESG telechat is actually the 2nd of May
due to the IESG retreat.

Cheers

Magnus Westerlund 

SE-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: "Roni Even (A)" <[email-masked]>
Date: Mon, 15 Apr 2019 05:04:42 +0000

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

“

Does this sound reasonable to you

Regards
Roni

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

DISCUSS:

5.1.3.  Label Parameter

   string.

be insufficient.

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 15 Apr 2019 08:25:54 +0000

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

Regards
Roni

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

DISCUSS:

5.1.3.  Label Parameter

   string.

(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>). And in the reference version

be insufficient.

/a

--

Magnus Westerlund

---

From: "Roni Even (A)" <[email-masked]>
Date: Mon, 15 Apr 2019 09:47:54 +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:[email-masked]]
Sent: Monday, April 15, 2019 11:26 AM
To: Roni Even (A)
Cc: [email-masked]; [email-masked]; [email-masked]; Adam Roach; The IESG
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)

Hi,

Cheers

Magnus

Regards
Roni

DISCUSS:

5.1.3.  Label Parameter

   string.

be insufficient.

/a

--

Magnus Westerlund

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Apr 2019 16:52:37 -0500

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?

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

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 16 Apr 2019 10:04:25 +0000

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

> unpaired surrogate codepoints."

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

Cheers

Magnus Westerlund