Subject: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive?

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Tue, 8 Mar 2016 13:43:33 +0100

Hello,

If a WebRTC endpoint uses the data channel establishment protocol in order to open a data channel, 
it may add a non-empty protocol identifier to the DATA_CHANNEL_OPEN message. Is the endpoint, which 
receives this DATA_CHANNEL_OPEN message, assumed to process this protocol id string in a case 
sensitive or case insensitive way? Or would that actually be up to the receiving WebRTC endpoint's 
implementation?

As far as I see draft-ietf-rtcweb-data-protocol doesn't seem to specify this.

Background is draft-ietf-mmusic-data-channel-sdpneg, where the subprotocol identifiers are signaled 
as part of an SDP attribute and where it is not yet clarified if these identifiers are assumed to be 
case sensitive or case insensitive.

Thanks,
Juergen

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 Mar 2016 08:31:12 -0800

Hi Juergen,

On Tue, Mar 8, 2016 at 4:43 AM, Juergen Stoetzer-Bradler <
[email-masked]> wr

> As far as I see draft-ietf-rtcweb-data-protocol doesn't seem to specify
Following the chain on this is a bit tedious, but section 5.1 specifies
that this re-uses the registry set up by Websockets and described in RFC
6455.  That, in turn, says:

        The elements that comprise this value
        MUST be non-empty strings with characters in the range U+0021 to
        U+007E not including separator characters as defined in
        [RFC2616 <https://tools.ietf.org/html/rfc2616>] and MUST all
be unique strings.  The ABNF for the
        value of this header field is 1#token, where the definitions of
        constructs and rules are as given in [RFC2616
<https://tools.ietf.org/html/rfc2616>].

The current registry is here:

http://www.iana.org/assignments/websocket/websocket.xhtml#subprotocol-name

regards,

Ted

> Background is draft-ietf-mmusic-data-channel-sdpneg, where the subprotocol
> identifiers are signaled as part of an SDP attribute and where it is not
> yet clarified if these identifiers are assumed to be case sensitive or case
> insensitive.
>
> Thanks,
> Juergen
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 8 Mar 2016 11:54:48 -0500

Ted,

On 3/8/16 11:31 AM, Ted Hardie wrote:
> Hi Juergen,
>
> On Tue, Mar 8, 2016 at 4:43 AM, Juergen Stoetzer-Bradler
> <[email-masked]
> <mailto:[email-masked]>> wr
>
>
>          [RFC2616 <https://tools.ietf.org/html/rfc2616>] and MUST all be unique strings.  The ABNF for the
>          constructs and rules are as given in [RFC2616 <https://tools.ietf.org/html/rfc2616>].
>

I had already investigated this. This only talks about the registry, not 
how values passed in the protocol are compared to registered values. Nor 
does it explicitly say whether "unique strings" is to be determined via 
case-sensitive comparison or case-insensitive comparison.

(Without any other information to go on I guess I would assume 
case-sensitive comparison.)

What is most *important* to me is that this be made entirely clear, that 
IANA have clear instructions to enforce, and that both websocket and 
data channel specs consistently specify what implementations must do in 
this regard.

It is less important to me *which* choice is made. My *preference* would 
be minimally that the registry not permit two different names that 
differ only by case. If that is so, then in some sense it doesn't matter 
how implementations of the protocols do the comparison.

	Thanks,
	Paul

> regards,
>
> Ted
>
>     Background is draft-ietf-mmusic-data-channel-sdpneg, where the
>     subprotocol identifiers are signaled as part of an SDP attribute and
>     where it is not yet clarified if these identifiers are assumed to be
>     [email-masked] <mailto:[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 Mar 2016 11:22:26 -0800

On Tue, Mar 8, 2016 at 8:54 AM, Paul Kyzivat <[email-masked]> wrote:

> Is there any token example in RFC 2616 that is case sensitive?  As far as
I can tell they are all case-insensitive, but I may have missed something.

The Postel principle seems to indicate that we should always use the
registered form, but be willing to understand a case insensitive variant.

> IANA have clear instructions to enforce, and that both websocket and data
> channel specs consistently specify what implementations must do in this
> regard.
>
>
It is less important to me *which* choice is made. My *preference* would be
> minimally that the registry not permit two different names that differ only
> by case. If that is so, then in some sense it doesn't matter how
> implementations of the protocols do the comparison.
>
> How likely do you see this being?  Anyone going to register XMPP (instead
of xmpp) is going to be hurting themselves as much as users of xmpp if they
actually use it.  I'm happy to clean this up at some point, but I find it
hard to believe this is the biggest rock.

regards,

Ted

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 8 Mar 2016 21:07:11 +0100

This is a sidetrack, but the grammar in RFC 2616:

      token          = 1*<any CHAR except CTLs or separators>
       separators     = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT

+ the ancient # rule
means that "1#token" is a comma-separated list of tokens, where each
token is separated by LWS.

Not only do we (or someone) have to decide whether "xmpp" matches
"XMPP", we also have to decide whether "iam,thegreatest" matches "iam
,   thegreatest"  or even "iam,
thegreatest" (yes, there's a newline in there).

All tokens registered so far are single tokens. Would it be possible to
advise against using identifiers with comma in them?

(for the base question, since this is ASCII only, lowercase is
well-defined, so I have no strong objection to either choice.)

On 03/08/2016 08:22 PM, Ted Hardie wrote:
> On Tue, Mar 8, 2016 at 8:54 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>                  [RFC2616 <https://tools.ietf.org/html/rfc2616>] and
>         MUST all be unique strings.  The ABNF for the
>     I had already investigated this. This only talks about the
>     registry, not how values passed in the protocol are compared to
>     registered values. Nor does it explicitly say whether "unique
>     strings" is to be determined via case-sensitive comparison or
>     case-insensitive comparison.
>
> Is there any token example in RFC 2616 that is case sensitive?  As far
> as I can tell they are all case-insensitive, but I may have missed
> something. 
>
>     What is most *important* to me is that this be made entirely
>     clear, that IANA have clear instructions to enforce, and that both
>     websocket and data channel specs consistently specify what
>     implementations must do in this regard.
>      
>
>     It is less important to me *which* choice is made. My *preference*
>     would be minimally that the registry not permit two different
>     names that differ only by case. If that is so, then in some sense
>     it doesn't matter how implementations of the protocols do the
>     comparison.
>
> How likely do you see this being?  Anyone going to register XMPP
> (instead of xmpp) is going to be hurting themselves as much as users
> of xmpp if they actually use it.  I'm happy to clean this up at some
> point, but I find it hard to believe this is the biggest rock.
>
> regards,
>
> Ted
>  
>
>             Thanks,
>             Paul
>
>         regards,
>
>         Ted
>
>         <mailto:[email-masked] <mailto:[email-masked]>>

-- 
Surveillance is pervasive. Go Dark.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 Mar 2016 12:57:59 -0800

On Tue, Mar 8, 2016 at 12:07 PM, Harald Alvestrand <[email-masked]>
wrote:

> means that "1#token" is a comma-separated list of tokens, where each token
> is separated by LWS.
>
> So, what RFC 6455 says is:

        The request MAY include a header field with the name
        |Sec-WebSocket-Protocol|.  If present, this value indicates one
        or more comma-separated subprotocol the client wishes to speak,
        ordered by preference.  The elements that comprise this value
        MUST be non-empty strings with characters in the range U+0021 to
        U+007E not including separator characters as defined in
        [RFC2616 <https://tools.ietf.org/html/rfc2616>] and MUST all
be unique strings.  The ABNF for the
        value of this header field is 1#token, where the definitions of
        constructs and rules are as given in [RFC2616
<https://tools.ietf.org/html/rfc2616>].

I think that text is clear enough that comma is used as a separator of
sub-protocols and that "seperator charactors" are generally not allowed in
the elements.  So, I believe that faced with iam,thegreatest you would have
to parse it as two tokens: "iam" and "the greatest".

Ted

> Not only do we (or someone) have to decide whether "xmpp" matches "XMPP",
> we also have to decide whether "iam,thegreatest" matches "iam ,
> thegreatest"  or even "iam,
>> be minimally that the registry not permit two different names that differ
>> only by case. If that is so, then in some sense it doesn't matter how
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> --

---

From: Christian Groves <[email-masked]>
Date: Wed, 9 Mar 2016 14:02:50 +1100

Hello,

According to draft-ietf-mmusic-rfc4566bis-16 clause 5, SDP values are 
case significant unless specified otherwise. So that would make certain 
registered tokens such as MID case sensitive.

So if we're using a case sensitive SDP field to define to indicate the 
subprotocol then I think it would follow that DCEP should maintain the 
case sensitivity.

We might have similar issue for RTP/RTCP SDES e.g. BUNDLE MID 
(draft-ietf-mmusic-sdp-bundle-negotiation-27), CLUE ID 
(draft-ietf-clue-rtp-mapping-06). I don't think there's a general rule 
about maintaining case sensitivity for these cases?

Christian

On 9/03/2016 7:57 AM, Ted Hardie wrote:
> On Tue, Mar 8, 2016 at 12:07 PM, Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     means that "1#token" is a comma-separated list of tokens, where
>     each token is separated by LWS.
>
> sub-protocols and that "seperator charactors" are generally not 
> allowed in the elements.  So, I believe that faced with 
> iam,thegreatest you would have to parse it as two tokens: "iam" and 
> "the greatest".
>
> Ted
>
>     "XMPP", we also have to decide whether "iam,thegreatest" matches
>     "iam ,   thegreatest"  or even "iam,
>     All tokens registered so far are single tokens. Would it be
>     possible to advise against using identifiers with comma in them?
>
>>     On Tue, Mar 8, 2016 at 8:54 AM, Paul Kyzivat
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>                      [RFC2616 <https://tools.ietf.org/html/rfc2616>]
>>             and MUST all be unique strings.  The ABNF for the
>>         registry, not how values passed in the protocol are compared
>>         to registered values. Nor does it explicitly say whether
>>         "unique strings" is to be determined via case-sensitive
>>         comparison or case-insensitive comparison.
>>
>>         (Without any other information to go on I guess I would
>>         assume case-sensitive comparison.)
>>
>>     Is there any token example in RFC 2616 that is case sensitive? 
>>     As far as I can tell they are all case-insensitive, but I may
>>     have missed something.
>>
>>     The Postel principle seems to indicate that we should always use
>>     the registered form, but be willing to understand a case
>>     insensitive variant.
>>
>>         clear, that IANA have clear instructions to enforce, and that
>>         both websocket and data channel specs consistently specify
>>         what implementations must do in this regard.
>>
>>         It is less important to me *which* choice is made. My
>>         *preference* would be minimally that the registry not permit
>>         two different names that differ only by case. If that is so,
>>         then in some sense it doesn't matter how implementations of
>>         the protocols do the comparison.
>>
>>     (instead of xmpp) is going to be hurting themselves as much as
>>     users of xmpp if they actually use it.  I'm happy to clean this
>>     up at some point, but I find it hard to believe this is the
>>     biggest rock.
>>
>>     regards,
>>
>>     Ted
>>
>>           Thanks,
>>                 Paul
>>
>>             regards,
>>
>>             Ted
>>

---

From: Tim Panton <[email-masked]>
Date: Wed, 9 Mar 2016 12:12:10 +0000

> On 8 Mar 2016, at 12:43, Juergen Stoetzer-Bradler <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hello,
> 
> If a WebRTC endpoint uses the data channel establishment protocol in order to open a data channel, it may add a non-empty protocol identifier to the DATA_CHANNEL_OPEN message. Is the endpoint, which receives this DATA_CHANNEL_OPEN message, assumed to process this protocol id string in a case sensitive or case insensitive way? Or would that actually be up to the receiving WebRTC endpoint's implementation?

Since the sub-protocol definition in websockets seems to be non-normative, this feels like a matter we can leave to post 1.0 .

> Background is draft-ietf-mmusic-data-channel-sdpneg, where the subprotocol identifiers are signaled as part of an SDP attribute and where it is not yet clarified if these identifiers are assumed to be case sensitive or case insensitive.

I’m not sure I understand the point of draft-ietf-mmusic-data-channel-sdpneg - 
I think the new data contained in the ‘offer’ SDP is exactly that in the DCEP Open - and the 
‘answer' contains nothing other than an ACK or NACK of that offer?
That being the case, why doesn’t the offer side just open a DataChannel with the
required parameters and see if it gets ACK or reset back  - no additional SDP needed ? 

Tim.

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Wed, 9 Mar 2016 15:50:03 +0100

Ted, Paul, Harald, Christian,

Thanks for your replies.
Based on your feedback it seems to me that RFC 6455 and current draft-ietf-rtcweb-data-protocol may 
actually not unambiguously specify if (Websocket or data channel) subprotocol identifiers are 
compared case-sensitively or case-insensitively.

As far as I see, in case of DCEP, the situation with the 'Label' value might be similar.

Thanks,
Juergen

On 09.03.2016 04:02, EXT Christian Groves wrote:
> Hello,
>
> According to draft-ietf-mmusic-rfc4566bis-16 clause 5, SDP values are case significant unless 
> specified otherwise. So that would make certain registered tokens such as MID case sensitive.
>
> So if we're using a case sensitive SDP field to define to indicate the subprotocol then I think it 
> would follow that DCEP should maintain the case sensitivity.
>
> (draft-ietf-mmusic-sdp-bundle-negotiation-27), CLUE ID (draft-ietf-clue-rtp-mapping-06). I don't 
> think there's a general rule about maintaining case sensitivity for these cases?
>
> Christian
>
>
>> On Tue, Mar 8, 2016 at 12:07 PM, Harald Alvestrand <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> I think that text is clear enough that comma is used as a separator of sub-protocols and that 
>> "seperator charactors" are generally not allowed in the elements.  So, I believe that faced with 
>> iam,thegreatest you would have to parse it as two tokens: "iam" and "the greatest".
>>
>> Ted
>>
>>>     Is there any token example in RFC 2616 that is case sensitive?     As far as I can tell they 
>>> are all case-insensitive, but I may
>>>     have missed something.
>>>
>>     --     Surveillance is pervasive. Go Dark.
>>
>>

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Wed, 9 Mar 2016 15:50:25 +0100

Tim,

Thanks for feedback.
The SDP offer/answer extensions described in draft-ietf-mmusic-data-channel-sdpneg could be used if 
subprotocol related properties need to be negotiated, which go beyond the pure signaling of the 
subprotocol identifier. If no subprotocol properties need to be negotiated, then usage of DCEP may 
indeed be sufficient.
I mentioned this draft as I think that the case related processing of data channel subprotocol ids 
should be the same for SDP offer/answer based data channel subprotocol negotiation as for DCEP based 
data channel subprotocol negotiation.

Thanks,
Juergen

On 09.03.2016 13:12, EXT Tim Panton wrote:
>
>> On 8 Mar 2016, at 12:43, Juergen Stoetzer-Bradler <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hello,
>>
>> If a WebRTC endpoint uses the data channel establishment protocol in order to open a data 
>> channel, it may add a non-empty protocol identifier to the DATA_CHANNEL_OPEN message. Is the 
>> endpoint, which receives this DATA_CHANNEL_OPEN message, assumed to process this protocol id 
>> string in a case sensitive or case insensitive way? Or would that actually be up to the receiving 
>> WebRTC endpoint's implementation?
>
>> Background is draft-ietf-mmusic-data-channel-sdpneg, where the subprotocol identifiers are 
>> signaled as part of an SDP attribute and where it is not yet clarified if these identifiers are 
>> assumed to be case sensitive or case insensitive.
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 10 Mar 2016 20:02:05 +0100

Den 09. mars 2016 15:50, skrev Juergen Stoetzer-Bradler:
> Based on your feedback it seems to me that RFC 6455 and current
> draft-ietf-rtcweb-data-protocol may actually not unambiguously specify
> if (Websocket or data channel) subprotocol identifiers are compared
> case-sensitively or case-insensitively.
> 

Having thought a little more about this, I think the answer is actually
out of scope for this WG.

In my opinion: The subprotocol and label attributes MUST be transported
unchanged from the source to the destination. This protocol has no
operation whereby one compares the values to anything. Therefore, this
protocol should say nothing about how to compare them.

Harald

---

From: Ted Hardie <[email-masked]>
Date: Thu, 10 Mar 2016 12:12:38 -0800

On Thu, Mar 10, 2016 at 11:02 AM, Harald Alvestrand <[email-masked]>
wrote:

> unchanged from the source to the destination.

So far, I agree.

> This protocol has no
Does this equate to your taking an action item to specify the comparison in
the API?

Ted

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 10 Mar 2016 21:51:10 +0100

On 03/10/2016 09:12 PM, Ted Hardie wrote:
> On Thu, Mar 10, 2016 at 11:02 AM, Harald Alvestrand
> Does this equate to your taking an action item to specify the
> comparison in the API?

The Javascript API specified in WebRTC doesn't have any business
comparing them either.

Once we have a specification that says "if the incoming value of the
protocol field matches <X>, then...", that specification needs to say
what "matches" means.

Currently we don't have one in either of our WGs.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Mar 2016 22:00:37 -0500

> protocol should say nothing about how to compare them.

If that is the case, where should the specification of this belong?

The protocol is pretty useless if it says we exchange a token to agree 
on the subprotocol but doesn't specify how we determine what the token 
means.

I think the minimal safe thing to do is to forbid the registration of 
values that differ only in case. Then, a case-sensitive implementation 
can interoperate with a case-insensitive implementation withou problem 
as long as they use only registered values.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Mar 2016 22:09:52 -0500

On 3/8/16 2:22 PM, Ted Hardie wrote:
>     I had already investigated this. This only talks about the registry,
>     not how values passed in the protocol are compared to registered
>     values. Nor does it explicitly say whether "unique strings" is to be
>     determined via case-sensitive comparison or case-insensitive comparison.
>

While I think the Postel principle is often good practice for 
implementers, it is still a DWIM approach. It only works in cases where 
there is only one reasonable interpretation of what to do. If it is 
relied upon, then it becomes an unwritten normative requirement.

At the end of the day DWIS is more reliable than DWIM.

Being explicit is a cheap way of avoiding future trouble.

>     What is most *important* to me is that this be made entirely clear,
>     that IANA have clear instructions to enforce, and that both
>     would be minimally that the registry not permit two different names
>     that differ only by case. If that is so, then in some sense it
>     doesn't matter how implementations of the protocols do the comparison.
>
> (instead of xmpp) is going to be hurting themselves as much as users of
> xmpp if they actually use it.  I'm happy to clean this up at some point,
> but I find it hard to believe this is the biggest rock.

I think we already have encountered a case where MSRP has been proposed 
to be spelled "MSRP" and "msrp", once for websocket use and once for 
data channel use. (I am not sure of this, and don't want to go look it 
up right now.)

Technically that might not be a problem, but it would be at least 
annoying and a source of confusion.

	Thanks,
	Paul

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

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 Mar 2016 09:41:26 +0100

> as long as they use only registered values.

The specification that sets up the registry seems like the logical place.

Amending RFC 6455 (WebSocket), anyone? Errata? Updating document?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Mar 2016 20:09:46 +1100

On 11 March 2016 at 07:51, Harald Alvestrand <[email-masked]> wrote:
> protocol field matches <X>, then...", that specification needs to say what
> "matches" means.
>

Thankfully.  We probably should use USVString rather than DOMString so
that we can avoid the Unicode issues that DOMString creates, but other
than that, I don't see any future in standardized values for protocol,
it is simply too poorly defined.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 Mar 2016 13:33:44 +0100

> it is simply too poorly defined.

Good idea, https://github.com/w3c/webrtc-pc/issues/543 filed.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 11 Mar 2016 10:44:04 -0800

> Amending RFC 6455 (WebSocket), anyone? Errata? Updating document?
Okay, the message asking if there is any heartburn on this change is in a
moderation queue; I'll report back when I hear anything.  A cursory glance
at libwebsockets repo on github only shows case-sensitive matching during
the pick function, but I still think folks would be happy to avoid the
confusion.

Ted

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Mar 2016 14:13:25 -0500

On 3/11/16 1:44 PM, Ted Hardie wrote:
> On Fri, Mar 11, 2016 at 12:41 AM, Harald Alvestrand
> Okay, the message asking if there is any heartburn on this change is in
> a moderation queue; I'll report back when I hear anything.  A cursory
> glance at libwebsockets repo on github only shows case-sensitive
> matching during the pick function, but I still think folks would be
> happy to avoid the confusion.

Yes. I don't really care what the answer is as long as it is clear.
Nor do I care what mechanism is used to clarify it. An erratum might be 
simplest if this sort of question is allowed to be handled that way.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Mar 2016 14:18:26 -0500

On 3/9/16 7:12 AM, Tim Panton wrote:
>> If a WebRTC endpoint uses the data channel establishment protocol in
>> order to open a data channel, it may add a non-empty protocol
>> identifier to the DATA_CHANNEL_OPEN message. Is the endpoint, which
>> receives this DATA_CHANNEL_OPEN message, assumed to process this
>> protocol id string in a case sensitive or case insensitive way? Or
>> would that actually be up to the receiving WebRTC endpoint's
>> implementation?
>
> Since the sub-protocol definition in websockets seems to be
> non-normative, this feels like a matter we can leave to post 1.0 .
>
>>

Note that DCEP is *optional* for data channels. The alternative is to 
externally agree on the use of channels. This is what the draft provides 
for.

	Thanks,
	Paul