From: John Stanley (stanley@peak.org)
Date: Mon Jun 16 2003 - 12:11:09 CDT
Thorfinn (thorfinn@tertius.net.au):
>That situation exists in scorefile syntax - you can't score on "parent
>subject", because there's no such header available,
It's called the "Subject" header in the parent article. What do you mean
there is no such header available?
I understand that people will read a parent article and decide "I don't
want to see this topic again, but I want to see this thread again if the
topic changes." In that case, the lack of Re: hints that it has, but even
moreso, the _difference in the Subject itself_ hints that it has. You
don't need to see the lack of Re:, you have the subjects and can compare.
And, if you've killed the previous Subject, the thread will be visible
when it changes. Problem solved.
I do not understand why anyone would say "I've not seen this thread before
(i.e., never had access to the parent or any ancestor) but I know I
do/don't want to read this article because the Subject has/hasn't changed
from the previous article." I just don't see how the changed subject
header has any effect on their decision -- it is data that has no
information. Are there really people who base their decision to read an
article solely on whether the subject has or hasn't changed? And I mean
"solely" in the strict sense -- that't the only piece of "information"
they use. And then, if there really are, is their reliance on a hack
sufficient justification to claim "interoperability issues" and the use of
RFC 2119 language?
And then explain, of course, why leaving RFC2822 as the definition for
Subject would cause anything to change from the way it is now. That's the
crux of the issue -- why RFC2822 isn't sufficient, given the current usage
of the Re: hack already.
>So, don't go claiming "there's no functional difference", because *there
>is*.
No functional difference of any value. Just knowing that the Subject may
have changed (whether or not the actual topic has) is not of any value,
unless you know what the topic was before and are assuming it is
different now. But without the parents, you don't know that.
> See? There we go. You *do* want to do away with it.
I said that is it redundant and is not necessary. I was also EXPLICIT in
saying that RFC 2822 was sufficient language for the definition of the
Subject header, which is an EXPLICIT statement that the definition and
usage of Re: described therein was acceptable. How you can pretend that
this means I am trying to "do away with it" by using language that
explicitely defines it is just beyond imagination. If I wanted to do away
with it, I would have to say "redefine the Subject header in our standard
to do away with 'Re: '", not "use RFC2822 definition" (which includes "Re:
".) I have to assume you know better and are doing this deliberately.
> "Not necessary" implies "don't do it."
Nonsense. "Not necessary" means exactly what it says: there is no need.
"Don't do it" is an imperative instruction that has nothing to do with
need but with actual performance. One does not imply the other. If you
believe otherwise, then please explain why you think the current standards
which make certain headers "not necessary" (i.e., optional) are not in
actuallity saying "don't use these headers"? E.g., Keywords, Summary,
Distribution, Reply-To, and any other optional header you can think of.
> Maybe you don't mean that -
Yes, I don't mean that, and that's why I both have not said that and did
not imply it, and have told you several times that I did not say that and
did not imply it. Yet you continue to say I have.
>They're *not* redundant (in the sense of providing completely identical
>functionality) ...
I guess you also don't comprehend the meaning of "if". IF this draft uses
the wording as specified, yes, "Re: " will be redundant and have the same
function. If it is there, it will still mean "this is a reply", and if it
is not there, it will still not mean "the topic has changed." The meaning
doesn't change just because the strictness of its requirement for usage
changes.
>Redundancy is not necessarily a thing that should be thrown away anyway...
And here you are back at talking about throwing things away. Show me
how RFC2822 "throws away" the Re: hack. Please?
>I don't think that language is strong enough, given that there *is* a
>functional difference between having a well-adhered to "Subject: Re: "
>method, and not. I think we should use RFC2119 language, and we should
>do so in USEAGE.
Well, you've already lost that argument, since, as I recall, the purpose
of USAGE is not to contain the MUSTS and MUST NOTS, but the Oughts and
Ought Nots. That's why it's called USAGE and not USEFOR.
Seth Breidbart (sethb@panix.com):
>If Re: were being used correctly, in Case 2, the child article would
>have "Subject: bar" or perhaps "Subject: bar (was: Re: foo)" or
>"Subject: bar (was: foo)".
I see nothing in the standards that tells me that the article with
"Subject: bar" proves that the topic has changed from the parent. It means
that the author has changed the subject header, but then, we can tell that
because the parent Subject header is different. And the question is still,
so what? If you've not seen the parent, are you really going to decide
whether to read THIS article just because the Subject doesn't start with
"Re: "? You've not seen any of the ancestors, so what difference does it
make if the Subject starts with "Re: " or not, you don't have any idea
other than what the rest of the subject header says as to what the real
topic is. You're going to decide based on everything that (doesn't) follow
the "Re: ", and not on the "Re: " or lack thereof.
But this is still all silly. Nobody is talking about doing away with "Re:
". Nobody but Charles and Bill, who say they don't want it to go away.
So the issue is not "doing away with it" at all, it's justifying mandates
for an obsolete and redundant hack. Argue that it shouldn't be done away
with all you want, you are preaching to the choir, so to speak.
J.B. Moreno (planb@newsreaders.com):
> Did your mail client automatically remove the "Re: " for you?
My mail client did nothing automatically with the Subject at all. I had to
tell it what the Subject was. In any case, it still proves my point, in
that the Subject did not start with Re: and it was not a new topic, as I
think everyone will agree at this point. Seeing an article without an Re:
in the Subject means nothing other than there is no Re: in the Subject.
> That's what "new" means -- that a human entered it.
Oh, please. That's not what "new topic" means. "New topic" means it is a
new area of discussion, not just that it has a subject that doesn't start
with "Re: ". There is no definition in any of the standards that would
support your claim, and common language more than supports mine. Usage
supports mine, too, since I've seen more than one Subject get changed by
someone who thinks it was a poor description of the actual discussion
topic, without that topic actually changing at all. And this discussion,
which isn't new, has a Subject sans "Re: ", so there goes your definition.
Charles Lindsey (chl@clerew.man.ac.uk):
>I have said my piece. I have given up arguing with John, since he
>consistently fails to acknowledge the difference between 'Re' and
>'References', which has been explained several times.
Another deliberate misrepresentation of my position. Since it has happened
so often, I'll call it what it is: a lie.
Of course they are different, and I've not said otherwise. I'm not here
arguing that they aren't different, so I'm not wasting time saying that
explicitely. It would be like us comparing the nutritional merits between
Macintosh and Jonathon apples and you complaining because I wouldn't
acknowledge that they are both red. Prove all you want that they are
different. Have fun. Knock yourself out.
And you've still not answered my question as to what people you hear
calling for a complete removal of "Re: ". You said they exist, please
provide a list of names. This is not my first request for this
information. It would be helpful if you provided it, so we know who is
saying what.
As late as June 13, Charles Lindsey (chl@clerew.man.ac.uk):
> It does no "harm" not to use the "Re: " convention.
I'm sorry you are still unable to differentiate between "is redundant and
obsolete and thus merits no RFC2119 language" and "do not use".
>Anyway, the only real difference between RFC 2822 and the text I posted
>here a few days ago is that the "ought" in RFC 2822 becomes "MUST" in my
>text (I could easily be persuaded to downgrade it to SHOULD).
Until you can support the change to the definition, it should not be made.
Until you can provide some reason for the RFC2119-style language, it does
not belong.
>It is not entirely clear what RFC 2119 wording means in an Informational
>document.
It means exactly what RFC 2119 says it means. Sheesh.
>I _think_ its
>meaning in an Informational document is "a lot of people will be pissed
>of if your break it".
I see nothing at all in RFC2119 that says that MUST and MUST NOT are
appropriate just because people "will be pissed" (and I noted the
vulgarity here). An informational document can present a standard for some
piece of software which will have interoperability issues if some protocol
is not followed just as any standards track document can. There is no
difference there. There is also no interoperability issue here.