Werner Koch <wk(_at_)gnupg(_dot_)org> writes:
On Mon, 25 Oct 2004 10:10:13 -0400, Derek Atkins said:
Unfortunately that is not sufficient....
Is there an RFC defining the rules?
Good question. There is a document on the process in general,
and "The Dao of the IETF". As for when a 'bis' document progresses
to Draft or stays at Proposed tends to be a combination of time,
effort, interop, and the amount of changes between the original
and new document. In particular, to go from Proposed to Draft
you generally can NOT add new features...
FWIW, from the minutes of the 45th IETF OpenPGP WG on 14-July-1999:
Advance to Draft, Collect $200
6 months have passed
Requirements
2 implementations
No IPR problems
6 months of experience
JN: We have the experience but we do not have the interoperability
fully checked. Suggest: Enumerating all the musts and publishing a
document so implementors can easily see requirements for
compliance. Finally, we can get implementors into a room for
testing.
Implementors' survey & results are at:
noc.rutgers.edu/~mione/ietf/ietfopgp.html
This was a long long time ago and under the previous chair, so my
applogies for not being in the loop for this.
Moving to "draft standard" will be a secondary process once we finish
2440bis.
:-(
Okay, to make the later interop testing easier we should now really
consider to make all PGP2 things OPTIONAL or even remove them.
Eh, we can always drop that when we move to draft. Dropping
"features" is perfectly reasonable in Proposed -> Draft. The main
purpose of the interop testing is to see what's been implemented but
also to weed out what cannot be implemented (or hasn't been
implemented) and drop it from the draft _then_.
So, if we're going to Proposed now, as I suspect we are, then there's
no need to drop RFC1991 compatibility now. We can drop in 6ish months
later when we go to Draft.
Werner
-derek
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant