Subject: Re: [OAUTH-WG] Error Registry: Conclusion

From: Mike Jones <[email-masked]>
Date: Thu, 14 Jun 2012 21:40:02 +0000

Hi Hannes,

You stated a preference for separate registries below, but that was a larger change to the OAuth Core spec than the current draft, which added a fourth error usage location "resource access error response" to the registry.  To my knowledge, the consensus call didn't ask people to express a preference between having four separate OAuth Errors registries versus one OAuth Errors registry allowing any combination of a set of four usage locations to be specified.

Given that the two choices are completely equivalent, and we had previously established the single OAuth Errors registry with three possible usage locations, extending it to a fourth seemed to be both more natural and easier for people to understand.

Therefore, I'd like to ask you to withdraw your suggestion and allow the existing structure of the OAuth Errors registry to remain.

				Thank you,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Tuesday, May 15, 2012 2:27 PM
To: [email-masked] WG
Subject: [OAUTH-WG] Error Registry: Conclusion

Hi all, 

on May 8th we called for consensus on an open issue regarding the location of the error registry. Here is the call for comments: http://www.ietf.org/mail-archive/web/oauth/current/msg08952.html. 

Thank you all for the feedback. The consensus is to create the registry in the core document.

Section 11.4.1 already sort-of creates sub-registries to illustrate where the different errors can be used. This is needed since some of the errors may only appear in certain error responses. Hence, we need add another one to this list (suggestion: 'resource access error response'). In fact, I would prefer IANA to create separate tables for each of these sub-registries to avoid confusion for the reader (instead of putting everything into a single table). 

We believe that these changes are really minor and address IESG feedback.

Ciao
Hannes & Derek

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

---

From: William Mills <[email-masked]>
Date: Thu, 14 Jun 2012 14:48:07 -0700 (PDT)

We might be able to combine these, but to me it really does make sense to have one registry for OAuth 2 core extensions to the frameowrk and one for the auth profiles.  The downside of this would be duplication between the two.  If we think there will be significant overlap then I think they should be merged, if they are mostly distinct then I would somewhat prefer separate registries but I can live with either.

My tuppence.

-bill

----- Original Message -----
> From: Mike Jones <[email-masked]>
> To: Hannes Tschofenig <[email-masked]>
> Cc: "[email-masked] WG" <[email-masked]>
> Sent: Thursday, June 14, 2012 2:40 PM
> Subject: Re: [OAUTH-WG] Error Registry: Conclusion
> 
> Hi Hannes,
> 
> You stated a preference for separate registries below, but that was a larger 
> change to the OAuth Core spec than the current draft, which added a fourth error 
> usage location "resource access error response" to the registry.  To 
> my knowledge, the consensus call didn't ask people to express a preference 
> between having four separate OAuth Errors registries versus one OAuth Errors 
> registry allowing any combination of a set of four usage locations to be 
> specified.
> 
> Given that the two choices are completely equivalent, and we had previously 
> established the single OAuth Errors registry with three possible usage 
> locations, extending it to a fourth seemed to be both more natural and easier 
> for people to understand.
> 
> Therefore, I'd like to ask you to withdraw your suggestion and allow the 
> existing structure of the OAuth Errors registry to remain.
> 
>                 Thank you,
>                 -- Mike
> 
> on May 8th we called for consensus on an open issue regarding the location of 
> the error registry. Here is the call for comments: 
> http://www.ietf.org/mail-archive/web/oauth/current/msg08952.html. 
> 
> Section 11.4.1 already sort-of creates sub-registries to illustrate where the 
> different errors can be used. This is needed since some of the errors may only 
> appear in certain error responses. Hence, we need add another one to this list 
> (suggestion: 'resource access error response'). In fact, I would prefer 
> IANA to create separate tables for each of these sub-registries to avoid 
> confusion for the reader (instead of putting everything into a single table). 
>

---

From: Eran Hammer <[email-masked]>
Date: Thu, 14 Jun 2012 21:52:56 +0000

We already have multiple registries. This one is about error codes only. I don't think the overlap is clear at this point between errors on the core endpoints vs error on the bearer and future auth schemes opting into this registry. So it is hard to tell which format would be better. The main question if we split the error registry into multiple tables is how registrations are done because currently, the template is used as-is to insert a single record into the IANA table.

