>From the point of view of developer experience, meh, the degree of difficulty of generating/parsing JSON & form/url is about the same.
JSON has the advantage that it forces you to use UTF-8, and is more pleasant to debug when things get weird. For my money, anything that forces anyone to use UTF-8 is A Good Thing. -T On Mon, Feb 4, 2013 at 1:46 PM, Mike Jones <michael.jo...@microsoft.com>wrote: > I’m not proposing that we boil the ocean. “Diving in with both feet and > define a full RESTful API with all appropriate verbs and CRUD ops” is an > almost sure way to build a complicated spec, most of which isn’t needed, > and to have it take a long time.**** > > ** ** > > Everything in the current OpenID Registration spec is motivated by an > actual use case. Stuff that isn’t isn’t in the spec. That’s nearly true > of the closely-related OAuth Registration spec, with what I believe to be a > few exceptions. (Yes, we should harmonize those differences – hopefully > based upon real use cases.)**** > > ** ** > > I was only proposing that we answer the single question of whether we’re > using the right input format or not. I hope we can keep the discussion to > that topic and not use it to generate a passel of new work items as a side > effect.**** > > ** ** > > -- Mike*** > * > > ** ** > > *From:* Richer, Justin P. [mailto:jric...@mitre.org] > *Sent:* Monday, February 04, 2013 1:34 PM > *To:* Mike Jones > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Should registration request be form-urlencoded > or JSON?**** > > ** ** > > For history, the original UMA registration spec from whence this all grew > was JSON-in and JSON-out. It's feeling like this is coming back around. ** > ** > > ** ** > > Pro:**** > > - more REST-ish (particularly if we use real REST style like URL > templates and verbs)**** > > - consistent data structures**** > > - possible use of rich client data structures like lists and sub-objects* > *** > > ** ** > > Con:**** > > - unlike the rest of OAuth, which is form-in, JSON-out**** > > - major change from existing code**** > > - possible overhead for existing OAuth libraries which haven't had to > deal with JSON from clients**** > > ** ** > > ** ** > > ** ** > > If we're going to do this, we should dive in with both feet and define a > full RESTful API with all appropriate verbs and CRUD ops, and define it at > the OAuth DynReg level as well.**** > > ** ** > > ** ** > > -- Justin**** > > ** ** > > On Feb 4, 2013, at 4:25 PM, Mike Jones <michael.jo...@microsoft.com>**** > > wrote:**** > > > > **** > > Now that we're returning the registration state as JSON, it's pretty > inconsistent for the registration request to instead be form-url-encoded. > The case can be made for switching to JSON now - especially in light of > possibly wanting to convey some structured information at registration time. > **** > > I realize that this is a big change, but if we're going to do it, we > should do it now.**** > > As a precedent, apparently SCIM requests are JSON, rather than > form-url-encoded.**** > > **** > > -- Mike*** > * > > **** > > _______________________________________________ > 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
