Michael,
> > 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
>
Daniel,
If the resource parameter is required, what would break are new clients that
rely on it. Thus, we have a forward-compatibility issue. That is an issue,
which is why we made it optional. (But I've said that.)
I think a question is whether we can accept this "new client" issue as an
i
Mike,
> On 04/20/2012 07:17 AM, Derek Atkins wrote:
> > 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).
Derek,
> > 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, pl
On 04/20/2012 03:40 PM, Michael Thomas wrote:
>
> Why not MUST ASN.1 while you're at it? JSON has won in case
> you'all haven't noticed it.
Well, I also remember when XML won over ASN.1, or
was that some RPC thing? Seems like a new format wins
about every five years or so, once the last winner
And the AOL is working as well (though it was down for a bit:)
On 4/19/12 12:15 PM, Christian Weiske wrote:
Hello Dick,
Gmail, aol, and yahoo all put up webfinger endpoints, but there
hasn't been much movement, I think due to the chicken and egg
nature of adoption around decentralized tools.
6415 supporting a XML format doesn't require everything that uses it to support
XML.
John B
Sent from my iPhone
On 2012-04-20, at 7:34 PM, Gonzalo Salgueiro wrote:
> 6415
smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing l
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
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
Derek -
On Apr 20, 2012, at 10:17 AM, Derek Atkins wrote:
> Paul,
>
> "Paul E. Jones" 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 implemen
On 04/20/2012 08:31 AM, Julian Reschke wrote:
On 2012-04-20 17:12, Michael Thomas wrote:
...
To Paul's point about how easy it is for a server to support both, I'd
retort that it's equally easy for a client to gin up JSON instead of XML.
Pity the poor programmer who can't get their head around t
On 2012-04-20 17:12, Michael Thomas wrote:
...
To Paul's point about how easy it is for a server to support both, I'd
retort that it's equally easy for a client to gin up JSON instead of XML.
Pity the poor programmer who can't get their head around that gigantic
change. On the other hand, having
We are not arguing that XML be removed from the server. Only that JSON be
mandatory for the server to support.
Others on the list piled on the removing XML argument.
I do think there is a legitimate argument that fewer options make for better
interoperability.
However Mike and myself are n
On 04/20/2012 07:17 AM, Derek Atkins wrote:
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 reasona
There's a disconnect here. Mnot and I (at least) have argued that
there are very specific problems and costs associated with going
multi-format. I’ve heard lots of people say "Well, I support
multi-format” but I haven’t heard any specific responses explaining
why those costs and problems aren’t re
So you are guaranteeing that there are no clients using WF today?
>
> From: Mike Jones
>To: Paul E. Jones ; 'Murray S. Kucherawy'
>; "oauth@ietf.org" ; 'Apps Discuss'
>
>Sent: Thursday, April 19, 2012 10:48 PM
>Subject: Re: [OAUTH-WG] [apps-discuss] Web Fin
On 20 April 2012 16:40, Michael Thomas wrote:
> On 04/20/2012 07:17 AM, Derek Atkins wrote:
>
>> Paul,
>>
>> "Paul E. Jones" 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 sai
On 04/20/2012 07:17 AM, Derek Atkins wrote:
Paul,
"Paul E. Jones" 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
Paul,
"Paul E. Jones" 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
Mike -
I can get behind this approach.
(Note: We already mandated JSON in the current WebFinger spec)
Cheers,
Gonzalo
On Apr 20, 2012, at 1:48 AM, Mike Jones wrote:
> To be clear, making this mandatory would break no clients. It would require
> updating some servers, just as requiring JSON
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-
> bo
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
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 wrote:
> Mike,
>
>> T
You're right, resource owner credentials is specifically for username and
password. If by RSA you mean a one time password from a hard token, you
might be able to kind of shove it into a resource owner credentials flow.
But I don't think that was really the intent. If you mean RSA signatures,
then
24 matches
Mail list logo
