From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Mon May 19 2003 - 04:41:08 CDT
In <3EC501F7.5070907@Sonietta.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>There was discussion about dropping the "Re: " hack entirely, and some
>support for doing so during the discussion. Why then is that not a third
>option in the draft? Heavy-handedness on the editor's part perhaps?
No, I explained the reason. RFC 2822 already explains the correct usage of
"Re :", albeit in a not very forceful manner, and I did not want our
document to be even weaker than that.
However, I also said that if anybody wanted a weaker version, then he
should speak up. You have spoken up, so the debate is now open.
Does anyone else support your position?
In any case, I would still like to hear opinions between the two wordings
I proposed, or suggestions for other ways of expressing the same, or
similar, things.
>[...]
>> [The alternative text is weaker, though correct usage of "Re " is still
>> a requirement.]
>There is no such thing as 'correct usage of "Re "'.
Oh yes there is!
It is quite evident what current best practice is. It is to have at most
one "Re: " and to avoid abominations such as "Re[2]: " which were common
at one time, but have now virtually died out. Even RFC 2822 acknowledges
that position.
The real question is how much of it we say in USEFOR and how much in
USEAGE. The reason why I want to take a firm position in USEFOR is that
implementors need to know whether they need to go to the trouble of
recognizing all those strange variations which were common once, but which
are now hardly ever seen.
Read draft-ietf-imapext-sort-11.txt to see the sort of mess you can get
into if you decide to cope with every variant of "Re" and "Fwd" that has
ever been seen anywhere.
>In both cases, my earlier comment about ABNF production naming still applies:
>if we're going to reference 2822 yet have different syntax, ABNF productions
>which differ from 2822's should be named differently to avoid confusion.
>Specifically in this case, "unstructured".
I don't mind hearing views on this, but it is really a matter for when we
come to the tidying up (and maybe splitting into #1 and #2) of UESFOR, not
for the present stage of splitting off USEAGE.
>> Newsgroups
>[...]
>> administrators should consider the consequences carefully before
>> allowing them to be exceeded.
>>
>> 1. Uppercase letters are forbidden.
Note that text is merely 'advisory'.
>I believe that "forbidden" is too strong. Generation should be prohibited
>for the near future, but the goal should be conformance to RFC 1958 (viz.
>public names should be case-insensitive). Consequently, conforming
>implementations should be required to recognize newsgroup (and distribution)
>names in a case-insensitive manner.
There are two problems with this:
1. There are three headers that are of crucial importance to relaying
agents: Newsgroups, Path and Message-ID (all three have a restricted
syntax for that reason). Currently, universal practice is to eliminate all
need for case conversions/comparisons, for reasons of efficiency. I invite
Andrew to come in here with his standard lecture on this topic (which we
have heard several times before).
2. It is clear that I18N newsgroup-names are going to happen fairly soon,
whether by means of UTF-8 or otherwise. Case insensitive comparisons in
UNICODE are a pain (they would be even worse if you tried to do them in
punycode). There is even less possibility of incorporating them into
relaying agents that for newsgroup-names in pure ASCII (the great beauty
of the former UTF-8 scheme for newsgroup-names was that it worked fine
with existing relaying agents, but only on the understanding that
comparisons were case sensitive).
As for RFC 1958, that is fine for keywords which are in ASCII (such as
header-names). But I doubt any revision of RFC 1958 is going to try to
extend that principle to non-ASCII public names.
>> 3. A component is limited to 30 component-graphemes and a newsgroup-
>> name to 71 component-graphemes (counting also the '.'s separating
>> the components).
>How about changing the obscure "graphemes" to "octets" or "characters".
It is a relic of the UTF-8 days, and may yet be needed for that reason
someday. But I agree that it looks odd as it stands, and I have made a
note to review it when that syntax next comes up for review.
-- 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