Subject: how to make Apple Mail comply to email standards: or vv?

From: Michael Richardson <[email-masked]>
Date: Sun, 09 Oct 2011 11:19:17 -0400

I've just received an important email from an important person (a former
IETF chair even) on an IETF mailing list.

The content-type was: 
    Content-Type: text/plain; charset="us-ascii"

yet the first line of the mail was 491 characters wide.  There is an
expectation that "format=flowed;" is now implied.

Has the YAM WG taken this into consideration?  Will a new standard now
make make format=flowed; standard?

I'm really really really tired of this.  I never expected redmond to do
the right thing, but at least everyone with a clue knew that they did
the wrong thing, and some versions of that system there was even
settings that mostly did the right thing.  

Meanwhile a colleague of mine in the non-IT space is complaining that he
can't read email that I send because his Apple Mail program seems to
forceably reformat all text, assuming it is format=flowed;
RFC2646 has been around for 11 years now.

So my request is simple:
   1) can the IETF secretariat please document appropriate settings for
      commodity mail user agents that comply with RFC2464, and configure
      our mailing list software to filter anything that does not comply?
      I'm serious about this. It's embarassing.

   2) alternatively, will the YAM (or another WG) please update the
      standard to say that "format=flowed" is now the default, and
      ideally also give me some idea if "format=fixed" will do anything
      at all with MUAs out there?
        
-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: [email-masked]
Date: Sun, 09 Oct 2011 09:30:41 -0700 (PDT)

> yet the first line of the mail was 491 characters wide.

... which is legal according to the relevant standards. There are legitimate
uses for fixed format messages with long lines, which is why the 78 character
wrap limit is a SHOULD, not a MUST.

Of course in the case you present the line should have been wraped. But that's
a user agent quality issue, albeit a fairly common one.

> There is an

That particular wrongminded expectation has been with us in one form or another
for almost 20 years - it became a real problem shortly after MIME was
published, as a matter of fact. There have been many attempts to address it,
including the relatively recent definition of the format=flowed label.

> Has the YAM WG taken this into consideration?

Of course it hasn't. Read the charter. YAM has a single purpose:

    The Yet Another Mail (YAM) WG will revise existing Internet Mail
    specifications currently at Draft Standard to advance them to Full
    Standard. 

Even if there was a consensus to make format=flowed the default (and I've seen
no sign of any such thing), YAM couldn't do it. You know, that whole pesky "no
significant changes when moving from draft to full" thing?

> Will a new standard now

Seems unlikely.

>       I'm serious about this. It's embarassing.

The first part seems reasonable, the second seems like a massive overreaction
and IMNSHO has zero chance of being adopted.

>       at all with MUAs out there?
        
Again, making such a major change to the default handling of the most comon
type of email seems unlikely to be feasible at this stage.

And besides, we've tried standards-making in this space quite a few times
(simple text proposal, text/enriched, format=flowed, etc.) and nothing
has worked. I see no reason to believe that further standards-making
will do anything but further fragment the behavior of user agents.

So perhaps it's time to try a different approach. Instead of writing yet
another technical specification, write a best practices document that
explains the problem and gives specific advice to user agent developers.
This sort of thing has been conspicuous by its absence in previous
documents.

Just a thought.

				Ned