At 00:04 15-04-10, Evan Gilbert wrote:
I've been participating in the OAuth 2.0 discussions, but realized I don't know how the process is supposed to work for getting successive drafts and getting to an agreed upon spec and if we have a rough timeline.

The "Informal Guide" didn't help that much - wondering if someone could give a quick summary of how this is supposed to work.

A few specific questions:
- What does it mean to have successive drafts? And if we move an issue to the next draft, what does that practically mean?

"During the development of a specification, draft versions of the document are made available for informal review and comment". "At any time, an Internet-Draft may be replaced by a more recent version of the same specification".

If the current version of an Internet-Draft (I-D) does not address an issue and it is viewed as an issue by the Working Group (WG), the question might be deferred to a future version of the I-D. There are no hard or fast rules. It's a matter of style or approach.

- What is the expected timing of these drafts?

There isn't a deadline for submitting these drafts. It may be viewed as bad form to submit an updated version of the draft for each minor change. The important point is to gauge whether there is consensus on what will become the final version of the specification. That is first determined through a Working Group Last-Call. It's a matter of using your judgement along the way to build consensus. The WG Chairs can have consensus calls to resolve controversial issues.

- How does the bill become a law?

Before the RFC can be published (I'm skipping some details here), it goes through a Working Group Last-Call and an IETF-wide Last-Call where the IESG asks the IETF community to comment on the document. An IESG Evaluation is performed after that Last-Call to determine whether the document satisfies the criteria for publication. A RFC is not a law. The IETF does not enforce its specifications. It's up to you to determine whether you want to implement what the RFC says and how you are going to do that. It is better, for interoperability, if an implementation that claims conformance to a RFC adheres to it.

Regards,
-sm
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to