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

On 2011-10-31 21:25, Yutaka OIWA wrote:
> 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.

I disagree. It's just a syntactical difference.

> 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?

In P2, we say:

"Many header fields use a format including (case-insensitively) named 
parameters (for instance, Content-Type, defined in Section 6.8 of 
[Part3]). Allowing both unquoted (token) and quoted (quoted-string) 
syntax for the parameter value enables recipients to use existing parser 
components. When allowing both forms, the meaning of a parameter value 
ought to be independent of the syntax used for it (for an example, see 
the notes on parameter handling for media types in Section 2.3 of [Part3])."

> 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.

See above.

> I am not favor of this idea, because it also breaks existing implementations.

For instance?

>> 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.

And I believe that we need to make this statement for parameters in HTTP 
header fields as well.

Do you have an example where this interpretation breaks current 
implementations?

Best regards, Julian

Received on Monday, 31 October 2011 21:12:23 UTC