Russ Allbery wrote:
RFC 1036 is not a standard and this is not best practice for Usenet
software. Please do not include this in the grammar.
RFC 1036's title is "Standard for Interchange of USENET Messages". While it
has no standing as an Internet Standard it certainly claims to be a
standard, and
moreover it is current and is THE RFC addressing message format w.r.t.
Usenet
(RFC 850 having been superseded by 1036, and 1036 not having been amended or
superseded).
I agree that a number of things in 1036 are questionable practice;
Subject field
hacks are one of those questionable practices. But questionable or not,
that's
what 1036 requires.
RFC 1036 is not a standards track document and therefore should not need
to be explicitly repudiated by another document.
As a self-proclaimed standard for message format, and with a number of
discrepancies
with other message format RFCs, 1036 presents a problem for implementors; an
implementor apparently has the following choices:
a) ignore RFC 1036, which means ignoring Usenet, since 1036 is THE RFC
dealing
with Usenet message format
b) take 1036 into account, which imposes structure on the supposedly
unstructured
Subject field
c) pick and choose bits and pieces from the various standards
Option a is certainly a viable choice. Option b leads to the present
discussion.
Option c can lead to incompatibilities and lack of interoperability; it
is the option of
last resort.
Repudiation of the questionable items may provide an out for the hapless
implementor.
Maybe not [old messages still exist, and may need to be parsed in
accordance with old
standards].
One of the lessons to be learned is that it can be extremely difficult
to recover from
poor design decisions.