Subject: Re: [OAUTH-WG] Closing a few issues

From: Alexey Melnikov <[email-masked]>
Date: Tue, 03 May 2011 12:16:50 +0100

Hi Barry,

Barry Leiba wrote:

>There are three issues in the tracker that are just looking for
>consensus on text that's in the document -- Eran had flagged them as
>"pending consensus" in the -15 version.  Let's look at closing those
>issues now.  The issues are
>
>#8	4.1.2.1 and 4.2.2.1, text for 4xx or 5xx HTTP status code
>http://trac.tools.ietf.org/wg/oauth/trac/ticket/8
>
>#9	5.2, text for non-400 & 401 error conditions
>http://trac.tools.ietf.org/wg/oauth/trac/ticket/9
>  
>
These look fine to me.

>#10	8.4. Defining Additional Error Codes
>http://trac.tools.ietf.org/wg/oauth/trac/ticket/10
>  
>
This is mostly fine, but I am wondering if the ACAP vendor name registry (RFC 6075), the OID vendor names, or DNS names can be recommended for the prefix (to satisfy the "SHOULD be prefixed by an identifying name when possible" requirement)?

Best Regards,
Alexey

-- 
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address
twitter: aamelnikov

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 3 May 2011 18:44:34 +0000

I propose that we close issue #12 (Restore WWW-Authenticate response to the framework specification) with no action, that is each extension would handle as they are doing now.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Friday, April 29, 2011 11:05 AM
To: OAuth WG
Subject: [OAUTH-WG] Closing a few issues

There are three issues in the tracker that are just looking for consensus on text that's in the document -- Eran had flagged them as "pending consensus" in the -15 version.  Let's look at closing those issues now.  The issues are

I think these are non-controversial.  I'm aware of some conversation about perhaps tweaking the text to make sure it's clear what layer the status codes go into (for the redirects, it should be clear, but a slight text change might help).

Everyone, please review these.  They are short, and should be easy to confirm consensus on.  Please post any objection you have to closing these issues.  If you do have an objection, it would help if you could post alternative text that you'd be happy with.  Please post also if you think they're OK and ready to close.

I will close these issues next Friday, 6 May, if there are no unresolved objections.

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

---

From: Barry Leiba <[email-masked]>
Date: Fri, 6 May 2011 10:22:37 -0400

> http://trac.tools.ietf.org/wg/oauth/trac/ticket/9

I will close these later today, as I said in my original note:
http://www.ietf.org/mail-archive/web/oauth/current/msg06211.html
There have been no objections, nor other comments.

> http://trac.tools.ietf.org/wg/oauth/trac/ticket/10

I will leave this open for the moment, and consider closing after
there's some response to Alexey's comment:
http://www.ietf.org/mail-archive/web/oauth/current/msg06225.html
Eran, do you have any comment on what Alexey suggests (I agree, as a
participant, with the suggestion to use the ACAP vendor registry)?

> #12	Restore WWW-Authenticate response to the framework
>    	specification
> http://trac.tools.ietf.org/wg/oauth/trac/ticket/12

Tony has suggested closing this:
http://www.ietf.org/mail-archive/web/oauth/current/msg06228.html
As he and Mike were the chief supporters of this, with their objection
removed it should be ready to close as well.  I'll leave it open for a
few more days, and close it early next week if there are no objections
by then.

Barry, as chair

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 6 May 2011 07:41:40 -0700

Hi Alexey,

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Alexey Melnikov
> Sent: Tuesday, May 03, 2011 4:17 AM

