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