Re: publishing some standards immediately at Draft-Standard status?

On Fri Nov 13 09:42:32 2009, "Martin J. Dürst" wrote:
> A related point, but from another direction:
>
> My impression currently is that Full Standards never get revised  
> again. Unless I'm wrong, we may have to revise this practice if we  
> go to a model with only one standards category, because sometimes  
> it indeed makes sense to update a document.
No, they do - consider the recent revising of RFC 821 and RFC 822.

Just to throw in some different experience, though, the XSF (which  
does the non-core work on standardization of XMPP) has a three level  
standards track, documented in XEP-0001 - that's  
http://www.xmpp.org/extensions/xep-0001.html - which starts off with  
Experimental, then Draft, then Final.
XEPs, unlike RFCs, get edited in-place, and there's no real  
equivalent to Internet Drafts - "protoXEPs" do exist, but they're  
usually not much more that sketches of what is hoped to be achieved.
Experimental XEPs are conceptually the equivalent of adopted  
working-group drafts, therefore - albeit the XSF has no individual  
submission as such. Experimental XEPs can be changed by their authors  
without oversight or review.
Draft is roughly centered between the IETF's Proposed Standard and  
Draft Standard states, with the difference that the specifications  
are intented to be well-reviewed and stable by Draft, but haven't had  
to be field-proven yet. However, to hit this state they do need  
oversight and review, and any changes from this point on need the  
same.
Final is - roughly speaking - a "cheap" Full Standard. Ive no doubt  
we're not quite as rigorous as the IETF is, here. Final doesn't mean  
immutable, either, it can still be edited.
This mechanism works within the XSF for a number of reasons, not all  
of which are applicable to the IETF. For example, the XMPP community  
as a whole is highly engaged with the standards process, by  
comparison with a lot of the IETF's target communities. Thus making  
work more visible at an earlier stage within the standards community  
overflows into the wider XMPP community very easily. In turn, this  
supports a shorter standards-track (the XSF's is, from this  
perspective, three stage rather than the IETF's four-stage).
We took a serious effort, there, too, to ensure that even at  
Experimental stage, a protocol can be implemented and deployed as  
safely as possible - this eliminates the cases where, for example, an  
IMAP I-D has been deployed and subsequently changed in incompatible  
ways. Again, this supports wider buy-in to the specification's  
development, by avoiding penalizing implementors.
Finally, use of stable identifiers for a particular work item means  
that implementors who are less well engaged can track items of  
interest more easily.
There may well be ways that people feel the XSF is worse than the  
IETF in terms of the design of it's standards process, but as a  
whole, having observed both cases quite closely over the past few  
years, the XSF has a tendency to use its process for positive goals -  
ie, it helps us more than it hinders.
I'm not even sure whether the differences truly matter compared with  
the differences that a highly engaged developer community makes, but  
I do think that if there are perceived problems with the IETF's  
standards process, then it's worth looking at other examples that do  
seem to function well.
Dave.
--
Dave Cridland - mailto:dave(_at_)cridland(_dot_)net - 
xmpp:dwd(_at_)dave(_dot_)cridland(_dot_)net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf