From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Mon Jul 02 2001 - 05:49:23 CDT
In <ylofr7xc9y.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes:
>Those people and I have a very strong difference of opinion, then. My
>opinion has been formed and hardened by watching this group flounder
>around topics for years now; even if there's a valid point behind
>requiring 8bit encoding on Usenet, I now doubt whether there's sufficient
>resources here to finish standardizing the *Usenet* portions of this
>document, let alone going back and revisiting decisions made by the MIME
>folks.
>(And by resources, I'm specifically thinking of things like testing,
>implementing the draft and seeing if it works, protocol bakeoffs, and the
>like. Coming up with the wording is hard enough and that's the *easy*
>part.)
Yes, but in this particular case all the various encodings are a "MUST
accept" for all agents, so the implementation effort required with either
wording is much the same.
>> The problem with the "SHOULD use 8bit" wording, however, is that you then
>> have to spell out the exceptions in detail,
But the wording is written, so all the exceptions are there to be seen.
The only practical difference between them is the pressure that is applied
to the writers of posting agents. With the weaker wording, they will see that
their software will be compliant even if they take the easy route (as mail
agents currently do) and encode _everything_ "just in case". That would
piss off a lot of current users who do not like seeing such stuff.
With the stronger wording, a user agent that does not make some genuine
attempt to use 8bit wherever practically possible will find itself only
partially compliant. That puts the writers of such agents under some
pressure.
It is, of course, the posting agents that are affected. The reading agents
MUST accept regardless (but we know well that it is going to take a long
time for that state of affairs to come about, which is why we are asking
the posting agents to be as halpful as possible in the meantime).
>> So this is an issue we can discuss, but be clear that it is going to
>> lead to an argument far more intense than the recent Archive furore :-(
>> .
>It's at least more important than the Archive header; if I had the choice,
>I'd rather spend my time arguing about this.
But I see no need to have the argument, because the effect on what
implementors actually have to DO is rather small (and I would be quite
happy for implementors to concentrate on the MUST things before getting
around to the SHOULDs).
>> Actually, no. The message/partial as defined in RFC 2046 leaves several
>> things unclear, notably exactly how the References header is to be used.
>> Therefore our draft provides some extra guidance in that area which
>> ensures that reading agents which already do threading will find it easy
>> to do joining together of message/partials.
>I vote that we decide this is out of scope and will just needlessly
>complicate our standard, given that we don't anticipate widespread use of
>message/partial on Usenet anyway, and at most note this problem in a NOTE.
>Those who care can take up the matter with ietf-822 and hammer out a
>better definition in a future revision of the MIME standards. References
>is now a mail header, so it's well within scope for such a revision.
No, References is primarly is News header, which mail has now adopted (but
which is not all that regularly used). Mail user agents mostly do not
implement threading (there are some honourable exceptions that do) whereas
it is quite common in news readers. The particular usage porposed for
References is to build upon that threading feature of news readers, since
it is easily extendable to do reassembly of message/partial.
But I will have another look at that bit, and compare it carefully with
RFC 2046.
-- 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@clw.cs.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