ietf-822
[Top] [All Lists]

Re: RFC 2047 and gatewaying

2003-01-03 23:12:54

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.

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.

Accordingly, Usenet standardization work is half updating of RFC 1036 and
half throwing it out entirely and then going through the gruelling process
of attempting to measure and characterize current practice and them
formalize it in a standard.

When it comes to control message processing, the latter is definitely more
needed than the former.  For example, of the control messages listed in
RFC 1036, sendsys and version have been obsolete and essentially unheard
of for longer than I've been working on Usenet software (at least four
years), ihave and sendme are only useful for UUCP sites and are
practically unheard of given the wholesale conversion of Usenet to NNTP,
and checkgroups, newgroup, and rmgroup are routinely PGP-signed and
verified via a protocol RFC 1036 makes no mention of at all.

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.

-- 
Russ Allbery (rra(_at_)stanford(_dot_)edu)             
<http://www.eyrie.org/~eagle/>

<Prev in Thread] Current Thread [Next in Thread>