> -----Original Message----- > From: Mike Jones [mailto:michael.jo...@microsoft.com] > Sent: Thursday, March 31, 2011 11:19 AM
> > Section 2.4: > > > > - ABNF includes '( token "=" ( token / quoted-string ) )', but no prose is > provided about how new parameters may be defined. Retained this > extensibility point must be justified with actual use cases. > > This is insufficient rationale to introduce a breaking change. I would want > to > see a demonstration of working group consensus for this change before > making it. Adding prose is a breaking change? Really?? > > Section 4.3: > > > > - This registry is unnecessary and adds no value here (namespace collision > > is > unlikely in general, and unlikely to cause problems). No use cases where > suggested to justify it, and no additional error codes were proposed in over a > year of discussions. Error codes were intentionally left non-extensible to > increase interoperability. If addition color is needed for existing error > codes, > additional response parameters may be registered. Otherwise, if new error > codes are needed, a new RFC must be published updating draft-ietf-oauth- > v2. > > - The only way to define such a registry is to bring it up as a comment for > draft-ietf-oauth-v2. Otherwise, it is limited to the Bearer token header only > (and since this document is not extensible, not needed even here). > > Your "Error extensibility proposal" note sent on 3/29/2011 documents the > need for error extensibility. This registry meets this need, while being > simpler than the 3/29 proposal and in line with standard IETF extensibility > practices. Whatever this registry defines has no impact on v2. I think it's silly but I don't care about this spec enough to waste any more time with it. My proposal for V2 is currently being reviewed and unless sufficient objections are raised, it will be added to -14 over the weekend. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
