RE: [OAUTH-WG] [oauth] #4: Error Codes

Sorry. Wrong list. Outlook decided to change the destination.

EHL

> -----Original Message-----
> From: Eran Hammer-Lahav
> Sent: Monday, August 03, 2009 2:22 PM
> To: ietf-http-wg@w3.org Group
> Subject: RE: [OAUTH-WG] [oauth] #4: Error Codes
> 
> We will need to write a new proposal which can be based on the problem
> reporting extension. But it will be part of the core spec(s). I don't
> think we need to have it as an I-D. It is just a good reference (for
> the WG) to existing work in the space.
> 
> EHL
> 
> > -----Original Message-----
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> Behalf
> > Of oauth issue tracker
> > Sent: Monday, August 03, 2009 12:25 AM
> > To: leifj@mnt.se
> > Cc: oauth@ietf.org
> > Subject: Re: [OAUTH-WG] [oauth] #4: Error Codes
> >
> > #4: Error Codes
> > ---------------------------------+-----------------------------------
> --
> > -----
> >  Reporter:  eran@hueniverse.com  |        Owner:
> >      Type:  defect               |       Status:  new
> >  Priority:  critical             |    Milestone:
> > Component:  authentication       |      Version:
> >  Severity:  Active WG Document   |   Resolution:
> >  Keywords:                       |
> > ---------------------------------+-----------------------------------
> --
> > -----
> >
> > Comment(by leifj@mnt.se):
> >
> >  My first question is what would happen to the ProblemReporting
> > proposal -
> >  does it get republished as a standards-track I-D or will it stay an
> >  extension at oauth.net. I guess it would have to be a standards-
> track
> > I-D
> >  if we want to be able to make normative references to it..?
> >
> >  As for the proposal itself I've got some minor comments:
> >
> >  - The text
> >
> >  "Other values of oauth_problem MUST NOT be used. However, a Consumer
> >  SHOULD be prepared to receive other values, from a Service Provider
> > that
> >  implements a future version of problem reporting."
> >
> >  This feels inconsistent to me - isn't it better to apply the
> > robustness
> >  principle and only say that "Consumers MUST be prepared to receive
> > other
> >  values as Service Provders may implement later versions of this
> >  specification, however Consumers MUST silently ignore parameters
> they
> > do
> >  not understand."
> >
> >  In that spirit the oauth_parameters_rejected parameter might need to
> >  become oauth_parameters_ignored.
> >
> >  - A range of values in oauth_acceptable_versions feels like a bad
> idea
> > -
> >  who knows what type of strings will be thought appropriate for oauth
> >  versions in the future and comparison may not me meaningful. Just
> use
> > a
> >  comma-separated list - we really shouldn't be defining that many
> > version
> >  to make this a problem :-)
> >
> >  - oauth_acceptable_timestamps: How could a sender (the use of
> >  sender/receiver gets confusing in the text btw) ever make use of
> that
> >  value? Is it to adjust the clock or just pick a timestamp in the
> > range? I
> >  may just have misunderstood things...
> >
> > --
> > Ticket URL:
> > <https://trac.tools.ietf.org/wg/oauth/trac/ticket/4#comment:1>
> > oauth <http://tools.ietf.org/oauth/>
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth

Received on Monday, 3 August 2009 21:24:19 UTC