Subject: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18

From: Mike Jones <[email-masked]>
Date: Fri, 11 Mar 2011 23:04:05 +0000

As you know, the OAuth 2.0 Bearer Token draft -03 established the OAuth Errors Registry<http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.html#errors-registry> to increase interoperability among implementations using the related OAuth specifications.  As you also know, there has been some discussion about whether:

A)  The OAuth Errors Registry belongs in in the Framework specification rather than the bearer token specification,
B)  The OAuth Errors Registry should continue to be defined in the Bearer Token specification and apply to all OAuth specifications,
C)  The OAuth Errors Registry should reside in the Bearer Token specification but be scoped back to only apply to that specification, or
D)  The OAuth Errors Registry should be deleted because the set of errors should not be extensible.

Please vote for A, B, C, or D by Friday, March 18th.

I personally believe that A makes the most sense, but given that other points of view have also been voiced, this consensus call is needed to resolve the issue.

                                                                Cheers,
                                                                -- Mike

---

From: Phil Hunt <[email-masked]>
Date: Fri, 11 Mar 2011 15:35:01 -0800

Should option C read: No OAuth Errors Registry, but each specification may specify its own set of errors. Or is this another option and C is different?

Phil
[email-masked]

On 2011-03-11, at 3:04 PM, Mike Jones wrote:

> As you know, the OAuth 2.0 Bearer Token draft -03 established the OAuth Errors Registry to increase interoperability among implementations using the related OAuth specifications.  As you also know, there has been some discussion about whether:
>  
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Fri, 11 Mar 2011 23:41:46 +0000

That would be yet a different option.  With (C), the initial set of errors registered by the bearer token spec {invalid_request, invalid_token, insufficient_scope} could be extended by registering new errors.  With your alternative wording, this set would not be extensible.

                                                                -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Friday, March 11, 2011 3:35 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18

Phil
[email-masked]<mailto:[email-masked]>

                                                                Cheers,
                                                                -- Mike

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phillip Hunt <[email-masked]>
Date: Fri, 11 Mar 2011 16:31:41 -0800

Extensibility for the new option would be defined within each spec.

It doesn't seem right to put registry in bearer spec. What if one is defining a non-bearer spec?

Phil

Sent from my phone.

---

From: Mike Jones <[email-masked]>
Date: Sat, 12 Mar 2011 00:58:42 +0000

The value of having a common OAuth Errors Registry, as provided by both (A) and (B), is that when “one is defining a non-bearer spec”, the errors will be consistent with those used in the bearer spec (and other OAuth specs), which can only help interoperability.

Your statement “It doesn't seem right to put registry in bearer spec” is the argument for (A) rather than (B).

                                                                -- Mike

From: Phillip Hunt [mailto:[email-masked]]
Sent: Friday, March 11, 2011 4:32 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18

Phil

Sent from my phone.

On 2011-03-11, at 15:41, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
That would be yet a different option.  With (C), the initial set of errors registered by the bearer token spec {invalid_request, invalid_token, insufficient_scope} could be extended by registering new errors.  With your alternative wording, this set would not be extensible.

                                                                -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Friday, March 11, 2011 3:35 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18

Phil

                                                                Cheers,
                                                                -- Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 11 Mar 2011 18:06:13 -0700

D (not objection to C).

So far, not a single use case or technical rational has been presented to justify option A.

Option B is not a valid option per IETF process (for option B to be valid, the protocol spec must first be published as an RFC, and they the bearer token spec updates it).

This entire proposal received practically no support or interest and calling for a vote on it is a bit overreaching.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, March 11, 2011 3:04 PM
To: [email-masked]
Subject: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18

                                                                Cheers,
                                                                -- Mike

---

From: Lucy Lynch <[email-masked]>
Date: Fri, 11 Mar 2011 17:41:03 -0800 (PST)

On Fri, 11 Mar 2011, Mike Jones wrote:

> As you know, the OAuth 2.0 Bearer Token draft -03 established the OAuth 
> Errors 
> Registry<http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.html#errors-registry> 
> to increase interoperability among implementations using the related 
> OAuth specifications.  As you also know, there has been some discussion 
> about whether:
>
> A)  The OAuth Errors Registry belongs in in the Framework specification 
> rather than the bearer token specification,
> B)  The OAuth Errors Registry should continue to be defined in the 
> Bearer Token specification and apply to all OAuth specifications,
> C)  The OAuth Errors Registry should reside in the Bearer Token 
> specification but be scoped back to only apply to that specification, or