EH

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of William Mills
> Sent: Thursday, June 14, 2012 2:48 PM
> To: Mike Jones; Hannes Tschofenig
> Cc: [email-masked] WG
> We might be able to combine these, but to me it really does make sense to
> have one registry for OAuth 2 core extensions to the frameowrk and one for
> the auth profiles.  The downside of this would be duplication between the
> two.  If we think there will be significant overlap then I think they should be
> merged, if they are mostly distinct then I would somewhat prefer separate
> registries but I can live with either.
> 
> My tuppence.
> 
> -bill
> 
> 
> 
> > You stated a preference for separate registries below, but that was a
> > larger change to the OAuth Core spec than the current draft, which
> > added a fourth error usage location "resource access error response"
> > to the registry.  To my knowledge, the consensus call didn't ask
> > people to express a preference between having four separate OAuth
> > Errors registries versus one OAuth Errors registry allowing any
> > combination of a set of four usage locations to be specified.
> >
> > Given that the two choices are completely equivalent, and we had
> > previously established the single OAuth Errors registry with three
> > possible usage locations, extending it to a fourth seemed to be both
> > more natural and easier for people to understand.
> >
> > Therefore, I'd like to ask you to withdraw your suggestion and allow
> > the existing structure of the OAuth Errors registry to remain.
> >
> >                 Thank you,
> >                 -- Mike
> >
> > on May 8th we called for consensus on an open issue regarding the
> > location of the error registry. Here is the call for comments:
> > Section 11.4.1 already sort-of creates sub-registries to illustrate
> > where the different errors can be used. This is needed since some of
> > the errors may only appear in certain error responses. Hence, we need
> > add another one to this list
> > (suggestion: 'resource access error response'). In fact, I would
> > prefer IANA to create separate tables for each of these sub-registries
> > to avoid confusion for the reader (instead of putting everything into a
> single table).
> >

---

From: Mike Jones <[email-masked]>
Date: Thu, 14 Jun 2012 21:59:57 +0000

Yes, we already have multiple registries, but only one for errors.  When an error code can be used in more than one usage location, having one will make the registrations simpler and it may be somewhat more apparent how the error code is used.

The two structures are equivalent, but it seems to me that having one is more convenient and simpler than having four.

-- Mike

________________________________
From: Eran Hammer
Sent: 6/14/2012 2:53 PM
To: William Mills; Mike Jones; Hannes Tschofenig
Cc: [email-masked] WG
Subject: RE: [OAUTH-WG] Error Registry: Conclusion

EH

> > Of Hannes Tschofenig

---

From: Eran Hammer <[email-masked]>
Date: Thu, 14 Jun 2012 22:02:28 +0000

It seems to me that a single table is a better way to accomplish the goals set by the working group. The entire reason for adding the new location was based on the assumption that there will be overlap.

EH

From: Mike Jones [mailto:[email-masked]]
Sent: Thursday, June 14, 2012 3:00 PM
To: Eran Hammer; William Mills; Hannes Tschofenig
Cc: [email-masked] WG
Subject: RE: [OAUTH-WG] Error Registry: Conclusion

-- Mike
Cc: [email-masked]<mailto:[email-masked]> WG

EH

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
> Of William Mills
> Cc: [email-masked]<mailto:[email-masked]> WG
> > From: Mike Jones <[email-masked]<mailto:[email-masked]>>
> > To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
> > Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
> > Of Hannes Tschofenig
> > To: [email-masked]<mailto:[email-masked]> WG
> > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Jun 2012 21:26:48 +0300

Hi Mike, 

thanks for raising this issue. 

I am fine with the currently proposed approach. I just had a personal preference for separate tables for readability purposes -- not a big issue. 

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Jun 2012 18:51:33 +0000

Thanks, Hannes.  I believe that leaves the particulars of the ABNF and possible encoding of client_id values containing colon for use with HTTP Basic as the only open issues for Core.

				-- Mike

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, June 15, 2012 11:27 AM
To: Mike Jones
Cc: Hannes Tschofenig; [email-masked] WG
Subject: Re: [OAUTH-WG] Error Registry: Conclusion

Hi Mike, 

Ciao
Hannes