On 2011-12-31 00:19, Mike Jones wrote:
I did already back the statement that this is the working group consensus with
the e-mails attached in this note sent to you on December 12, 2011:
- http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html
I replied in
<http://www.ietf.org/mail-archive/web/oauth/current/msg08043.html>:
"I'm not disagreeing with the decision not to allow "\" in the value.
What I'm disagreeing with is writing the ABNF in a way that will make it
likely for implementers to special-case OAuth parameters when they
should not."
So you're citing a consensus for a related but different question. I
recommend to read the mailing thread to the end.
As for your assertion that the specs are in conflict, yes, the Bearer spec
includes a different decision than a RECOMMENDED clause in the HTTPbis spec
(which was added after the Bearer text was already in place). However, it is
not violating any MUST clauses in the HTTPbis spec. Given that no MUSTS are
violated, I don't see it mandatory for this tension to be resolved in favor of
one spec or the other in order for both to be approved as RFCs. I look forward
to seeing that happen soon in both cases (and for the OAuth core spec as well).
As a matter of fact, the HTTPbis P7 text on considerations for new
schemes doesn't use any BCP14 keywords at all. That's on purpose,
because we think they should be used with care, and in particular that
they should only be used to discuss the protocol, not the style of other
specifications.
So it's really not relevant; what's essential is the intent of the spec
text, and I believe that is VERY clear:
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.
(Note the "cannot").
So again, if you disagree with this statement, please argue your case in
the HTTPbis WG.
If you *do* agree, but somehow feel that the bearer spec can't do this,
the bearer spec should document the reason (just like when an
implementation fails to implement a SHOULD).
As to the question of timing (when certain paragraphs were added): yes,
HTTPbis P7 changed based on feedback and review of the OAuth bearer spec
(triggered by James Manger). That's a feature.
If it hadn't, for instance, the bearer spec wouldn't conform to the base
grammar *at all*. See
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/195>.
Best regards, Julian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
