From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Tue Feb 03 2004 - 09:20:51 CST
In <401D71CB.7090400@erols.com> Bruce Lilly <blilly@erols.com> writes:
>Russ Allbery wrote:
>> I agree with Bruce, with the caveat that I do believe it is important to
>> tell client authors *somewhere* about the "Re: " convention and make sure
>> they're aware that basically every existing news client uses it and that
>> it, while not a protocol issue, is widely expected behavior. While it may
>> be a display issue, it's a display issue that a lot of people expect.
>>
>> But this need not be in the standards document. I think it's a perfectly
>> reasonable thing to explain in the GNKSA document.
Indeed. There is wording in USEAGE on this, and that wording is open for
detailed discussion.
>There are a couple of things that need to be made clear:
>1. presence or absence of "Re:" means nothing. A message with or w/o "Re:"
> might or might not be a reply. This is not a protocol issue, but we
> need to make it clear to implementors that it is not a protocol issue.
Not quite. There are the following things that might happen:
1. A followup agent just copies the existing header withhout any "Re: ".
In this case, nothing unpleasant happens.
2. A followup agent checks whether a "Re: " is already present and, if
not, inserts one. In this case again, nothing unpleasant happens (because
current agents are used to this situation and know than an initial "Re: "
has to be ignored during certain operations).
3. A broken followup agent creates a "Re: Re: " or "Re^2: " situation. In
this case, unpleasant things DO happen. Subsequent agents may show this
article separately from others in the same thread. Or they may purport to
detect a change of subject where none was intended. Or they may break in
other ways (since current agents do use "Re: " for a variety of purposes.
So it IS a protocol issue insofar as #3 can lead to interoperability
problems (and our Chair, when he was still participating, did rule that it
was in order to consider it as an interoperability matter). Granted it is
not a particularly gross interoperability, and therefore a "situation #3
SHOULD NOT arise" should be sufficient to cover it. I just cannot see why
you are so opposed to that.
Of course, what is said is USEAGE can, and likely will, go further than
that.
BTW, people have been saying that threading by references is THE proper
way to go about it, and that threading by Subject is old-fashioned. But it
is not as simple as that. Many current threading agents endeavour to
detect a change of subject within a thread, and move the new subthread to
a separate area. This is usually a configurable option, but users do seem
to like it. Of course, it fails if "Re: " processing is wrongly done, and
also if various other broken things happen, but on balance it works well
enough to be useful.
>2. Prefacing an existing Subject field with "Re: " is NOT a simple matter
> of inserting the string "Re: ". It is necessary to ensure that if the
> modified Subject field contains any encoded-words, that those words are
> on lines with length no greater than 76 octets (in accordance with RFC
> 2047). This *is* a protocol issue. Likewise w.r.t. recommended line
> length and mandatory line length limits in the absence of encoded-words.
This particular issue is currently discussed in USEAGE. Maybe that bit
should be moved to Usefor.
>Beyond those, it's certainly possible to cover other non-protocol topics;
>the silliness of "Re: Re: " and "Re^2:", "FW", "Fwd", "Auto:", etc.
And those also are discussed in USEAGE.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5