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

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 
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>
>     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.
>
> 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,
>     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
>>     <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>> wrote:
>>
>>
>>                      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
>>
>>
>>         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.)
>>
>>     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.
>>
>>         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
>>
>>                 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
>>             rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>>             <mailto:rtcweb@ietf.org <mailto:rtcweb@ietf.org>>
>>             https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>>
>>             _______________________________________________
>>             rtcweb mailing list
>>             rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>>             https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>         _______________________________________________
>>         rtcweb mailing list
>>         rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>>         https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>>
>>     _______________________________________________
>>     rtcweb mailing list
>>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>     -- 
>     Surveillance is pervasive. Go Dark.
>
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb