W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

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

From: Eran Hammer-Lahav <eran@hueniverse.com>
Date: Mon, 3 Aug 2009 14:22:28 -0700
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783562D0F@P3PW5EX1MB01.EX1.SECURESERVER.NET>
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:23:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:08 GMT