From: John Stanley (stanley@peak.org)
Date: Tue Jun 10 2003 - 14:32:15 CDT
I'll start with a challenge to everyone who thinks this Re: hack needs RFC
2119 language: if it needs RFC2119 language to make it useful, then how
has it achieved such widespread use without such language? And
furthermore: given the existing lack of RFC2119 language concerning the
"Re: " hack, what makes you imagine for a second that continuing with the
same language will cause the "Re: " hack to go away? If your sole reason
for arguing about the level of language in the draft is that you think
someone is trying to STOP Re: from being used, then you can stop arguing.
Boris 'pi' Piwinger (3.14@logic.univie.ac.at):
>Why don't we start with an argument why this should be changed?
Yes, please, provide an argument why it should be changed. Oh, you didn't
know that the use of "Re: " is not mandatory in the current standard? You
didn't know it is not mandatory in RFC2822? Yes, why do we need stronger
language than RFC2822 has? Other than the oft-repeated "broken software
needs it" argument, why?
>It works perfectly.
If you are referring to Subject threading, no, it does not work perfectly.
It will happily thread different threads together just because they have
the same subject. I've pointed that problem out already.
Furthermore, I challenge you to find the parent article to the one you are
reading, based on the Re: hack. I also challenge you to find the direct
child to the article you are reading using the Re: hack. I challenge you
to sort the articles with the same subject into correct parent-reply order
using the Re: hack. If it works "perfectly", you ought to be able to do
all of this. (All of this is possible using the References header.)
> Which clients do this?
The ones Bill Davidsen uses. The ones I use DO mark replies when I see
them, so the requirement for "Re: " to accomplish this is specious.
>With Re: you can in a list which displays only subjects see
>if this is a followup or not.
Your client is free to show you whatever it wants to. This is not an
interoperatbility issue, it is a user interface issue. If you don't like
how your client does things, get a better client. It's not our job to
design clients, just to get them the information they need -- which is
found in the References header.
>That agents could put a Re:
>there if it is missing is not convincing.
Really? Why can't reading agents put it there if it is missing? But then,
who says it will be missing?
>Further, it is very useful to be able to display subthreads
>with a new subject as a new thread.
It is wrong to do so, unless it truly is a new thread. That's one of the
problems of subject threading that I've already mentioned.
>But (see above) you can do much better, if things are done
>properly.
No, you cannot do things "much better" if you do them improperly -- which
is what you choose to do when you choose subject threading instead of
References threading.
>>This isn't even an odd-man-out issue. It's an issue of JUSTIFYING the
>>creation of a difference. The difference between RFC2822 and this draft in
>>the matter of the Subject header cannot be justified
>I don't know if you ever used e-mail,
And you have the nerve to claim that someone else is trolling.
> ... but there Re: is used.
Your lack of understanding of what this discussion is about is absolutely
amazing. Please read RFC2822 wrt Subject and "Re: " and tell me why there
needs to be any stronger language than is found therein. Please find a
dictionary or get a friend to explain to you the difference between "is
used" and "is mandatory". Please find a dictionary or find a friend to
explain the difference between "RFC2822 is sufficient" and "don't use".
Charles Lindsey (chl@clerew.man.ac.uk):
>No, MUST NOT is correct because there is software around that will do the
>wrong thing (or fail to do the right thing) if it is ignored.
And what software would that be, Charles? I'll answer that for you.
USENET-ignorant software. Software where the author has CHOSEN to ignore
the References header. That's the software that will fail to "do the right
thing" without the Re: hack. What other deliberately USENET-ignorant
software will we try to support in this USENET message standard?
Charles Lindsey (chl@clerew.man.ac.uk):
>Personally I could be persuaded, but in view of a few people who are
>pressing for complete removal of this feature, I thought that was the best
>compromise.
A: It is not a feature, it is an obsolete hack. It does not warrant
mandates regarding its use. At BEST, it merits the language already
present in RFC2822.
B: Please produce the names of those people you think are calling for
"complete removal" of this so-called feature. I've seen nobody saying
this. I'm serious: if you've been following the discussion sufficiently to
understand both sides and function as editor, you should be able to
produce this list. I won't even ask you to provide message ids, just
names.
C: It is not a "compromise" to start with a definition that has no RFC
2119 language regarding a "feature", see an argument that wants to keep it
that way, and then produce a definition that has RFC 2119 language.