Re: [Mutt] #3328: mutt should handle unencoded whitespace in
#3328: mutt should handle unencoded whitespace in Q-coded strings
-------------------------------+--------------------------------------------
Reporter: antonio@xxxxxxxx | Owner: mutt-dev
Type: enhancement | Status: new
Priority: trivial | Milestone:
Component: mutt | Version: 1.5.20
Resolution: | Keywords:
-------------------------------+--------------------------------------------
Comment(by Derek Martin):
{{{
On Tue, Sep 08, 2009 at 08:01:57AM -0000, Mutt wrote:
In principle, I agree, but...
...in practice, worrying about this case is crazy. If you can find
even *one* example of a subject line containing such a string, where
the thread happened before this discussion, and it's clear that the
reason it appears as such was because it was intended to, I'll be
convinced otherwise (i.e. that it's not crazy -- but I still won't be
convinced that you shouldn't make the change).
Another way to look at this: The RFCs are not laws; they are merely
guidelines. Throughout the history of computing, there have been many
cases where there were competing standards. Here, you have two: the
standard outlined by RFC 2047, and the de facto standard which allows
space in an encoded word, thrust on the world by the most popular
e-mail software in the world, as well as others. You can blindly
adhere to the written standard, or... you can ignore it and
interoperate with the rest of the known universe. Which is better?
"Very bad?" Hardly. Besides, I assert that it will never be a
problem (barring cases where the poster is specifically trying to
point out problems with this encoding scheme), precisely because so
many mailers don't interpret the RFCs correctly. If such a thread
were created, no doubt the subject line would be changed almost
immediately as the thread progressed, and almost certainly writing
such a subject line will be discouraged by people who have any clue
about this issue.
I think it would be a satisfactory compromize if Mutt recognized that
such an encoded word were present, and display the given header both
ways... although that seems slightly gross. At least then, the user
would be able to read the subject line as it was intended to be read,
regardless of what mail client generated it. But I think the most
sensible thing would be to just ignore the standard, and interpret it
like everyone else does.
}}}
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3328#comment:>
Mutt <http://www.mutt.org/>
The Mutt mail user agent