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

[Adam Roach <[e-mail]>]

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