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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