Why the early cut-off date? As this is in advance of IETF 80, changes will
wait until after Prague in any case.

> I personally believe that A makes the most sense, but given that other 
> points of view have also been voiced, this consensus call is needed to 
> resolve the issue.

Consensus isn't achieved by voting so all you'll get is poll data but that 
may be useful here. While I agree that there has been some discussion, I 
don't think the relative merits of the models have been made clear to the 
group. A fuller discussion of the need for an extensible registry for 
errors (before decided where to home the text) might be more helpful.

- Lucy

---

From: Anthony Nadalin <[email-masked]>
Date: Sat, 12 Mar 2011 01:46:23 +0000

> Why the early cut-off date? As this is in advance of IETF 80, changes will wait until after Prague in any case.
To inform the discussions @ IETF 80 to determine what else might be needed, which goes to your second comment

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lucy Lynch
Sent: Friday, March 11, 2011 5:41 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18

On Fri, 11 Mar 2011, Mike Jones wrote:

> As you know, the OAuth 2.0 Bearer Token draft -03 established the 
> OAuth Errors 
> Registry<http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.ht
> ml#errors-registry> to increase interoperability among implementations 
> using the related OAuth specifications.  As you also know, there has 
> been some discussion about whether:
>
> A)  The OAuth Errors Registry belongs in in the Framework 
> specification rather than the bearer token specification,

Why the early cut-off date? As this is in advance of IETF 80, changes will wait until after Prague in any case.

> points of view have also been voiced, this consensus call is needed to 

Consensus isn't achieved by voting so all you'll get is poll data but that may be useful here. While I agree that there has been some discussion, I don't think the relative merits of the models have been made clear to the group. A fuller discussion of the need for an extensible registry for errors (before decided where to home the text) might be more helpful.

- Lucy

---

From: Lucy Lynch <[email-masked]>
Date: Fri, 11 Mar 2011 17:55:25 -0800 (PST)

On Sat, 12 Mar 2011, Anthony Nadalin wrote:

>> Why the early cut-off date? As this is in advance of IETF 80, changes 
>> will wait until after Prague in any case.

> To inform the discussions @ IETF 80 to determine what else might be 
> needed, which goes to your second comment

ack - thanks!

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 11 Mar 2011 21:03:10 -0500

I vote (A) because 1) I strongly believe in modularity and 2) I disagree 
with D.  Hence what applies to all specifications must be defined at the 
highest level, rather than in a self-contained specification. So, this 
looked like a simple matter to me.

Having said that, I note that Lucy has a different opinion, and this  
may very well mean that I simply don't understand the issue fully.   If 
convinced otherwise, I will change my "vote."

I would like to have this discussion in Prague, indeed, if Hannes can 
put it on the agenda. (As a former WG chair, I know how hard it is to 
get everything that came up as an issue discussed in a short time of one 
meeting.) Alternatively, if there is a strong argument against A, I 
would like to see it now. Maybe everything can be resolved on the list.

Igor

Mike Jones wrote:
> OAuth Errors Registry 
> <http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.html#errors-registry> 
> OAuth specifications.  As you also know, there has been some 
> discussion about whether:
>
>  
>
> Please vote for A, B, C, or D by Friday, March 18^th .
>
>  
>
> ------------------------------------------------------------------------
>

---

From: Phillip Hunt <[email-masked]>
Date: Fri, 11 Mar 2011 22:18:55 -0800

I have not seen any detailed agenda for IETF 80. If there will be votes that override email votes all participant should so be informed. 

Phil

Sent from my phone.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 12 Mar 2011 01:15:45 -0700

Decisions are never made outside the list.

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Phillip Hunt
> Sent: Friday, March 11, 2011 10:19 PM
> To: Anthony Nadalin
> Cc: [email-masked]
> I have not seen any detailed agenda for IETF 80. If there will be votes that
> override email votes all participant should so be informed.
> 
> Phil
> 
> Sent from my phone.
> 
> >> Registry<http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.h
> >> t ml#errors-registry> to increase interoperability among
> >> implementations using the related OAuth specifications.  As you also
> >> know, there has been some discussion about whether:
> >>
> >> I personally believe that A makes the most sense, but given that
> >> other points of view have also been voiced, this consensus call is
> >> needed to resolve the issue.
> >
> > Consensus isn't achieved by voting so all you'll get is poll data but that may
> be useful here. While I agree that there has been some discussion, I don't
> think the relative merits of the models have been made clear to the group. A
> fuller discussion of the need for an extensible registry for errors (before
> decided where to home the text) might be more helpful.
> >
> > - Lucy
> >
> >
> >>                                                               Cheers,
> >>                                                               -- Mike
> >>
> >>
> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Mar 2011 09:10:44 +0200

