Re: [EAI] MIME questions (was: draft-hurtta-eai-messagestore-00.txt)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [EAI] MIME questions (was: draft-hurtta-eai-messagestore-00.txt)



On Fri, 23 Mar 2007 12:48:44 -0000, Frank Ellermann <nobody at xyzzy.claranet.de> wrote:

Kari Hurtta wrote:

["what is MIME"]
Was that discussed on meeting?

Don't think so, I only know the jabber log: http://www3.ietf.org/meetings/ietf-logs/eai/2007-03-20.html

You was suggested to ask from MIME experts that
       Is UTF-8 possible in MIME version 1.0 header fields ?
What was result?

Nothing, unless "[10:39:54] --- nsb has joined" indicates something that's not visible in the log.

My feel is that
   - If UTF-8 can be added to address and subject
     header fields without label, then UTF-8 can be added also
     to MIME header fields without label.

Yes, that's where we disagree, because it makes the identification of a message/utf-8 too difficult:

Looking into the header is one thing, but parsing
the body for MIME part headers is another thing:

Looking for somebody else's trouble, none of our
business, what if the MIME structure is broken,
should that affect message/utf-8 transport, etc.

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

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.

It's IMO possible to implement 2049 ignoring 2231, and treat 2231 "features" as garbage.

Of course that software then couldn't claim to
support the (approved) NetNews message format,
but that RFC won't be published before another
RFC is ready... <sigh />

So changing MIME header field syntax yet one
more time is not different.

2231 is in a certain sense "compatible" with MIME 1.0, while raw UTF-8 in Content-* header fields directly _violates_ a requirement in 2045 (or whereever it was, we quoted it here often enough).

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


We are constructing a new kind of mail object - call it a RFC2822-u object if you like. And 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.

And we are also inventing a new kind of MIME-Version-1.0 object, let us call it a MIME-Version-1.0-u object, and 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 toe non-EAI iniverse.

There is NO difference in principle between the two cases.

Yes, we might decide to call them MIME-Version-1.1 objects instead of MIME-Version-1.0-u objects, and require a new MIME-Version: 1.1 header. But 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.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 ;    Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.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


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




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.