On 10 mrt 2009, at 13:15, Ben Laurie wrote: > On Tue, Mar 10, 2009 at 12:08 PM, Marc Worrell <[email protected]> > wrote: >> So, which fields are for human consumption and which not? I >> wouldn't let my >> library make this guess, so better not encode/decode at all and >> just pass >> what was given to it by the application. > > There's no reason your library should guess - it can be told, surely?
It can be told. It can be told for every possible incoming and outgoing key (and value) in what encoding it is. It can also not be told, and just accept the octet streams you want to transport and sign. And deliver those octet streams to the application, just as-is, without magic. I prefer to just assume octet streams. Lots simpler. Less code. Less debugging. Less mess. More time for other things. Most libraries for languages without native UTF-32/16 character types will assume byte streams anyway. Is anybody re-encoding Windows-1250 into UTF-8 before signing? Just keep it simple. And keeping it simple might mean transcoding all your UTF-whatever into an octet stream before pushing it into your transport-layer-with- oauth-signing. Which makes it completely according to the specs, but without the complications for the library. - Marc --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
