You proposed, Julian "3. Do not specify the ABNF. The ABNF of the WWW-Authenticate is defined in HTTPbis. Just state the names of the parameters, their syntax *after* parsing and their semantics."

About some of Mark Nottingham's comments, Barry wrote "Let me point out that "this represents working-group consensus" is not always a valid response.  If the working group has actually considered the *issue*, that might be OK.  But if there's consensus for the chosen solution and someone brings up a *new* issue with it, that issue needs to be addressed anew."

Relative to these two statements, I believe that I should remark at this point that your proposed semantics of only considering the syntax after potential quoting was explicitly considered earlier by the working group and rejected.  The consensus, instead, was for the present "no quoting will occur for legal inputs" semantics.

I believe that in the New Year the chairs and area directors will need to decide how to proceed on this issue.  (The working group consensus, as I see it, is already both well-informed and clear on this point, but I understand that that's not the only consideration.)  It would be good to see the spec finished shortly.

				Best Wishes,
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Monday, December 19, 2011 2:38 AM
To: Mike Jones
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer draft 15?

On 2011-12-19 02:00, Mike Jones wrote:
> ...
> ON SPECIFYING ONLY A QUOTED-STRING SERIALIZATION:
>
> I understand and agree with your desire to promote code reuse.  You cite HTTPbis P7 2.3.1 to support adding a requirement for supporting token serialization in addition to quoted-string serialization for all parameters.  I believe that the relevant text there is:
>        When the auth-param syntax is used, all parameters ought
>        to support both token and quoted-string syntax, and syntactical
>        constraints ought to be defined on the field value after parsing
>        (i.e., quoted-string processing).  This is necessary so that
>        recipients can use a generic parser that applies to all
>        authentication schemes.
>
>        Note: the fact that the value syntax for the "realm" parameter is
>        restricted to quoted-string was a bad design choice not to be
>        repeated for new parameters.
>
> First, it's my understanding that this text was added between -16 and -17 explicitly to try to force a change the definitions used in the Bearer spec.  While this seems heavy-handed, be that as it may.   Assuming the specification remains as-is, I think there are two code reusability cases to consider:
> ...

The text change was caused by both the early interactions with OAuth (mainly thanks to James), and the fact that we see that was defined for Realm isn't implemented in practice (<http://greenbytes.de/tech/tc/httpauth/#simplebasictok>).

(Note: we had a working feedback loop between WG's here; that's a feature)

If you disagree with what HTTPbis P7 now says than you really really ought to come over to the HTTPbis WG's mailing list (*) and argue your point.

(*) Similarly to how I'm arguing my point over here.

> Recipient Case:  Recipients are able to use code capable of parsing both token and quoted-string syntax to parse fields that may only contain quoted string syntax.  Thus, the rationale for this requirement given in P7 is actually incorrect; recipients *can* use a generic parser that applies to all authentication schemes.  (Perhaps P7 should be corrected?)  There is no code-reuse problem for recipients.

Yes, there is. As the test case above shows, all UA recipients accept both forms; none of them rejects the token syntax. This is a problem as people frequently do not code against specs but just do "what works".

I'm pretty sure that changing a UA's behavior here would cause breakage in practice.

> Producer Case:  I will grant that it is possible for generic parameter producer code to exist that does not give the caller control over how the parameter is serialized.  If such code is used, it would be possible for a parameter value such as "xyz" to be erroneously serialized as xyz, thus creating an interoperability problem.  Note however, that serialization of the HTTP-defined realm parameter MUST occur using quoted-string serialization.  Thus, in practice, it would seem that generic frameworks still need to enable callers to control the serialization formats of specific parameters.  Hence, I doubt that this problem-in-theory is actually a problem-in-practice.  I'd be interested in data points from the working group about whether HTTP frameworks they use would have his problem in practice or not.
>
> It seems that there are two possible resolutions to this issue:
>
> 1.  Change the spec to allow both quoted-string and token serialization for these parameters.
>
> 2.  Leave the specification as-is.
> ...

3. Do not specify the ABNF. The ABNF of the WWW-Authenticate is defined in HTTPbis. Just state the names of the parameters, their syntax *after* parsing and their semantics.

Best regards, Julian