I also would be in favor of keeping both, for the reasons mentioned. Plus xml is traditionally better than json at handling extensions & namespaces that may appear throughout future deployments
walter > -----Messaggio originale----- > Da: apps-discuss-boun...@ietf.org [mailto:apps-discuss- > boun...@ietf.org] Per conto di Tim Bray > Inviato: venerdì 20 aprile 2012 7.33 > A: Paul E. Jones > Cc: oauth@ietf.org; Apps Discuss > Oggetto: 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 you're reacting to are from someone else. But we > agree that the choice of formats isn't 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 > > > _______________________________________________ > apps-discuss mailing list > apps-disc...@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
