From: Bruce Lilly (blilly@erols.com)
Date: Mon Mar 15 2004 - 23:47:55 CST
Russ Allbery wrote:
> Here, what about this? Bruce, John, I'd also be interested in your
> opinions as to how this sounds and whether you feel like this adds
> structure to an unstructured header:
>
> The Subject-header SHOULD be initialized from the precursor's
> Subject-header with any initial "Re: " removed, preceeded by the
> literal, case-sensitive text "Re: ". Posters MAY change this before
> posting if they wish, and therefore reading agents cannot rely on all
> followup Subject headers having this format.
>
> The "Re: " convention predates the References header and was
> originally used to enable a simple form of thread sorting. With the
> more complete and accurate thread information found in References,
> strict adherence to this convention is somewhat less important, but it
> is still widely used and not following it by default may cause
> confused presentation of messages in reading clients.
>
> A change in the Subject away from the above convention is often taken
> to signify a sufficient change in topic of a thread as to warrant a
> different visual presentation to the reader.
>
> One could toss in a parenthetical about the Latin origins of Re somewhere
> if one felt like it.
Several points:
0. I'm assuming this is for the "practices" document (#3) as it does not
deal with syntax or network operations.
1. factual basis: I'm not convinced that the first sentence of the 2nd
paragraph is accurate. "Re: " was initially adopted from a convention
used in printed memoranda and predated any (electronic) sorting by
subject. As far as modern Usenet is concerned, use of "Re: " in
Subject and References was simultaneous (RFC 850). And it actually
*hinders* sorting.
2. Unnecessary complexity. Removing "Re: " only to reinsert exactly the
same thing seems pointless.
3. Incomplete. It doesn't address the fact that an original subject
might begin with the characters "Re: ". Nor does it address the fact
that some other hacks ("Fwd: ", "Antwort: ", "Sv: ", etc.) are also
used.
4. Overstates some things, e.g. not prepending "Re: " "may cause confused
presentation of messages in reading clients".
5. It imposes structure, as there is no provision for not prepending
"Re: ". See also the discussion below.
> I don't think the encoded-word bit is necessary given the wording above.
If one wishes to discourage use of Sv and Antwort etc. mentioning Latin
may help. To be fully compliant with RFC 2277 BCP, it should be something
like "=?utf-8*la?q?Re:_?=", which will reinforce that point. Without that,
one is treating "Re: " not as text, but as a "name" (in the RFC 2277 and
RFC 1958 sense) and one is once again imposing structure.
I really think we need to postpone discussion of the detailed wording
for the third document until after we get the first two documents ready.
The delays have already led to the situation that by the time we submit
the first document, it will also have to include header field registration
entries for the news-specific fields -- that's one more thing that will
have to be added, and it's work that hasn't been started.
If you want to keep track of points to be included when we get to document #3:
* "Re: " is a text convention, with Latin roots, with a long history of
use in printed documents.
* It cannot be mandatory. (that would conflict with unstructured)
* As text (vs. a "name"), we should reinforce current BCP (RFC 2277).
* As text, we should recognize that case is unimportant
* With the exception of some technical documents used in very structured
organizations, printed documents had nothing analogous to the References
or In-Reply-To fields, which provide information about relationships
between messages.
* As a mere convention and not a carrier of information, it is prudent not
to read too much into either the presence or absence of "Re: "
* use of a convention as though it contained reliable information (it does
not), when there is a reliable source of information readily available,
constitutes a "hack"
* A dozen hack variants is a bit better than a hundred. One is a bit
better than a dozen. And none is enormously better than one. That's
the nature of a "hack".
* optionally, we can also discuss "(Was "
* optionally, we could also discuss the dozen or so variants of hacks
for multipart messages (all of which are pointless due to MIME
message/partial, which is an officially structured way of indicating
partial messages).