Pqx9: In the matter of: Subject-header and "Re: "

From: John Stanley (stanley@peak.org)
Date: Wed Jun 18 2003 - 14:40:40 CDT


Charles Lindsey (chl@clerew.man.ac.uk):

>The reason why "MUST (or SHOULD) NOT use 'Re: Re: ...' or 'Sv: '" is
>better in USEFOR is to make it clear that any agent that automatically
>generates such things is broken and non-compliant, ...

A better example of circular logic would be hard to find. "This section
must say MUST NOT to show that doing otherwise is non-compliant. The
only reason it is non-compliant is because it is a MUST NOT in this
section." Your argument would be valid only if some previous RFC had
included mandates and you wanted to emphasize their existance, but to
claim that creating a requirement is necessary to emphasize that you've
created a new requirement is just ridiculous.

> ... and hence other agents
>which try to take note of "Re: " (for whatever reason) are under no
>obligation to take note of those cases as well.

USENET-ignorant agents that try to take note of "Re: " for whatever reason
are already under no obligation to take note of "Re: " or any other thing
that may appear in the Subject header. We need no special definition of
the Subject header for News to tell agents that already ignore certain
parts of the news standard that they may freely ignore the rest of it.

> May I suggest a grep for "Re:" in the text of RFC 2822?

I've already suggested that, but people keep trying to claim that I'm
calling for elimination of "Re: ". I'm glad you now notice that "Re: " is
defined in a standard that we explicitly reference and I've said has a
sufficient definition of the Subject header.

Now, I've asked you repeatedly to list those people you've claimed are
arguing for an elimination of "Re: " and you've failed to do so. Am I to
assume that you know that nobody has done so but are too shy to admit that
you fibbed about it?

> I have provided those reasons. I see no need to repeat them.

You've provided no reasons that justify the use of RFC2119 language.
You've provided reasons why it is convenient for USENET-ignorant clients
to have "Re: " present, or only one "Re: " present, but that's not
justification for MUST or MUST NOTs. I've already dealt with those
"reasons", I'm asking you to provide something real.

>>It means exactly what RFC 2119 says it means. Sheesh.

>I suggest some reading of RFC 2119.

And I suggest you read the USEFOR draft. Here. I'll quote it for you:

   Certain words, when capitalized, are used to define the significance
   of individual requirements. The key words "MUST", "REQUIRED",
   "SHOULD", "RECOMMENDED", "MAY" and "OPTIONAL", and any of those words
   associated with the word "NOT", are to be interpreted as described in
   [RFC 2119].

        NOTE: The use of "MUST" or "SHOULD" implies a requirement that
        would or could lead to interoperability problems if not
        followed.

So, in just so many words, MUST and MUST NOT are to be interpreted as
described in RFC2119. They mean exactly what RFC2119 says they mean.

Until you show a true interoperability problem, such language is not
justified. The burden is upon YOU to show why the existing definition of
the Subject header needs to be changed, not upon anyone else to prove to
you why it should not. Until you prove this, your redefinition is just
another example of needless changes introduced by the group editor because
he wants things his way and he can introduce them at his own whim.




This archive was generated by hypermail 2.1.7.