Brian's brought up the point that the new organization would cause an implementor to have to jump all around the spec to find all the parts needed. I propose that the working group work on a set of "implementor guides" that detail exactly what parts one needs to deal with all of the major use cases. These would cover both the client and server cases, and would be worded along the lines of "listen like this, accept these five arguments that do this, and return this". In this way, it would be closer to the -06-and-earlier "profiles".
I can see value in this helping adoption. An implementor isn't going to care about elegant organization of thoughts if they can't figure out what parameters to listen for. A set of guides like this would give someone a direct, non-ambiguous way to go about building stuff. Case in point, in all my implementations of OAuth 1.0, I referred more to the connection diagrams than I ever did to the protocol spec. But this of course does beg us to ask, shouldn't the spec itself fill this role? Or can it? -- Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