> This is mostly fine, but I am wondering if the ACAP vendor name registry (RFC
> 6075), the OID vendor names, or DNS names can be recommended for the
> prefix (to satisfy the "SHOULD be prefixed by an identifying name when
> possible" requirement)?

I don't find this particularly helpful.

The main reason for allowing this kind of extensibility is to align the protocol with common practice which is to add vendor specific parameters without registration. Expecting vendors (and there are going to be hundreds of them, unlike the handful of companies in the ACAP registry) to follow another registry (especially one like ACAP) is just not practical for this particular use case.

Also, given that we are talking about URI query parameters which tend to be short, using DNS names is unlikely to win much adoption. Reality is, there are already plenty of such parameters deployed with OAuth 1.0 and 2.0 drafts.

I think we have a good balance now between promoting interoperability and sharing of ideas (new parameters) and allowing vendors to quickly deploy practical solutions that reflect how they do business today. It took us a while to get to this balance.

I would like to ask the chairs to close this issue with no additional changes.

EHL

---

From: Barry Leiba <[email-masked]>
Date: Fri, 6 May 2011 11:08:21 -0400

>> prefix (to satisfy the "SHOULD be prefixed by an identifying name when
...
> The main reason for allowing this kind of extensibility is to align the protocol
> with common practice which is to add vendor specific parameters without
> registration. Expecting vendors (and there are going to be hundreds of
> them, unlike the handful of companies in the ACAP registry) to follow
> another registry (especially one like ACAP) is just not practical for this
> particular use case.
>
> Also, given that we are talking about URI query parameters which tend
> to be short, using DNS names is unlikely to win much adoption. Reality
> is, there are already plenty of such parameters deployed with OAuth
> 1.0 and 2.0 drafts.

Makes sense.

> I would like to ask the chairs to close this issue with no additional changes.

I think that's right.  Alexey, any further objection or comment?

Barry, as chair

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 07 May 2011 11:14:51 +0100

>The main reason for allowing this kind of extensibility is to align the protocol with common practice which is to add vendor specific parameters without registration. Expecting vendors (and there ar…
Sorry, I don't find your argument to be convincing at all.

Both the ACAP vendor registry (really, the name is historic, it is used 
for other things now and is independent of ACAP) and the PEN (Private 
Enterprise Numbers in OIDs) are first come first serve, so a 
registration only requires sending an email asking for a new value.

>Also, given that we are talking about URI query parameters which tend to be short, using DNS names is unlikely to win much adoption. Reality is, there are already plenty of such parameters deployed…
I can possibly agree with this point.

>I think we have a good balance now between promoting interoperability and sharing of ideas (new parameters) and allowing vendors to quickly deploy practical solutions that reflect how they do busine…
If you say that prefixes should be used and don't state how this can be 
achieved, than what is the point of saying that prefixes should be used? 
Surely prefixes should be unique and any sort of registry is going to 
guaranty uniqueness.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 7 May 2011 09:37:35 -0700

Collision between vendor-specific parameters is not a concern or something we want to address. All we want to avoid is collision between a vendor-specific parameter and a future registered extension parameter. This is why we recommend a vendor-specific prefix. As long as there is a prefix, we've avoided the issue. An endpoint should never have more than one vendor-specific extensions since then it is no longer vendor-specific and should be registered without a prefix.

As for the ease of getting a registration, you still need to go and read another RFC about how to make the request, send an email to a list, and follow up on that. And all that for adding parameters to an endpoint you control, and do not have to interoperate with anyone else other than your own clients.

So I don't see a point in adding such a requirement.

EHL

> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Saturday, May 07, 2011 3:15 AM
> To: Eran Hammer-Lahav
> Cc: Barry Leiba; OAuth WG
> Subject: Re: [OAUTH-WG] Closing a few issues
> 
> Eran Hammer-Lahav wrote:
> 
> >Hi Alexey,
> >
> >
> >>This is mostly fine, but I am wondering if the ACAP vendor name
> >>registry (RFC 6075), the OID vendor names, or DNS names can be
> >>recommended for the prefix (to satisfy the "SHOULD be prefixed by an
> >>identifying name when possible" requirement)?
> >>
> >>
> registration. Expecting vendors (and there are going to be hundreds of them,
> unlike the handful of companies in the ACAP registry) to follow another
> registry (especially one like ACAP) is just not practical for this particular use
> case.
> >
> Both the ACAP vendor registry (really, the name is historic, it is used for other
> things now and is independent of ACAP) and the PEN (Private Enterprise
> Numbers in OIDs) are first come first serve, so a registration only requires
> sending an email asking for a new value.
> 
> >Also, given that we are talking about URI query parameters which tend to
> be short, using DNS names is unlikely to win much adoption. Reality is, there
> are already plenty of such parameters deployed with OAuth 1.0 and 2.0
> drafts.
> >
> >
> >I think we have a good balance now between promoting interoperability
> and sharing of ideas (new parameters) and allowing vendors to quickly
> deploy practical solutions that reflect how they do business today. It took us
> a while to get to this balance.
> >
> >
> Surely prefixes should be unique and any sort of registry is going to guaranty
> uniqueness.
>