Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)

["Paul E. Jones" <[e-mail]>]

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:[e-mail]]
> Sent: Thursday, April 19, 2012 11:41 PM
> To: Paul E. Jones
> Cc: Mike Jones; Murray S. Kucherawy; [e-mail]; 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 <[e-mail]>
> 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:[e-mail]
> >
> >> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/apps-discuss