Re: [OAUTH-WG] Possible alternative resolution to issue 26

[Julian Reschke <[e-mail]>]

On 2011-10-10 01:08, Manger, James H wrote:
>> You can't "replace" quoted-string.
>>
>> A recipient will have to be able to parse multiple challenges in a
>> single header field value. To do so, it has to understand the syntax of
>> params using double quotes. It can't special-case the parsing based on
>> what part of the set of challenges it currently is looking at (because
>> to do so, it needs to have parsed them first).
>
> Parsing is not affected. Only un-escaping after parsing.
>
> Even if you did generic un-escaping before reaching code that
> understood a specific parameter (and I'm not sure that is likely),

It is possible. There is code out there that does it.

> you still don't need to special-case the un-escaping. You can interpret it
> all like JSON as no quoted-string value in practise will escape an
> alphabetic letter (a-z). Not only would it be pointless for the sender to
> do so, they would also be violating a "SHOULD NOT" in the spec.
>
>     Senders SHOULD NOT escape octets in quoted-strings that do not
>     require escaping (i.e., other than DQUOTE and the backslash octet).
>     [draft-ietf-httpbis-p1-messaging-16#section-3.2.3]

It still is a violation of the spec if you do so.

>> If we were free to change things, we'd simply state that everything is
>> UTF-8.
>
> But that would break things.
> I am only suggesting changing the interpretation of \u because
> I don't believe it will break any existing values.
>
>
>> But that argument doesn't change the fact how it is defined.
>
> Changing defined behaviour is not great.
> Changing defined behaviour that is *never used* (eg "\u" as an
> escape sequence for "u") doesn't sound so unreasonable.

Again, if you believe this is a good idea, the place to argue this is 
the HTTPbis WG, and not inventing something specific for OAuth.

Best regards, Julian