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
