Tim, I misunderstood. I thought you authored the MNOT blog post. That stood in quite a contrast to your work on XML. Reading that, I felt like, on a whim, you threw the baby out with the bathwater and started down a new path, giving no regard to what exists.
OK, let me reset me mind dizzy head here... What I do understand is you're suggesting for WF, we should pick one. It there was any complexity to it, I'd agree with you. But, in all seriousness, producing both XML and JSON for WF is a trivial exercise. Why not support both and avoid breaking what exists today? Asking servers to add JSON would be easy enough to do. Paul > -----Original Message----- > From: Tim Bray [mailto:tb...@textuality.com] > Sent: Friday, April 20, 2012 1:33 AM > 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) > > Oops, looks like I left off the link to my own remarks about XML&JSON: > http://goo.gl/v7Pjr - but they say the same thing, more or less, that MNot > did. Your characterizing me as an enemy of XML is amusing, given that my > name appears at the top of this document: http://goo.gl/lBjkl > > The points 1 & 2 youre reacting to are from someone else. But we agree > that the choice of formats isnt crucial. Where we disagree is that we > should pick just one, not multiple ones. -T > > On Thu, Apr 19, 2012 at 9:43 PM, Paul E. Jones <pau...@packetizer.com> > wrote: > > 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
