I would be OK with optional XML support in the server, that way existing endpoints will continue to work, but new ones are not required to add something some people feel is cruft.
As one of the XRD authors, I do understand the advantages of it. However I don't want to be sentimental, and force people to carry forward things that won't be used, and may hamper adoption. And Yes I am one of the hard hatred basters that decided to redo openID on OAuth rather than trying to graft OAuth functionality onto openID 2. Keeping what's working working is fine, but not forcing people to carry it forward. John B. On 2012-04-20, at 7:09 PM, Gonzalo Salgueiro wrote: > Derek - > > On Apr 20, 2012, at 10:17 AM, Derek Atkins wrote: > >> Paul, >> >> "Paul E. Jones" <pau...@packetizer.com> writes: >> >>> 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.) >> >> As an individual (and not the chair of OAUTH) I believe that the server >> should be allowed, no encouraged, to support multiple formats for data >> retrieval. I also believe that clients should be allowed to choose only >> one. I am fine with JSON being Mandatory to Implement. I am NOT okay >> with making it the only one, and I am even less okay with mandating it >> is the ONLY one. I would say MUST JSON, MUST (or possibly SHOULD -- you >> can convince me either way) XML, and MAY for anything else that people >> feel stronly about (although I feel in 2012 XML and JSON are the two >> best). I also feel it is okay to say that a client MUST implement one >> of JSON or XML, and MAY implement more. >> >> <OAUTH Chair Hat> >> >> Note that this is a replay of the historical "MUST Implement" versus >> "MUST Use" arguments. Just because the server MUST IMPLEMENT JSON and >> XML does not mean that a Client must use both (or even that a client >> must implement both). It is perfectly reasonable and generally >> acceptable to have a server that provides data in multiple formats >> whereas the client only supports a subset and specifies which format(s) >> are acceptable. >> >> </OAUTH Char Hat> >> > > This is the most sensible path forward. A MUST for JSON and XML (I'm going > with a MUST for XML to maintain backwards compatibility with RFC 6415) on the > server side and a client can choose whatever format it wants. This is the > approach taken in the current WebFinger draft. If we reach consensus that we > must mandate a client format (Note: I don't personally think we need to), > then so be it. > > Cheers, > > Gonzalo > >> -derek >> >> -- >> Derek Atkins 617-623-3745 >> de...@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >> _______________________________________________ >> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
