From: Bruce Lilly (blilly@erols.com)
Date: Fri Mar 12 2004 - 07:21:27 CST
Charles Lindsey wrote:
>>Charles Lindsey <chl@clerew.man.ac.uk> writes:
>
>
>>>A followup that fails to contain a References header is also a
>>>"compliant article". However, in neither case was the article created by
>>>"compliant" means.
Utter nonsense. A followup must contain a References header field, else
it is non-compliant.
> The problem that I face is that there are people on my left who want
> weaker language (or even no language at all) whereas there are people on
> my right who are determined that stronger language is necessary. As far as
> I can tell, by counting heads, there are slightly more people on my right
> than on my left. Which makes it rather hard to reach a consensus.
As Mark Crispin says:
"Science does not emerge from voting, party politics, or public debate."
We're trying to develop an engineering standard, not judge a beauty
contest. There are clear-cut engineering principles that can be used
to determine whether or not something is part of a protocol, whether
or not ABNF agrees with other verbiage, whether or not wording and
ABNF in one standard agrees with another document, whether or not
something which can be elided at point B is capable of carrying
information from point A to point C, etc. Saying something equivalent
to "I favor contestant E because she has more structure than the others"
isn't engineering.
Either a case is being made based on engineering principles, with sound
rationale, or it is not. Strident rhetoric with no substantiation
doesn't count. This is part of an IETF effort; the E stands for
Engineering.
> Sadly, that is a simplification. Subject-content is in actuality used for
> things other than display. We might wish it were not so, but it is.
You're going to have to do better than a(nother) bald assertion. Give
an example of use of Subject field content for something unrelated to
display (hint: killfile processing is *not* unrelated to display).
Explain in engineering terms the role of that content related to
filing, transport, expiration, etc.
> The hard part is persuading the people on my right to
> agree to that.
Either they are able to make a case based on engineering principles,
with sound rationale, or they are unable to do so. To date I have
seen no such case presented by you or any of the others who are pushing
for structure in the unstructured Subject field, only lame rhetoric
and bald assertions. I'd welcome an engineering rationale if there
is one; but please spare us circular reasoning and bald assertions.
> For the record, my minimal position is:
>
> SHOULD by default take the Subject from the precursor, but MAY prepend
> a single "Re:" is none present.
>
> (there is room for detailed trimming, such as whether "Re:" is case
> sentitive, and there is room for further explanatory text).
>
> I am not going to change that unless some of the people on my right are
> agreeable to it (and I suspect that it is already too weak for some of
> them) or else until a Chair is appointed who can resolve the dilemma in
> some other way. But if a consensus (or even a majority) for a weaker
> wording emerges, then that would be a different matter.
Again, this is supposed to be an engineering discussion. The case has
been made, on engineering principles and with rationale, for wording
which is identical to RFC 2822, and engineering arguments with rationale
have been presented against wording (i.e. "SHOULD" etc.) which differs
from RFC 2822. In other words, sound engineering reasons have been
presented for changing the wording which you have placed in the draft
by either referencing RFC 2822 or by copying RFC 2822 text verbatim.
Conversely no engineering reasons have been presented in favor of the
current wording or for introducing structure in a more formal manner.