On 2011-09-26 21:03, Mike Jones wrote:
... No, b64token isn’t always there; the syntax specifies that either a b64token OR one or more auth-params will be present. Yes, that’s intended.
OK then; just checking :-) > ...
This was the working group decision at the interim meeting and is used in both the core and bearer drafts. I believe that UTF-8 is a reasonable outcome. Unless there’s a clear consensus to change both specifications, I believe that this should stay as-is. ...
This is a serialization issue. Just because one encoding is right in one place doesn't mean it's right somewhere else.
> There was an explicit working decision not to include language codes. I didn't ask for language codes :-) OK. Others had been asking for them before the interim meeting, hence my confusion. > This is recorded in the meeting minutes sent to the list by Hannes > Tschofenig on 6/3/11. The key part of the minutes is: > > *** Error Description *** > > Agreement among the participants that the error codes are meant for > consumption by the developer rather than the end user. Hence, language > codes are not important nor a human readable version that is supposed > to be understood by end users. In which case I recommend to stick to plain ASCII. Again, the working group explicitly decided to move from plain ASCII to UTF-8. ...
I think you need to make a conscious decision about the purpose. If it needs to support non-ASCII then using raw UTF-8 in the param may cause problems as explained above.
... > The reply syntax is intentionally restricted to simplify implementations. Special-casing the syntax *complicates* implementations. Using common constructs allows re-using existing parsing code and thus make things easier. Consider a browser seeing the credentials. It needs to parse the field value for multiple challenges, and the only way for this to work is to have predictable syntax for parameters. The philosophy behind the syntax restriction is that interoperability is often increased if implementations are prepared to handle all the cases that may arise. Having these cases be part of a fixed, enumerated set helps achieve this. Parsing is the easy part; understanding and meaningfully handling the semantics of the messages is the harder part, which is why this restriction intentionally imposes boundaries – so as to limit the cases that implementations need to be prepared handle.
First of all: it's pretty clear that you haven't written a conforming parser for WWW-Authenticate yet; you may want to look at the test cases at <http://greenbytes.de/tech/tc/httpauth/>.
Parsing definitively is *not* simple, and adding special cases over the generic syntax will make it even harder.
In particular, using double quotes for something that isn't a quoted string is incompatible with the base syntax. (Yes, this is a show-stopper).
> 4. IANA Considerations > > -> If you have a dependency on HTTPbis then you should also add the > > registration for the authentication scheme as defined in HTTPbis P7. > > Done Thanks. Now that you have switched to HTTPbis you probably can get rid of the reference to RFC 2617. The remaining reference is informational – not normative. ...
Yes, but what is it for? Best regards, Julian _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
