My agreement was, and is, to the *production* rules and not the
*parsing* rules. So long as the former is a proper subset of the latter,
everything is fine. What's happening here is that the spec is being read
-- by experts -- as if it were superceding the latter, and that's not a
good thing.
So as that's the case, I think the solution of using an existing grammar
by reference but further restricting input to that in the surrounding
text makes sense to me.
-- Justin
On 01/25/2012 03:37 AM, Mike Jones wrote:
Eran, do I then correctly understand that you've changed your mind on the position you took in
http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html, which was: "All I agree
with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP
header quoted-string, excluding " and \ so no escaping is needed, ever."? I ask
this, because if I correctly understand your statement that you agree with Julian, you are now
taking the position that you are OK with recipients being required to perform escape
processing for the scope (and other) parameters and with them being required to accept them
either as tokens or as quoted strings.
This raises a question I'd like to ask John Bradley, William Mills, Phil Hunt,
and Justin Richter: Since all of you replied with a +1 to Eran's original
statement, are you still in agreement with it, or are you now possibly
reconsidering your position, as Eran apparently has. I'm asking, because your
messages have been part of the basis upon which I've been taking the position
as editor that the working group consensus is that no quoting may occur. (The
other reason that I believed, as editor, that this was a consensus position is
that this syntax restriction has been present in every Bearer draft, as it was
in OAuth 2.0 draft 10, which was the basis of the first Bearer draft.) If
that's not the actual working group consensus (or it's not anymore), it would
be good to know that now.
Finally, I'd like to respond publicly to a comment made to me in a private note sent to
me about the current discussions. In it, the sender (an IETF "old hand")
observed that it could appear from the strength of my responses to Julian's feedback that
I might be trying to defend a particular personal view of how these issues should be
resolved. I responded to him that the irony here is that I'm not trying to representing
a personal position. Rather, I'm truly trying to do what I believe an IETF editor is
supposed to do, which is to represent the working group's positions.
I'm quite open to the working group making it clear that its position has
changed with respect to Julian's comments and equally open to the working group
standing behind the text in the current draft. If the chairs would like to
help bring this issue to successful closure, I would highly welcome their
participation as well.
Personally, I'd mostly just like to see the spec finished!
-- Mike
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer
Sent: Tuesday, January 24, 2012 10:24 PM
To: Julian Reschke; i...@ietf.org
Cc: The IESG; oauth@ietf.org
Subject: Re: [OAUTH-WG] Last Call:<draft-ietf-oauth-v2-bearer-15.txt> (The
OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
I fully agree with Julian's perspective. I believe there is sufficient feedback
requiring further review of this issue. If the editor cannot facilitate a path
forward, I request the chairs to intervene.
I will make sure this feedback is fully applied to the MAC token specification
in the next draft.
EHL
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Julian Reschke
Sent: Tuesday, January 24, 2012 3:24 PM
To: i...@ietf.org
Cc: The IESG; oauth@ietf.org
Subject: Re: [OAUTH-WG] Last Call:<draft-ietf-oauth-v2-bearer-15.txt>
(The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed
Standard
On 2012-01-23 16:58, Julian Reschke wrote:
On 2012-01-23 16:46, The IESG wrote:
The IESG has received a request from the Web Authorization Protocol
WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Protocol: Bearer Tokens'
<draft-ietf-oauth-v2-bearer-15.txt> as a Proposed Standard ...
Please see my comments in
<https://www.ietf.org/mail-archive/web/oauth/current/msg08120.html>
which I think have not been addressed.
...
In an off-list conversation I heard that what I said before may not be
as clear as it could be.
So...
1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme.
2) In the IANA considerations, it references the registration
procedure defined in
<http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-
2.3>
(now -18, but that doesn't matter here).
3) That document recommends in
<http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3.1>:
o The parsing of challenges and credentials is defined by this
specification, and cannot be modified by new authentication
schemes. When the auth-param syntax is used, all parameters ought
to support both token and quoted-string syntax, and syntactical
constraints ought to be defined on the field value after parsing
(i.e., quoted-string processing). This is necessary so that
recipients can use a generic parser that applies to all
authentication schemes.
4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has
been mentioned that it might not have ignored it if it had UPPERCASE
requirements, but in HTTPbis we try to restrict BCP14 keywords to the
actual protocol, not on recommendations on other specs.
5) The registration requirement for a new scheme is "IETF review",
which RFC
5226 defines in<http://tools.ietf.org/html/rfc5226#section-4.1> as:
IETF Review - (Formerly called "IETF Consensus" in
[IANA-CONSIDERATIONS]) New values are assigned only through
RFCs that have been shepherded through the IESG as AD-
Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The
intention is that the document and proposed assignment will
be reviewed by the IESG and appropriate IETF WGs (or
experts, if suitable working groups no longer exist) to
ensure that the proposed assignment will not negatively
impact interoperability or otherwise extend IETF protocols
in an inappropriate or damaging manner.
In this case the WG exists (it's HTTPbis), and the OAuth got two
reviews from HTTPbis pointing out the problem -- from Mark
Nottingham, the WG chair, and myself, one of the authors.
And yes, I believe the way OAuth defines the syntax *will* impact
interoperability.
Also, I haven't seen any explanation why OAuth can not follow the
recommendation from HTTPbis.
Hope this clarifies things,
Julian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
