I agree with Eran as well that the focus should be on finalizing 2.0 and then future work can occur in new working groups. We're so close! I keep telling people throughout the industry that the spec hasn't changed technically in months but they keep asking when it's going to be a final RFC.
On Thu, Apr 28, 2011 at 10:11 AM, Thomas Hardjono <hardj...@mit.edu> wrote: > Folks, Eran, > > My apologies for jumping ahead to far. I misunderstood Blaine's email. I > took the words "Revised Charter" to mean "Re-charter". > > And usually when a WG says "re-charter", it means a big overhaul (which is > why I mentioned Profiles, etc. etc.). > > This is not the case here. I believe what we are doing today is a just a > charter "clarification", "firm-up" or "clean-up". > > So please ignore my posting :) > > Thanks. > > /thomas/ > > > __________________________________________ > >> -----Original Message----- >> From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] >> Sent: Thursday, April 28, 2011 12:48 PM >> To: Thomas Hardjono; Blaine Cook; oauth@ietf.org; oauth- >> a...@tools.ietf.org >> Subject: RE: [OAUTH-WG] Revised Charter >> >> -1 on all of these. >> >> > -----Original Message----- >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On >> Behalf >> > Of Thomas Hardjono >> > Sent: Thursday, April 28, 2011 7:20 AM >> > To: Blaine Cook; oauth@ietf.org; oauth-...@tools.ietf.org >> > Subject: Re: [OAUTH-WG] Revised Charter >> > >> > Thanks Blaine, >> > >> > This is a good start. I have two suggestions and one request for an >> > additional >> > paragraph/bullet: >> > >> > (a) Openness to future items: >> > >> > I would like to see language that is more open (ready) to accept >> > future items (ie. those on the horizon and those unforeseen). >> > >> > For example, the Kerberos WG has just completed its re-charter >> > recently and had to address this same notion of limit/openness to >> > future items. The language that was finally chosen reflects this >> > openness, I think. Here are two >> > examples: >> > >> > "Prepare and advance one or more standards-track specifications >> which...." >> > (does XYZ). >> > >> > "Prepare, review, and advance standards-track and informational >> > specifications that..." (that does XYZ) >> >> This defeats the purpose of a charter, which is meant to clearly define >> what the working group is scoped to do. I would like to see a charter >> as narrow as possible to help us focus on getting 2.0 done. >> >> > >> > (b) Date for re-charter completion: >> > >> > Should you perhaps add a date for the completion of the re- >> chartering. >> > Say March 2012 (to coincide with the March IETF). Otherwise >> > re-chartering may drag on for sometime -- which is known to happen in >> > the IETF :-) >> >> I have serious doubts about the need for this WG to continue. I for one >> am going to push for closing this WG as soon as the list of >> deliverables are complete. If there is new work, it belongs in a new >> WG. >> >> > (c) Profiles of OAUTH2.0: >> > >> > I know that some folks want to use OAUTH2.0 as is (just the one >> spec), >> > but other folks (including myself) see the need to build additional >> > features on top the single OAUTH2.0 spec to make OAUTH2.0 work in >> other scenarios. >> > For lack of a better term, I use the term "profile" (to mean clearly >> > defined additions and narrowings of aspects listed in the main >> OAUTH2.0 spec). >> > >> > As such, I would like request the addition of the following paragraph >> > to the new charter: >> > >> > Prepare, review, and advance standards-track and informational >> > specifications that define profiles of OAUTH2.0 for usage within >> > certain well- defined environments. These profiles are adjunct to the >> > OAUTH2.0 specification, and add optional capabilities to those >> already >> > defined in the >> > OAUTH2.0 main specification. >> >> This is just a distraction. If you can demonstrate sufficient interest, >> you should have no problem creating a new WG at the conclusion of this >> one, or just submit and individual submission, which is probably the >> only practical way to go with most of these extensions (given the lack >> or implementation experience and small number of people interested in >> them). >> >> >> EHL > > _______________________________________________ > 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
