Re: #320: add advice on defining auth scheme parameters

2011/10/30 Julian Reschke <julian.reschke@gmx.de>:
>> I don't think it is a bad idea, as long as ["realm=" token] pattern is
>> not valid.  (because it is equivalent to use a generic parser first and
>> then to require quoted-string as a value.)
>> ...
>
> The issue is that - depending on the API - after you have run a generic
> parser you simply might not have that kind of information.

Hmm, I don't agree with this idea, actually.
Tokens (meanings usually defined for each token except general integers etc.)
has a distinct semantics than strings in general.
If the spec meant to allow special characters (e.g. commas)
in some parameters, that should be limited to quoted-strings
on the sender side.

For receivers side, I agree that some parsers takes drops the distinctions
between tokens and strings, and because of that I agree that new
specifications should not overload tokens (1, 2, 3 etc.) and
_equivalent_ strings ("1", "2", "3") for having a different meaning,
supporting "the RFC1123 way" of parsing.
Can't it be phrased in this way?

If we meant that quote-string is just a way to "quote tokens with commas etc",
we should have have clear definitions for equivalence between tokens
and strings, and ask every implementors to implement in that way.
I am not favor of this idea, because it also breaks existing implementations.

> It's comparable to require an XML attribute to be quoted with single quotes,
> and to disallow double quotes. It can be made to work by customizing the
> parser, but why would you want to?

No, in XML cases, single quotes and double quotes has been clearly
defined to be two representations of the same thing.
There is a clear semantic definitions, a definition how to compare these twos,
and a definition that anyone should not distinguish between these.

Received on Monday, 31 October 2011 20:26:18 UTC