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.
... 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
expectation that "format=flowed;" is now implied.
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
make make format=flowed; standard?
Seems unlikely.
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.
The first part seems reasonable, the second seems like a massive overreaction
and IMNSHO has zero chance of being adopted.
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?
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf