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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
