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@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf