[EAI] Re: MIME questions

[Frank Ellermann <nobody at xyzzy.claranet.de>]

Charles Lindsey wrote:

> If the MIME structure of broken, then Garbage-in
> Garbage-out. That is already true with out UTF8SMTP.

Kari's proposal would bounce anything misidentified
as message/utf-8 at the final delivery MTA, if the
LMTP-MDA says "no, thanks, legacy mailbox".  That's
not GiGo, it's more like "garbage in, garbage back".

>>> MIME header field syntax is already updated
>>> without changing MIME-Version header field.

>> In an IETF theory styling itself as "RFC 2231".

> No, it is not a "theory", it is a "proposed
> standard", just like RFC 2045 and RFC 2822.

http://purl.net/net/rfc/2045       => DRAFT STANDARD
http://tools.ietf.org/html/rfc2045 => DRAFT STANDARD

Ditto 2046, 2047, and 2049,  The registry stuff in
2048 is BCP 13 (now consisting of 4288 and 4289).

We discussed the implicit side-effects of 2231 wrt
multiple parameter name=value pairs using the same
name for some months in USEFOR with Bruce, Ned, and
Alexey.

Fortunately Bruce caught this bug before we pulled
a stunt like introducing multiple "ComplaintsTo"
parameters into a single header field claiming to
use MIME syntax.  Ned saying that he always had an
"environment" model in mind for MIME 1.0 on a list
isn't the same as saying it explicitly in RFC 204x.

Let's hope that nobody else tried it "successfully",
it is rather tempting to simplify the syntax of an
enumeration.  And it breaks miserably with the 2231
concept of multi-line name=value paramaters.

> And raw UTF-8 in any header directly violates a
> requirement in RFC 2822, but that has not stopped us,

2822 is the Internet Message format, we "adapted" it
as necessary in USEFOR, because it didn't fit several
reqirements for NetNews (in essence creating a proper
subset of 2822 + plus adding header fields only used
in NetNews).

We didn't modify MIME 1.0 for NetNews, in my parallel
universe that would be blasphemy.  I'd really prefer
it if EAI also stays away from "extending" MIME 1.0 -
above adding a bunch of new MIME types as outlined in
the DSN draft.

> We are constructing a new kind of mail object - call
> it a RFC2822-u object if you like.

<sarcasm> I like to call it message/utf-8 </sarcasm>

> we are designing a protocol which is supposed to
> ensure that RFC2822-u objects are converted to RFC2822
> objects before they are allowed to enter the old
> non-EAI universe.

You've skipped an important step:  We know how to convert
message/utf-8 into message/rfc822 for 8BITMIME.  For this
8bit part of the universe anything is straight forward.

We're less sure about the 7bit part of the universe, it
could make sense to invent a general mechanism working
for any 8 bit message/foo (not only message/utf-8) if a
message/foo is forced to be transported by 7bit relays.

But such "8to7" considerations are out of scope for EAI,
getting this right without any application/message hack
is a major headache (see Kari's encapsulation I-D) and
limited to message/utf-8.

> we are also inventing a new kind of MIME-Version-1.0
> object, let us call it a MIME-Version-1.0-u object

Any MIME 1.0 message/rfc822 can be an 8bit multipart/*
with message/utf-8 parts, and vice versa.  So far not
"new", that's how MIME and message/utf-8 are designed.

The _new_ concept would be MIME Version-1.0-u (or 2.0)
allowing raw UTF-8 in its Content-* header fields and
MIME part headers.  It changes the meta language used
to talk about MIME parts and their structure.  It's
not absolutely necessary for EAI to introduce MIME 2.0
now.

> we are designing a protocol which is supposed to
> ensure thar MIME-Version-1.0-u objects are converted
> to MIME-Version-1.0 objects before they enter to a
> non-EAI iniverse.

That's shaky.  IMO you want too much in one giant leap,
the transition from MIME 1.0 to 2.0 will be a rough
ride, what with implementations checking the version
and treating anything that's not MIME 1.0 as garbage ?

And why would you wish to bind the success or failure
of EAI to this MIME 2.0 feature ?  It's tricky enough
without it.

It reminds me of Martin's mailto-bis I-D where he wanted
to jump from 1738 to 3987+EAI without a pit stop at 3986.

Or your news-and-nntp proposals.  Or the Sender-ID RFCs
trying to change the email architecture fundamentally
based on observations working for c. 80% of all emails.

I don't believe in "wordwide upgrade" scenarios, it's
very hard to get folks to upgrade, just because an RFC
says so has nothing to do with it.

> There is NO difference in principle between the two
> cases.

Yes, in principle you can do MIME 2.0.  What you should
NOT do is claim that 2.0 is still 1.0.  I hate anything
in the direction of "embrace and extend", where that's
actually "embrace, extend, and extinguish".

MIME is a text book example of a standard guaranteeing
backwards compatibility as far as possible and beyond.
The authors should get a Turing-award or something for
this masterpiece.

> having just got rid of a Header-Type header to
> distinguish RFC2822 objects from RCC2822-u objects,
> it would be rather odd (and confusing IMHO) to take
> a different route as regards MIME.

Well, there's no message/rfc822 header field in a top
level mail or news message, but message/rfc822 is used
as MIME Content-Type for message bodies or MIME parts.

Like a message/utf-8 will be used as Content-Type for
message bodies or parts with raw UTF-8 in the "header
field bodies" (i.e. headers, we know the terminology).

MIME part headers are a different issue, it's not a
part of 2822 with the Message format, it's a part of
MIME.  The MIME design guarantees that MIME ignorants
can transport MIME messages, they can even read MIME
to some degre, and reply to or forward MIME messages
without knowing what =?utf-8*en-DE?Q?this?= means.

MIME is completely transparent, if you don't know it
you can savely ignore it, and it still works.  Okay,
admittedly I never bothered to really understand what
message/partial is, let's say s/completely/almost/

Only Bruce knows what that is, and only Bruce tried
to join 2822 and MIME.  I still have his four I-Ds,
it's a shame that nobody (including me) tried to use
his work.

Ignoring Bruce's I-Ds MIME works on top of 2822, you
can use 2822 without knowing what MIME is.  And you
can use MIME on top of 822 ignoring anything in 2822
that you don't like (but I guess there's only one
Resent-* monstrosity in RFC 2822 where it could make
sense to stick to 822).  2882 is also a masterpiece,
minor nits not withstanding, splitting the ABNF in
obs-* and non-obs-* mast have been hell.

Frank



_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima