rting point - the issues
I've raised have been ignored, and the spec is now much more
complicated from both sides of the implementation fence.
On May 7, 2012 3:17 PM, "Paul E. Jones" <mailto:pau...@packetizer.com>> wrote:
Walter,
I'm not sure what the
Walter,
I'm not sure what the full set of issues will be, but I only have a
couple of small edits queued for -05 at present (one being "template"
should be "href" in the example at the end of 4.2 that you pointed out
to me privately). We've already worked through a number of issues to
get to
Michael,
> From a programming standpoint, JSON is just easier to deal with. Consider
> these two links:
>
> http://php.net/manual/en/book.json.php
>
> http://php.net/manual/en/book.xml.php
>
> and tell me which you'd rather deal with. It's not huge, but it's not
> nothing either.
To be fair,
bet many other
applications will have to deal with a variety of content types, like hcard,
vcard, portable contacts, and others that might use something else.
Paul
Original Message
From: SM
Sent: Sat Apr 21 16:03:53 EDT 2012
To: "Paul E. Jones"
Cc: oauth@ietf.org,
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
>
nt side (or at
least go sifting through replies looking for the proper link relations and
values).
Paul
> -Original Message-
> From: Daniel Renfer [mailto:d...@kronkltd.net]
> Sent: Friday, April 20, 2012 11:09 AM
> To: William Mills
> Cc: Mike Jones; Paul E. Jones; Murray S.
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
Mike,
Deal. :-)
Paul
> -Original Message-
> From: Mike Jones [mailto:michael.jo...@microsoft.com]
> Sent: Friday, April 20, 2012 1:49 AM
> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss'
> Subject: RE: [apps-discuss] [
-
> 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 w
servers to
add JSON would be easy enough to do.
Paul
> -Original Message-
> From: Tim Bray [mailto:tb...@textuality.com]
> Sent: Friday, April 20, 2012 1:33 AM
> To: Paul E. Jones
> Cc: Mike Jones; Murray S. Kucherawy; oauth@ietf.org; Apps Discuss
> Subject: Re: [apps-di
ld do that.
Paul
> -Original Message-
> From: Mike Jones [mailto:michael.jo...@microsoft.com]
> Sent: Friday, April 20, 2012 1:10 AM
> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss'
> Subject: RE: [apps-discuss] [OAUTH-W
g-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
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 tha
Nico,
> On Thu, Jun 9, 2011 at 12:03 AM, Paul E. Jones
> wrote:
> > What issues, specifically. (Messages are all over the place and I
> > don’t know exactly what issues you’re raising. Is it with the
> > approach we’re proposing or something else?)
>
> The fundam
Tim,
> Hi Paul,
>
> > That's the reason for the MAC. Once we can ensure the integrity of
> > the message exchange, then the existing cookie mechanism can provide
> > us with the secure state management capability we need.
>
> Maybe I'm missing something in the MAC authentication draft, but I do
. Jones
Cc: apps-disc...@ietf.org; Nico Williams; OAuth WG; HTTP Working Group; Ben
Adida; Adam Barth; Eran Hammer-Lahav; http-st...@ietf.org
Subject: RE: [http-state] [apps-discuss] HTTP MAC Authentication Scheme
On Jun 8, 2011 2:09 AM, "Paul E. Jones" wrote:
>
> Nico,
>
>
co Williams [mailto:n...@cryptonector.com]
> Sent: Tuesday, June 07, 2011 6:36 PM
> To: Paul E. Jones
> Cc: Eran Hammer-Lahav; apps-disc...@ietf.org; Ben Adida; Adam Barth;
> http-st...@ietf.org; HTTP Working Group; OAuth WG
> Subject: Re: [http-state] [apps-discuss] HTTP MAC Authentication Scheme
>
Nico,
> > Gonzalo and I worked on this:
> > https://tools.ietf.org/html/draft-salgueiro-secure-state-management-04
> >
> > This may not be entirely complete, but the idea was to allow a client
> > and server to establish an association so that requests and responses
> > could be authenticated. Is
Nico,
Sorry for coming into this so late, but I just saw this message.
I don't have all of the background, but when I saw this message header and
some of the dialog, it seems there is a desire to provide some level of
authentication to requests and/or responses between the clients and servers.
G
20 matches
Mail list logo