Hi Mike, 
Hi all, 

As some of you had notice we do not vote. 
Soliciting the feedback from the working group on this issue is, however, a good idea. 

Ciao
Hannes

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 14 Mar 2011 08:44:27 -0400

A -- but potentially do a short-form registry with a full-url nonregistered means of extending error codes, like with grant types.

 -- justin
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Mike Jones [[email-masked]]
Sent: Friday, March 11, 2011 6:04 PM
To: [email-masked]
Subject: [OAUTH-WG] Vote:  Location of OAuth Errors Registry, deadline Friday,  March 18

                                                                Cheers,
                                                                -- Mike

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 14 Mar 2011 15:47:13 +0000

My preference would be option A

                                                                Cheers,
                                                                -- Mike

---

From: David Recordon <[email-masked]>
Date: Mon, 14 Mar 2011 23:15:28 +0000

I still haven't seen an explanation of what this registry accomplishes
or why it's become needed in the past few weeks.

--David

On Fri, Mar 11, 2011 at 11:04 PM, Mike Jones
<[email-masked]> wrote:
> Errors Registry to increase interoperability among implementations using the
> related OAuth specifications.  As you also know, there has been some
> B)  The OAuth Errors Registry should continue to be defined in the Bearer
> Token specification and apply to all OAuth specifications,
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 14 Mar 2011 23:28:31 +0000

This is not new.  This is meeting the need expressed in draft 10, Section 3.2.1 and draft 11, Section 4.3.1 as "[[ Add mechanism for extending error codes ]]".

It's there to provide a coordination mechanism among OAuth-related specifications so that different specs use the same errors for the same thing.

				-- Mike

-----Original Message-----
From: David Recordon [mailto:[email-masked]] 
Sent: Monday, March 14, 2011 4:15 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18

I still haven't seen an explanation of what this registry accomplishes or why it's become needed in the past few weeks.

--David

On Fri, Mar 11, 2011 at 11:04 PM, Mike Jones <[email-masked]> wrote:
> OAuth Errors Registry to increase interoperability among 
>                                                                 -- 
> Mike

---

From: David Recordon <[email-masked]>
Date: Tue, 15 Mar 2011 01:03:37 +0000

Has anyone extended error codes? Is there a list of error codes
currently being used in the wild that need standardizing?

--David

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 14 Mar 2011 18:29:53 -0700

It's a clear example of defining facilities without *ANY* use cases or requirements.

We have clear use cases and actual registration requests for the current registries defined in v2.

What's most annoying about this entire push for an error registry is that the author and supporters have all failed to show a single example of an actual value to be registered. I don't think I'm asking for much.

Registries must be held to the same level of adoption as any other part of the protocol. If a feature is not being use by the time the document is finalized, it MUST NOT be included and left out. Otherwise, this is pure astronaut architecture and design by committee.

As for the reference to the editorial comment in draft 11 - there were other such notes in part drafts which were simply removed without addressing throughout the process. This registry is new, and is baseless. An important part of our process is weeding out what is not necessary, and an error registry clearly fails to meet this standard.

This entire thread should be stopped until someone can offer clear use cases and requirements. Otherwise, this is a joke.

EHL

> Of David Recordon
> Sent: Monday, March 14, 2011 6:04 PM
> To: Mike Jones
> Cc: [email-masked]
> Has anyone extended error codes? Is there a list of error codes currently
> being used in the wild that need standardizing?
> 
> --David
> 
> 
> > This is not new.  This is meeting the need expressed in draft 10, Section
> 3.2.1 and draft 11, Section 4.3.1 as "[[ Add mechanism for extending error
> codes ]]".
> >
> > It's there to provide a coordination mechanism among OAuth-related
> specifications so that different specs use the same errors for the same thing.
> >
> >                                -- Mike
> >
> > I still haven't seen an explanation of what this registry accomplishes or why
> it's become needed in the past few weeks.
> >
> > --David
> >
> >

---

From: "William J. Mills" <[email-masked]>
Date: Mon, 14 Mar 2011 18:51:08 -0700 (PDT)

