Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The

[Bjoern Hoehrmann <[e-mail]>]

* Mike Jones wrote:
>Thanks for asking, Martin.  That's effectively what the spec does
>already.  It restricts the input values of these parameters to be quoted
>strings containing no backslashes.

Most XML parsers do not tell you, and most XML generators do not allow
you to control, the difference between <x y='z' /> and <x y="&#x7a"/>.
You could make a specification that says the value of the y attribute
on the x element must not be z, but it stops there. The difference be-
tween the two XML elements is in the lexical space, not in the value
space, the attribute value in both cases is "z", it's just encoded in a
different form.

Try writing a C function `int example(int i)` that returns `1` when it
is called like `example(00)` but returns `0` for `example(0)`. Without
some hack you can't do that because the C specification defines that it
does not matter whether you write `0` or `00` for an int. Same problem,
just as the C specification does not give you an interface to tell the
two inputs apart, the HTTP specification does not give you an interface
that allows you to tell `x` and `"x"` apart in this particular case. If
the draft said "When using WWW-Authenticate: Bearer ... then the header
name must be written `wWw-authenTICate`, same problem. HTTP says case
does not matter, and if another specification says "Yes, it does" then
it is overriding the underlying specification, to some degree anyway.

This is not always wrong, you might have coding guidelines for example
that tell you to write `example( 0 )` instead of `example(0)` and that
may work well with limited scope, but with coding guidelines people are
typically aware that they impose limits on formally equivalent things,
along with the understanding that if someone ignored the restriction the
code would work just as well, but that does not seem to be quite the
case here. If I make another scheme, WWW-Authenticate: Example, and say
all the parameters must be tokens, not quoted strings, and the tokens
must not contain "q" characters, but they are case-insensitive so you
can use "Q" to the same effect, would that be just as well?

If you want to keep the distinction, you should offer an argument why
this is something individual schemes should regulate (since having the
same rules for all schemes is much simpler).
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/