Russ Allbery wrote:
Bruce Lilly <blilly(_at_)verizon(_dot_)net> writes:
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).
You're simply wrong about this.
Perhaps, but it will take more than a bald assertion to convince me.
There is no standard document governing the message format of Usenet.
RFC 1036 says otherwise.
There is one obsolete informational RFC that does not agree with current
practice,
According to the latest rfc-index, 1036 has not been obsoleted. It
might well be
your opinion that it should be obsoleted or reclassified, but that does
not affect its
official status. You are of course free to petition for reclassification
of RFC 1036
to historic status (as RFCs 3166, 3638, etc. have done for other RFCs).
and an effort to write a standard which is completely stalled.
It seems to be stalled for lack of agreement on just what comprises
"current practice",
not to mention what *should* comprise best practice. That and the
mantra that "the
draft just needs a few minor tweaks" that has been repeated for
literally years. Unless
I've missed something (entirely possible), in spite of new leadership
(as of about a year
ago) and a planned rechartering of the WG that was set to work on a
successor to 1036
some eight years ago in order to deal with "urgent issues", that WG in
fact has no new
charter. That's not a good sign. I share your frustration, and I wish
1036 had long been
obsoleted by an update that incorporated those things upon which the WG
could agree
(as I had suggested quite some time ago). But it hasn't happened, and
the sad fact is
that 1036 is still the current standard.
Presenting the obsolete informational RFC as a standard because it
contains the word "standard" in the title and no one has yet written
anything better is not doing anyone any favors.
And pretending that there is a well-defined "current practice" does no
favors either.
a) ignore RFC 1036, which means ignoring Usenet, since 1036 is THE RFC
dealing with Usenet message format
This is simply nonsensical garbage. The world does not magically stop
working when you don't have an RFC to work from.
Did I say the world would stop working? Did I say that there isn't an
applicable RFC?
News flash: Usenet is not the world. In the grand scheme of things, it
isn't even close
to being important. It would be difficult to present a convincing
argument that Usenet
isn't the least important application that uses the text message format.
Certainly email,
which is legitimately used (i.e. excluding spam) to a much larger extent
than Usenet, and
which has become an essential tool for commerce, is far more important
than Usenet.
Voice mail, fax, EDI, and even SIP could be argued as more important
than Usenet. Not to
mention the fact that Usenet's historically appallingly low
signal-to-noise ratio (which
seems to keep falling to new lows) is making Usenet largely irrelevant,
it having been
supplanted by weblogs and the like to a large extent.
c) pick and choose bits and pieces from the various standards
It's incomprehensible to me how you can omit the choice that essentially
all Usenet implementors actually take, which is:
d) write code which works with the Usenet messages in the wild and
follows commonly accepted best practice, using RFC 1036 as one of many
guides but not giving it all that much weight
That amounts to precisely the same thing as c, viz. picking and choosing
bits and pieces,
and has the predictable and observable consequences noted, viz.
incompatibilities and
interoperability problems. Writing code which attempts to "work with
the Usenet
messages in the wild" amounts to picking and choosing from a plethora of
incompatible
options; is a header field restricted to the set of octets prescribed by
RFCs 1036, 850, 822,
and 2822, or is it "anything goes"? Are charsets other than the default
properly tagged
per the MIME RFCs or left up to the recipient to guess? And exactly
which charset *is*
the default? Does the existence of the magic incantation " Re: " at the
start of a
Subject field body define a message as a reply, or is it the presence of
a References field
that defines a message as a reply? Where are all of these supposedly
well-defined issues
of "current practice" actually defined? Has the cognizant WG come to
rapid agreement
on any of those issues?