Now, this is useful. I think this raises a very good point. Unless we expect the server response to always be just key/value pairs (regardless of the chosen serialization), we cannot support multiple formats. If we decide on limiting to a flat key/value pairs, the value of multiple formats is significantly reduced (but still somewhat useful).
EHL > -----Original Message----- > From: Yaron Goland [mailto:yar...@microsoft.com] > Sent: Monday, May 17, 2010 2:58 PM > To: Kris Selden; Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) > > My concerns with C are twofold. > > First, it's unclear to me how we will successfully reason about OAuth's data > model when the three proposed formats all have mutually incompatible data > models? > > | Forms | JSON | XML > Nesting | NO | YES | YES > Multi-Value Fields | NO | YES| NO[1] > Typing | NO | YES | NO[2] > Namespaces | NO | NO | NO > Objects | NO | YES | YES[3] > > [1] There is no formal definition in XML for multi-value fields although one > can build them using nested elements [2] XML does have XML schema but > most parsers don't natively support it [3] XML actually has two different > kinds > of objects, elements and attributes. > > Will we dumb down JSON and XML to the point where they match Forms? In > other words, per Kris's mail, is OAuth's data model just name/value pairs? > That can work but then it calls into question why the heck we bothered > supporting JSON or XML in the first place if we are essentially just using > them > as Forms? It seems almost cruel to dangle the richer data models of JSON and > XML in front of people and then pull them back with a restriction that we > only do name/value pairs. > > Will we support JSON's data model? In which case do we intend to add > typing, arrays, etc. to forms and ban attributes and namespaces from XML? > > Will we support XML's data model? In which case do we intend to add name > spacing and attributes to forms and JSON while banning all types but string > along with arrays in JSON? > > Or maybe we'll simply assert the existence of three different worlds where > every extension is defined in a completely different context independently > of each other? So every extension to OAuth has to, in essence, be defined > three separate times? > > Second, as a burden on server implementers we are requiring that they > possess and test three different parsers. I think this is unnecessarily > onerous > and all but guaranteed to lead to interoperability issues as server > implementers will focus primarily on the particular syntaxes they think will > see the most use and give less attention to other others. This is an > inevitable > trade off given the difficulties of fully testing even basic formats. > > Thanks, > > Yaron > > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Kris Selden > > Sent: Friday, May 14, 2010 1:29 PM > > To: Eran Hammer-Lahav > > Cc: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) > > > > The only reason I've heard was interoperability but it is always > > stated as patently obvious without a given reasoning. My assumption is > > this is concern of OAuth 2 client library authors who don't want to > > depend on 3 parsing libraries but want to state they can inter-operate with > any OAuth 2 provider. > > > > I have a suggestion to mitigate the client library dependency issue, > > an argument for why C is more "interoperable" (even why the server > > should be not be required to support all 3 formats), comments on > > encoding, and percent encoding issues with OAuth 1. > > > > Basically, what OAuth providers return are key/value pairs and this > > discussion is really an issue of serialization. > > > > Instead of depending on libraries, client providers could have a > > interface for serialization that takes a mime type and string and > > returns a structure of key value pairs. That way if I've already > > chosen libyajl (which it is, even though it is UTF8 only) as my favorite > > JSON > library, I can plug it in. > > > > Chances are your client library is going to still be more bloated than > > me just writing to a testable spec for the flows I need. Maybe even > > unusable simply because I'm using an API from an application on an > > evented server and your library uses blocking I/O for making the requests. > > > > On to why C is more interoperable and why as a consumer having it just > > be one format, doesn't help me unless I'm only using JSON APIs, it > > only helps the OAuth 2 client library developer. > > > > Let's say API A supports JSON, API B supports XML and API C supports > > both (as many APIs do, oh no the horror of the QA matrix). > > > > If I'm consuming API A, be nice if the OAuth 2 endpoint used JSON. If > > I'm consuming API B would be nice if the endpoint supported XML. If I > > needed both A and B, I need 2 parsers anyways, so what the endpoint > > did doesn't matter but I would pick JSON. If A and C I would want > > JSON. If B and C I would want XML. > > > > On the server side, would be nice if a service could match the OAuth > > endpoint format. I don't really see a need to support all 3 since in > > order to use my JSON only API you need a JSON parser anyway. > > > > There is little point to an API support multiple formats as many do if > > the OAuth endpoints require JSON only. > > > > If my service is just a REST storage API, accepting binary files like > > images, I just want whatever the simplest to parse in which case I > > would like form- encoded. I really don't see why people think that > > format is complicated, been in use a long time, there is lots of > > library support, and is more trivial to write your own parser than both JSON > and XML. > > > > The problem with application/x-www-form-urlencoded that was > > complicated in OAuth 1, had to do with signature base strings because > > some characters could be optionally encoded and various libraries did > > this. Here we are talking about key/value pair serialization that HTML > > forms have been using for a long time. The percent encoding is of > > bytes and the bytes character set is defined by the charset in the > > response header. Would not matter if some characters were optionally > percent encoded, they would still be decoded. > > > > While a lot of clients may not have an > > application/x-www-form-urlencoded parser, this problem is way > > overblown. Most have a percent-encoding decoder, needed just to parse > > URLs. Splitting on & and = then replacing + with space is trivial. > > This can easily be done in JavaScript, which is where I suspect some of the > JSON only momentum is coming from. > > > > Not all JSON libraries handle the NULL position UTF detection in the > > RFC 4627, some just assume UTF8 only. I'm guessing supporting the > > other Unicode transfer encodings isn't all that popular since UTF8 is a > superset of ASCII. > > > > Even though JSON maybe the way of the future, more SDKs like the > > iPhone come with a XML parser and you'd need to find a third party > > JSON parser or roll your own. > > > > As for the QA matrix, APIs that have handled multiple formats, have > > one output structure that is serialized to different formats which > > helps mitigate testing complexity. Test the one output, then test that > > that structure can be serialized to the supported formats. You may > > make that one structure JSON, then have a filter that can translate it to > XML. > > > > For OAuth, I think it would increase interoperability if the output > > was considered key/value string pairs and multiple serialization > > formats were available, requested through the Accept header. > > > > Or I guess you can make it so OAuth is only for JSON APIs because JSON > > is the future. Though I seem to remember that being said about XML not > long ago. > > Maybe I'm getting old. I guess I shouldn't use RSS and Atom feeds > > because they are so last year. > > > > I'm for option C plus relaxing the all 3 formats support to > > recommended but not required. > > > > On May 13, 2010, at 4:43 PM, Eran Hammer-Lahav wrote: > > > > > Can you give a reason why you are objecting to C. > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: Robert Sayre [mailto:say...@gmail.com] > > >> Sent: Thursday, May 13, 2010 4:27 PM > > >> To: Eran Hammer-Lahav > > >> Cc: Yaron Goland; OAuth WG (oauth@ietf.org) > > >> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) > > >> > > >> On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav > > >> <e...@hueniverse.com> wrote: > > >>> There is clearly no consensus for either A or B. There was mostly > > >>> no objection to C, and the reason given by most of those who > > >>> objected was > > >> client complexity with the current proposal solves. > > >> > > >> My objection to C was that your examples were buggy. So, to be > > >> tediously > > >> explicit: > > >> > > >> B, then A. Not C. > > >> > > >> - Rob > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
