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

[Gonzalo Salgueiro <[e-mail]>]

John - 

I understand your position, I truly do.  I'd even go so far as saying that a part of me agree with you given the ubiquitousness of JSON. Two concerns/questions come to mind:

- If it is a MUST in 6415, then isn't it simply good protocol design to maintain that same level of requirement in the discovery protocol based entirely on it? If the answer is "no", then we can figure something out but I'm sharing that this was our primary motivation for requiring it in WebFinger.

- Is it alarming to anyone how quickly we go through "flavor of the day" formats? 6415 was published 6 months ago and we are already ready to declare the mandatory format there a dinosaur that is now obsolete and unnecessary?

Cheers,

Gonzalo

On Apr 20, 2012, at 1:23 PM, John Bradley wrote:

> 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" <[e-mail]> 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
>>>     [e-mail]             www.ihtfp.com
>>>     Computer and Internet Security Consultant
>>> _______________________________________________
>>> apps-discuss mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>