So we have two competing good ideas. 1 include an ABNF directly and codify what is expected to to work at the cost of flexibility. 2 Reference RFC 2617 itself referencing RFC 2616 to allow for a future fix to the encoding limitations to be automatically picked up by OAuth if RFC 2617 is updated.
My observation is that if we are having a hard time deciding this, a developer is going to as well. My vote is for directly including the ABNF. I also want to note that I think the ABNF for client-id is wrong. It should exclude ":". Colon is used as a field separator by Basic (god help us) if you allow it it will blow up parsing. *<TEXT excluding ":"> That is probably the most important thing I realized in this exercise. On 2012-06-10, at 8:55 PM, Mike Jones wrote: > Hi Julian, > > As background, the reason for the special ABNF is to satisfy a DISCUSS raised > by Sean Turner specifically that specifically requested a comprehensive ABNF. > I believe that these very discussions show how valuable Sean's request is to > improving the clarity of the spec for implementer's, as even some experts on > the list hadn't completely worked through syntax consequences of the > dependent specs used, whereas as the ABNF makes the syntax restrictions > obvious. I believe this has improved the clarity of the spec and likely > improved interoperability of implementations because of it. > > Best wishes, > -- Mike > > -----Original Message----- > From: Julian Reschke [mailto:[email protected]] > Sent: Sunday, June 10, 2012 12:46 PM > To: Mike Jones > Cc: [email protected] > Subject: Re: Discussion needed on username and password ABNF definitions > > On 2012-06-10 20:50, Mike Jones wrote: >> Thanks for your reply, Julian. >> >> Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest", >> and they're required to be used with Basic, I believe that that confirms >> that username and password must either be ASCII or ISO-8859-1, and given >> that several people have written that ISO-8859-1 is a "non-starter", that >> effectively confirms the current syntax in -27 that username and password >> must be ASCII. Do you agree or am I missing a nuance here? > > I don't understand OAuth enough to know whether a constraint of Basic and > Digest should affect OAuth in general. > > Also, we actually might be able to *fix* these schemes, in which case it > would be unfortunate if OAuth adopted the constraint in a way that makes it > hard to update. > > I believe the right thing to do is not to have a special ABNF; but instead to > just note that when these protocol elements need to be used with Basic or > Digest, the respective constraints of these schemes apply. > >> Julian, there was one aspect of the open issue that you didn't reply to: Do >> you have an opinion on whether client_id and client_secret should be >> restricted to the same characters as username and password? This seems >> logical to me, as they are objects of the same kind as username and >> password, but I also sympathize with your sentiment that "we shouldn't >> extend this problem to anything new we define". On the other hand, given >> that client_id and client_secret are for machine (and not for human) >> consumption, I don't see any more need for internationalization of these >> fields than there was for scope (which the working group decided to limit to >> ASCII). > > I'll leave that to the WG :-) > > Best regards, Julian > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
