The original spec says to sort the encoded names, then the encoded values. And encoding assumes everything is in UTF-8 as input: "Text names and values MUST be encoded as UTF-8 octets before percent-encoding". The problem is, it doesn't clearly defines what 'Text' means, so this was my attempt as making it simpler.
The c%40 and c2 is a mistake in the spec (was already raised on the IETF list). I will fix it in the next draft. I would guess most libraries do not UTF-8 encode. I know Twitter has a lot of non-ascii text so it would be interesting to see what happens there with their OAuth implementation. As for the rest of this discussion, we can't change core 1.0 so if you want to fix this, we can add it to the IETF issues list for the new version. EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Ben Laurie > Sent: Tuesday, March 10, 2009 3:16 AM > To: [email protected] > Subject: [oauth] Re: OAuth Core 1.0 "Editor's Cut" > > > On Tue, Mar 10, 2009 at 9:56 AM, Tim Fletcher <[email protected]> > wrote: > > > >> As always, feedback is greatly appreciated. > > > > The example parameters in Section 3.3.1.2 (Normalize Request > > Parameters) suggest that "c%40" comes after *after* "c2" when sorting > > by lexicographical byte value ordering. > > > > I would have expected it to be the other way around ("%" is ASCII 37, > > "2" is ASCII 50, 37 is less than 50). > > It isn't very clear, but I read that as byte ordering of the actual > names/values, rather than their encoding. However, since encoding also > includes a step converting to UTF-8, which is presumably not always > reversible, this doesn't sound like such a good plan - so sorting > needs to be done after conversion to UTF-8, and so either conversion > should be split into two steps, i.e.: > > 1. Convert to UTF-8 > 2. Sort > 3. URL encode > > in which case c%40 comes after c2, or sorting should be after encoding, > i.e.: > > 1. Encode > 2. Sort > > in which case you are correct that c%40 should come before c2. > > Obviously the choice is dictated by existing OAuth - unfortunately the > existing spec isn't clear so I guess the question is: what does > existing code do? I'm betting it does: > > 1. Sort > 2. Convert to UTF-8 > 3. URL encode > > which is the one case that can't be right, I thin. > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
