Tim, I do not agree that it's harmful. If I removed the WF discussion off the table, I'm still having a hard time buying into everything you said in the blog post.
I implement various web services, largely for my own use. Usually, I implement all of them in XML, JSON, plain text (attribute/value pairs), AND JavaScript (for JSONP). For simple services, it's not hard. I do it because I sometimes have different wants/desires on the client side. (For more complex ones, I use XML.) For your point (1): For WebFinger, the format is simple. The XRD and JRD definitions exist and are clearly defined. I think the definitions of each are natural. It's not hard to produce both. For your point (2): That's a bias you have against XML, no two ways about it. I tend to prefer to run XML through a sax-style parser and pull out what I want. But, doing data binding is reasonable if one is dealing with complex data structures. WebFinger is not so complex that it would need to be done that way, but so what if developers did? It's their code. A lot of web services have been written that way, so let developers choose. You conclude with "use JSON". By that logic, we should send the HTML5 team back to the drawing board and have then re-write it in JSON. Oh, HTML is a document format. Complex JSON isn't? I'd argue it is whatever you want to put in it. In any case, I'm not going to object if the consensus of the group is to abandon XML entirely. I personally do not care which format(s) we use. What bothers me, though, is that we put a stake in the ground a few years ago and people were happy until *very* recently. Now, we want to pull it out of the ground and put in a whole new one. Engineering protocols should involve thinking far down the road. I cannot fault anyone for having selected XML at the outset. I cannot fault anyone for wanting to add JSON support now for something this simple to implement on the server. However, what I call dangerous is declaring that JSON should be the only format for the web, ignoring the significant investment web developers have in XML. The motivation for JSON? Because it works well with JavaScript, in spite of the fact that nobody would want to do an eval on it, so it has to be parsed like any other format? What about the next web language? Would we invent a new format for that, too? This is like throwing out a widely deploy authentication protocol and re-inventing that wheel, too. Oh yeah... that would be what was done with OpenID Connect ;-) Seriously... is there no sense of maintaining backward compatibility and rigidly defining protocols for the long-term? Paul > -----Original Message----- > From: Tim Bray [mailto:tb...@textuality.com] > Sent: Thursday, April 19, 2012 11:41 PM > To: Paul E. Jones > Cc: Mike Jones; Murray S. Kucherawy; oauth@ietf.org; Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > No. Supporting two different on-the-wire data formats is actively harmful. > Here are two pieces which explain why: > > - mnot, this month: > http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide > - Me, back in 2009 > > Pick one. -T > > On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones <pau...@packetizer.com> > wrote: > > Mike, > > > >> There are two criteria that I would consider to be essential > >> requirements for any resulting general-purpose discovery specification: > >> > >> 1. Being able to always discover per-user information with a single > >> GET (minimizing user interface latency for mobile devices, etc.) > > > > WF can do that. See: > > $ curl -v https://packetizer.com/.well-known/\ > > host-meta.json?resource=acct:pau...@packetizer.com > > > >> 2. JSON should be required and it should be the only format required > >> (simplicity and ease of deployment/adoption) > > > > See the above example. However, I also support XML with my server. > > It took me less than 10 minutes to code up both XML and JSON > > representations. Once the requested format is determined, the > > requested URI is determined, data is pulled from the database, spitting > out the desired format is trivial. > > > > Note, and very important note: supporting both XML and JSON would only > > be a server-side requirement. The client is at liberty to use the > > format it prefers. I would agree that forcing a client to support > > both would be unacceptable, but the server? Nothing to it. > > > >> SWD already meets those requirements. If the resulting spec meets > >> those requirements, it doesn't matter a lot whether we call it > >> WebFinger or Simple Web Discovery, but I believe that the > >> requirements discussion is probably the most productive one to be > >> having at this point - not the starting point document. > > > > I believe WebFinger meets those requirements. We could debate whether > > XML should be supported, but I'll note (again) that it is there in RFC > 6415. > > That document isn't all that old and, frankly, it concerns me that we > > would have a strong preference for format A one week and then Format B > the next. > > We are where we are and I can see reason for asking for JSON, but no > > good reason to say we should not allow XML (on the server side). > > > > Paul > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-disc...@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
