RE: Editorial issues with RFC 7616

Hi,

>> Ok, but how does it work in general, then?
>>
>> For example, assume I have a parameter foo that allows both token and quoted-string parameter values.
>>
>> I then define/register the value "BAR". Does that mean that "BaR", "bar", "Bar" etc are now allowed - unless explicitly indicated, as in the case of charset?
>> ...
>
> They are "allowed" in any case (syntactically).

Sure. Bad wording.  What I meant was whether they are semantically identical.

>If the parameter is defined to be case-sensitive, then yes, they are different. Otherwise they would be equivalent.
>
>Note that that is true for the token form as well (it allows both upper and lowercase).

So, what are the case-sensitivity rules for 'userhash', 'domain', 'nonce', 'opaque' and 'algorithm' auth parameters? 

Section 2.1 of RFC 7235 *DOES* say:

   "Authentication parameters are name=value pairs, where the name token
   is matched case-insensitively, and each parameter name MUST only
   occur once per challenge."

So, based on that one could assume that case-insensitive is the default, unless otherwise explicitly specified. So far so good.

However, for a couple of parameter there is explicit text saying that the value is case-insensitive:

For the 'stale' parameter RFC 7616 explicitly says:

      "A case-insensitive flag indicating that the previous request from
      the client was rejected because the nonce value was stale."

For the 'charset' parameter RFC 7617 (which, btw, is only informatively referenced by RFC 7616) explicitly says:

   "The only allowed value is "UTF-8"; it is to be matched case-
   insensitively (see [RFC2978], Section 2.3)."


So, assuming that the default is case-insensitive, perhaps that can be clarified in an errata. I think it is related to my issue Q1.

Regards,

Christer

Received on Wednesday, 30 June 2021 12:16:41 UTC