My vote is D, or C -- if you really have a use case for extensible errors in Bearer.

As for consistency, the WG should attempt to keep error codes sensible and consistently applied.

________________________________
From: Mike Jones <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Friday, March 11, 2011 3:04 PM
Subject: [OAUTH-WG] Vote:  Location of OAuth Errors Registry, deadline Friday, March 18

 

                                                                Cheers,
                                                                -- Mike

---

From: Phil Hunt <[email-masked]>
Date: Mon, 14 Mar 2011 22:12:29 -0700

As I indicated earlier, I don't agree yet with the choices and would like more information on the registry and use cases.

Phil
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 14 Mar 2011 22:15:27 -0700

Me too! :-)

EHL

> Of Phil Hunt
> Sent: Monday, March 14, 2011 10:12 PM
> Cc: [email-masked] WG
> As I indicated earlier, I don't agree yet with the choices and would like more
> information on the registry and use cases.
> 
> Phil
> [email-masked]
> 
> 
> 
> 
> > What's most annoying about this entire push for an error registry is that the
> author and supporters have all failed to show a single example of an actual
> value to be registered. I don't think I'm asking for much.
> >
> > Registries must be held to the same level of adoption as any other part of
> the protocol. If a feature is not being use by the time the document is
> finalized, it MUST NOT be included and left out. Otherwise, this is pure
> astronaut architecture and design by committee.
> >
> > As for the reference to the editorial comment in draft 11 - there were
> other such notes in part drafts which were simply removed without
> addressing throughout the process. This registry is new, and is baseless. An
> important part of our process is weeding out what is not necessary, and an
> error registry clearly fails to meet this standard.
> >
> > This entire thread should be stopped until someone can offer clear use
> cases and requirements. Otherwise, this is a joke.
> >
> > EHL
> >
> >
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of David Recordon
> >> 3.2.1 and draft 11, Section 4.3.1 as "[[ Add mechanism for extending
> >> error codes ]]".
> >>>
> >>>> implementations using the related OAuth specifications.  As you
> >>>> also know, there has been some discussion about whether:
> >>>>
> >>>>
> >>>>

---

From: Mike Jones <[email-masked]>
Date: Tue, 15 Mar 2011 20:16:57 +0000

