The sentiment of the WG seems to be leaning towards Specification Required rather than Expert Review.
Barring any objections, I'll update the draft to reflect that and publish a new version later today. On Sun, Jun 24, 2012 at 1:22 AM, Eran Hammer <[email protected]> wrote: > This boils down to whether the registration template can contain all the > detailes required for interoperability or not. If not, you need a > specification. > > EH > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Mike Jones >> Sent: Saturday, June 23, 2012 11:31 AM >> To: John Bradley; Hannes Tschofenig >> Cc: Barry Leiba; [email protected] >> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 >> >> I agree that Specification Required would be fine. I'd rather that there be >> a >> publicly available specification defining the URN than one potentially >> available only to the expert reviewers. >> >> -- Mike >> >> -----Original Message----- >> From: John Bradley [mailto:[email protected]] >> Sent: Saturday, June 23, 2012 8:36 AM >> To: Hannes Tschofenig >> Cc: Mike Jones; [email protected]; Barry Leiba >> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 >> >> I think Specification required is fine. It allows a OIDF or OASIS spec to be >> used as the basis for the registration withh appropriate expert review. >> >> John B. >> >> Sent from my iPad >> >> On 2012-06-23, at 8:31 AM, Hannes Tschofenig >> <[email protected]> wrote: >> >> > Hi Mike, >> > >> > the point is not that other groups, like OASIS, cannot use them. They can >> use the extensions. >> > >> > The question is more what process and documentation is needed to allow >> OASIS (and others) to define their own extensions. >> > >> > So far, OASIS had not been interested for any extension (at least from >> what I know). The OpenID community, to which you also belong, had defined >> extensions (and brought some of them to the IETF) but had been quite >> careful themselves to ensure proper review and documentation. >> > >> > So, if you look at the most important decision points then you have: >> > >> > 1) do you want a requirement for a specification, i.e., when someone >> defines an extension do you want it to be documented somewhere? >> > >> > 2) do you envision a review from experts (e.g., checking whether the stuff >> makes any sense or conflicts with some other already available extensions)? >> > >> > http://tools.ietf.org/html/rfc5226 provides a good discussion about this >> topic. >> > >> > If the answer to the above-listed questions is YES then you probably at >> least want 'Specification Required' as a policy. >> > >> > Ciao >> > Hannes >> > >> > >> > On Jun 21, 2012, at 10:49 PM, Mike Jones wrote: >> > >> >> I'd argue that the registration regime chosen should be flexible enough to >> permit OASIS or OpenID specs to use it. Otherwise, as someone else >> pointed, people will work around the limitation by using unregistered values >> - which helps no one. >> >> >> >> -- Mike >> >> >> >> From: Barry Leiba >> >> Sent: 6/21/2012 12:31 PM >> >> To: Stephen Farrell >> >> Cc: [email protected] >> >> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 >> >> >> >>>> Stephen: >> >>>> Yeah, I'm not sure Standards Track is needed. >> >>> >> >>> On this bit: I personally don't care, except that we don't have to >> >>> do it twice because someone later on thinks the opposite and wins >> >>> that argument, which I'd rather not have at all (My one-track >> >>> mind:-) Doing the 4 week last call means once is enough. But I'm ok with >> whatever the WG want. >> >> >> >> Well, it's not a 4-week LC, but a 2-week one. Anyway, yes, I see >> >> your point, and I've done that with other documents. Better to make >> >> it Standards Track for now, note in the shepherd writeup that >> >> Informational is probably OK, and let the IESG decide. >> >> >> >> b >> >> _______________________________________________ >> >> OAuth mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > _______________________________________________ >> > OAuth mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
