Oh, don't scare people with that ;-) If we do extend the syntax of WF, we should ensure that both formats are extended in a natural way for each format. Backward compatibility should also be of utmost concern, so changes should never be too drastic.
Paul > -----Original Message----- > From: Goix Laurent Walter [mailto:laurentwalter.g...@telecomitalia.it] > Sent: Friday, April 20, 2012 1:49 AM > To: Tim Bray; Paul E. Jones > Cc: oauth@ietf.org; Apps Discuss > Subject: R: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > 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
