Russ Allbery wrote:
Bruce Lilly <blilly(_at_)erols(_dot_)com> writes:
I expect IETF standards which update or replace earlier standards to
address compatibility issues. As discussed on the Usefor list, the
current draft expresses requirements which are diametrically opposed to
what the current standard (RFC 1036) requires (e.g. 1036 makes
processing of articles with Subject: cmsg ... as a control message,
whereas the current draft forbids such processing). Failure to provide
for a graceful transition is a recipe for disaster.
This specific case is a bad example, as major news software dropped
support for the obsolete control message format some time ago.
It is just *an* example; there are other instances.
In general, while I agree with you that graceful transition is important,
I disagree that a graceful transition from RFC 1036 *in particular* is
important. One of the very difficult parts about working on Usenet
standardization is that RFC 1036 is functionally obsolete. It does not
describe how Usenet actually works today.
RFC 1036 *is* the current official standard, whether or not current
practice follows it. The Usefor WG ought to have issued an update to
1036 long ago, in accordance with the task that the WG was formed to
address. Even at this late date, it is still possible for the WG to
update those non-controversial issues where current practice has
deviated from 1036. Such a revision could be one step in the "graceful
transition" to some goal, and could be approved through the standards
process fairly quickly.
Per contra, so long as the WG insists on incompatibility and actively
attempts to break mail standards because "we have to force mail to use utf-8"
(paraphrased), there is absolutely zero chance of the Usefor draft ever
becoming a standard.
[...]
A graceful transition from existing software and existing practice is
important, and a graceful transition from RFC 1036 is a reasonable
fallback in those cases where we cannot characterize existing practice,
but RFC 1036 really shouldn't have much in the way of special standing in
this process given its age and the accumulated differences between it and
standard practice.
Much of what is in the current Usefor draft is clearly untested (or
inadequately tested) experimental work, and that certainly includes
the utf-8-everywhere and parameters-everywhere parts. Those [experimental,
inadequately-tested] parts shouldn't be part of the draft; without them,
a draft could have been finished, approved, and codified as a 1036
successor ages ago.
Then, after appropriate consideration of the totality of the issues
involved, a carefully-designed and adeqautely-tested scheme for
handling i18n issues which cannot be handled via the existing 2047
and 2231 standards could become a successor to (or extension of) the
1036 successor.