From: Bruce Lilly (blilly@erols.com)
Date: Mon May 12 2003 - 08:46:48 CDT
Charles Lindsey wrote:
> It all depends on how you define "interoperability".
>
> If you say that the sole purpose of Netnews is to deliver articles from
> posters to readers accurately and without loss, then you can adopt a
> narrow definition of "interoperability" as that which interferes with the
> delivery.
That [transmission] is *part* of what entails interoperability. Another
part is related to the message format and its generation, processing,
parsing, and display.
> But if you accept that Netnews includes much "added value", in the form of
> bells and whistles (i.e. "features") in user agents, such as threading,
> following up, spam fighting and other user conveniences,
Features per se do not comprise interoperabilty. And none of those
features are uniques to Usenet -- they apply equally to mail.
> "Re: " in subjects, "-- " before signatures),
Those are contrary to "spam fighting", as John has pointed out.
> "Re: " will be an interesting borderline case because, as
> Bruce has pointed out, it could benefit from some ABNF assistance.
For clarity, my point was not that any "assistance" is merely desirable.
It is that if Subject is to be redefined as something other than
unstructured -- and the "Re: " hack does exactly that -- then it
is *necessary* that the ABNF clearly indicates the structure. It is
unreasonable to knowingly produce a document which is internally
inconsistent, and ABNF that says something different from the
text is a gross inconsistency if it is unnecessary (about the
only necessity is the issue of header field order, which cannot
be concisely made order-independent via ABNF).
The same applies to SP-after-colon, etc., which was also included
in the sample ABNF for Subject. Indeed, the discussion is about
the implications of the differences between the draft and RFC 2822,
one of which is that substantive differences make reference to
2822 of limited utility -- if *every* header field in a news
article requires different ABNF from 2822 (and those defined
in other RFCs as well; 2045, 2156, etc.), then the ABNF for
each needs to be specified.