Per the previous discussions, the use case is enabling OAuth specifications to be able to extend the set of interoperable error codes.  Use of an IANA registry for this purpose is standard IETF practice.  (To see *lots* of other examples of this in practice, go to http://www.iana.org/protocols/ and search for "error".)

One non-hypothetical motivating example is extending the set of errors in 4.2.2.1 to add an "insufficient_scope" error to indicate that the request is valid but requires higher privileges than currently held by the caller.  This is different than "invalid_scope".

Another possible error code that is meaningful and actionable in some contexts is "please_retry", indicating that this same request may succeed later if retried.  Services may return this when out of resources or during initialization.

Given that we all intend OAuth to be a building block for a family of related protocols and for new services, it would be presumptive of us to assert that we've identified of all the actionable error conditions up front.  This is exactly parallel to the argument for the OAuth Parameters registry, which does exist.

The IETF has a straightforward mechanism and for extending parameter spaces in an orderly way.   I believe that we'll best serve those building new protocols and services on top of OAuth by using it!

				Cheers,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Monday, March 14, 2011 6:30 PM
To: David Recordon
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 15 Mar 2011 14:13:52 -0700

Thank you.

> Of Mike Jones
> Sent: Tuesday, March 15, 2011 1:17 PM

> Per the previous discussions, the use case is enabling OAuth specifications to
> be able to extend the set of interoperable error codes.  Use of an IANA
> registry for this purpose is standard IETF practice.  (To see *lots* of other
> examples of this in practice, go to http://www.iana.org/protocols/ and
> search for "error".)

A registry is *one* possible solution for extensibility. Once the requirements are established we can pick the most appropriate solution.
 
> One non-hypothetical motivating example is extending the set of errors in
> 4.2.2.1 to add an "insufficient_scope" error to indicate that the request is
> valid but requires higher privileges than currently held by the caller.  This is
> different than "invalid_scope".

Insufficient scope is only applicable when making protected resource requests. Since v2 doesn't address how to make authenticated requests and does not define error codes for that case, such an error code is irrelevant. The MAC scheme does not use error codes at all as existing HTTP status codes fully cover every error case. I would be surprised if the bearer token scheme cannot do the same.

> Another possible error code that is meaningful and actionable in some
> contexts is "please_retry", indicating that this same request may succeed
> later if retried.  Services may return this when out of resources or during
> initialization.

HTTP 503 Service Unavailable covers this and is the appropriate method to return such information.

> Given that we all intend OAuth to be a building block for a family of related
> protocols and for new services, it would be presumptive of us to assert that
> we've identified of all the actionable error conditions up front.  This is exactly
> parallel to the argument for the OAuth Parameters registry, which does exist.

We have reviewed the document for over a year and came up with a comprehensive error response list for the endpoint defined within the specification.

However, here is an example use case...

Other specifications extending v2 can define additional error codes if necessary. For example, the UX extension adds a 'display' parameter to the authorization endpoint which can result in an 'unknown_display' error. However, such an error is only valuable if the client has a way to correct the request and try again, which is something the UX extension will need to address if defining such an error code. It would be helpful to hear from the UX authors how to intend to address errors related to their new parameters.

> The IETF has a straightforward mechanism and for extending parameter
> spaces in an orderly way.   I believe that we'll best serve those building new
> protocols and services on top of OAuth by using it!

As for the registry solution, a registry is not the only route for addressing such a case. Extensions can use error URIs (which is something *we* have opted to do for extension grant types, instead of using a registry). Additionally, such extensions can simply 'update the v2 RFC' to include an additional error code.

A registry does not help or improve interoperability if the client is not aware of the extension and is constantly updated with new registry values (or whatever the extension policy requires). Using error URI codes is much simpler, consistent with the specification, and something I would be supportive of adding via a simple sentence to -13 saying that additional error codes may be defined and must be absolute URIs.

I am still not convinced we need to address error code extensibility, but given my use case example above, I would be open for allowing URI error codes. Any reason why using URI as error code isn't sufficient (please present new use cases for such requirements)?

EHL

> Of Eran Hammer-Lahav
> Registries must be held to the same level of adoption as any other part of the
> protocol. If a feature is not being use by the time the document is finalized, it
> MUST NOT be included and left out. Otherwise, this is pure astronaut
> architecture and design by committee.
> 
> As for the reference to the editorial comment in draft 11 - there were other
> such notes in part drafts which were simply removed without addressing
> throughout the process. This registry is new, and is baseless. An important
> part of our process is weeding out what is not necessary, and an error
> registry clearly fails to meet this standard.
> 
> This entire thread should be stopped until someone can offer clear use cases
> and requirements. Otherwise, this is a joke.
> 
> EHL
> 
> 
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 15 Mar 2011 17:37:44 -0400

Other use cases include the encoding extensions (such as the XML one,
and if anyone gets around to it, the form-encoded one) and a "format not
supported" error. Having a standard set of oauth errors on the protected

> I am still not convinced we need to address error code extensibility, but given my use case example above, I would be open for allowing URI error codes. Any reason why using URI as error code isn't…

Like I said in a previous email, I'm happy with it being a uri-based
extension, like grant_type. I still think there's value in structuring
what the short codes are, and I think we need *some* kind of
extensibility and a way to make sure that errors don't come from
different spaces with the same code and mean different things. I don't
particularly care what the exact extension mechanism for this is so long
as there's an accepted way to get new stuff in there without stomping on
other things.

I disagree that the errors are all about the client being able to
automatically do something about them -- they're just as useful to push
up the stack to developers. Regardless, if it's an accepted practice
that other RFCs can simply "update the Oauth2 RFC" document without the
use of a registry, and that we can permit some kind of namespacing for
non-registered names (ie, use URIs), then we're probably covering our
bases.

 -- Justin

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 15 Mar 2011 14:47:48 -0700

> From: Justin Richer [mailto:[email-masked]]
> Sent: Tuesday, March 15, 2011 2:38 PM

> Having a standard set of oauth errors on the protected

Not practical. Given the wide range of token types and schemes, each will have to define its own way of handling errors. For example, MAC uses HTTP codes because the error codes were a direct map and defining extra values was simply wasteful. Bearer takes a different approach. No value in forcing a unified scheme approach here.
 
> Like I said in a previous email, I'm happy with it being a uri-based extension,
> like grant_type.

Great.

> I still think there's value in structuring what the short codes are

It's just a pre-defined, non-extensible set. Anything else is a URI, just like grant type. Exactly the same.

> I disagree that the errors are all about the client being able to automatically
> do something about them -- they're just as useful to push up the stack to
> developers.

For that we have two human readable error fields.

EHL