On 2011-12-31 20:40, Mike Jones wrote:
Maybe I misunderstood your position. If you agree that '\' may not occur in the INPUT string, then
that issue can be closed. That was the working group consensus position, per the cited e-mails. I
thought that you were arguing that syntax restrictions on the parameters should only be placed upon
the OUTPUT string - which forces all implementations to support unnecessary encodings like
"\a\b\c" for "abc". Please let me know whether you're fine with the working
group prohibiting the use of '\' in the input string as the spec presently currently does.
I'm not ok with that; because it's totally besides the point.
A recipient of WWW-Authenticate needs to use a proper parser for that
header field. And if you use a proper parser, it doesn't matter.
I'm not saying anybody should send something like that. What I'm saying
is that you shouldn't create an illusion that a recipient doesn't need
to deal with it.
A recipient that can't handle quoted-string syntax in auth-params is
broken. A recipient that can't handle token syntax in auth-params is
broken as well.
Finally, please re-read what I said: the syntax of the challenge is
defined by HTTP. The bearer spec can't change the parsing rules, because
you need a generic parser to properly handle header fields containing
multiple challenges. Once that generic parser has done it's job, it
should not matter anymore whether a value used the token syntax or the
quoted-string syntax, and also it shouldn't matter anymore where
unescaping has taken place or not.
What you're trying to do is comparable with defining an XML vocabulary
where you profile how an attribute is serialized (' vs ", character
encoding, escaping). Don't.
Best regards, Julian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
