Re: [EAI] FINAL POLL RESULTS on the "what MIME type" question

["Charles Lindsey" <chl at clerew.man.ac.uk>]

On Thu, 05 Jul 2007 19:51:05 +0100, Harald Tveit Alvestrand  
<harald at alvestrand.no> wrote:

> QUESTION 2: Should the same MIME type be used to carry UTF8SMTP messages  
> in
> a SMTP environment (without the UTF8SMTP extension, and without requiring
> the 8BITMIME extension)?
> This implies that it's possible to encode the message.
>
> A: Yes.
>    Harald Alvestrand
>    Chris Newman
>    John Klensin
>    Yangwoo Ko
>    Martin Duerst
>    Kazunori Fujiwara
>    Mao Wei
>    Randall Gellens
>    Yao Jiankang
>    Tony Hansen
>    Jaeyoun Kim
>    Abel Yang
>    Andrew Sullivan
>    Bjoern Hoehrmann
>    Yoshiro Yoneya
> B: No, that should not be allowed.
> C: I have another opinion, which is....
>    Kari Hurtta
>    Charles Lindsey
>
> Based on this result, I am declaring this question closed.

This question has two premises:

1. That a message/utf8smtp should be transportable in the current SMTP  
environment.
2. That encoding of message/utf8smtp will be necessary in that environment.

Since these two premises are mutually incompatible, the question as asked  
is meaningless. I shall address these issues in terms of the new  
draft-ietf-eai-utf8headers-06.txt.

1.2.  Relation to other standards

   This document updates section 6.4 of RFC 2045.  It removes the
   blanket ban on applying a content-transfer-encoding to all subtypes
   of message/, and instead specifies that a composite subtype MAY
   specify whether or not a content-transfer-encoding can be used for
   that subtype, with "cannot be used" as the default.

   This document also update [RFC2822] and MIME, and the fact that an
   experimental specification updates a standards-track spec means that
   people who participate in the experiment have to consider those
   standards updated.

The second of those paragraphs is fine; it is what we have been saying and  
doing all along. But you just cannot write that first paragraph in an  
Experimental RFC, because it requires/expects changed behaviour from those  
NOT participating in the experiment.

4.6.  message/utf8smtp


   The second type, used for content return, is message/utf8smtp which
   is similar to message/rfc822, except it contains a message with UTF-8
   headers.  This type has profound implications on the email
   infrastructure.  First, [RFC3501] servers MUST NOT descend a message/
   utf8smtp when generating the message BODYSTRUCTURE, it is likely a
   new variant on BODYSTRUCTURE will be necessary that does descend
   message/utf8smtp body parts.  Second, if this type is sent to a
   7-bit-only system, it could be encoded in [RFC2045]....

Note that this applies principally to MTAs which find themselves  
forwarding the message to an environment which does not support 8BITMIME  
[RFC 1652] - I am less concerned what happens at 7-bit MUAs. It is to be  
noted here that the change you have made to RFC 2045 has, as a side  
effect, changed the meaning of RFC 1652, which contains the wording
    "the resulting message must be valid 7bit MIME"
since you have just changed the definition of valid 7bit MIME. This needs  
to be pointed out.


   ........ (Note that a
   system compliant with MIME that doesn't recognize message/utf8smtp
   would treat it as "application/octet-stream" as described in Section
   5.2.4 of [RFC2046].)

But that is simply NOT TRUE.  As has already been pointed out, the wording  
in RFC 2046 regarding the treatment of unrecognized types as  
application/octet-stream was clearly intended, from the way it is worded,  
to apply to end-points such as MUAs, and relates solely to the manner of  
disposition of the unrecognixed type (hence the advice to offer to place  
it in a file). It was never intended to apply to RFC 1652, because any  
current agent adopting that behaviour would be in clear violation of the  
sentence I have quoted (I think we may assume that, in those days, there  
was not the modern distinction between "must" and "MUST").

Now if it were shown to be the case that a substantial part of the  
currently installed MTAs did in fact violate RFC 1652 (and hence RFC 2045)  
in that way, then I might well be persuaded to take a different view of  
the matter. But in actuallity there is not a shred of evidence for such  
current practice. I am not aware of a single current MTA that would treat  
a message/utf8smtp in that fashion, whereas several examples have been  
pointed out that will not. Therefore the bald words you have written
   "a system compliant with MIME that doesn't recognize message/utf8smtp  
would treat
   it as "application/octet-stream"
are quite out of order.

   ......... Alternatively, SMTP servers and other systems
   which transfer a message/utf8smtp body part MAY choose to down-
   convert it to a message/rfc822 body part using the rules described in
   [EAI-downgrading].


But, on a more cheerful note, I am glad to see that last sentence.

AFAICS, this matter can be resolved in one of the following ways:

1. Admit up front that current MTAs may fail to handle a message/utf8smtp  
when forwarding it to a non-8BITMIME system, and that this is considered  
an acceptablle risk during the experiment on the grounds that non-8BITMIME  
systems are exceedigly rare nowadays.

2. State that current agents MAY encode a message/utf8smtp in the manner  
you have suggested, or alternatively they MAY "just send 8bits", or  
alternatively they MAY bounce them (not much use if the Return-Path is  
'<>'), or finally they MAY downgrade them to message/rfc822 (but an agent  
smart enough to do that would likely be giving full UTF8SMTP support  
anyway).

3. Define a REQUIRED downgrade from message/utf8smtp to message rfc822  
before the message leaves the UTF8SMTP environment.

4. Revert to to one of the earlier suggestions to use an application type  
or to use message/rfc822 rather than message/utf8smtp.

BUT, if the matter cannot be resolved in one of those ways, or in yet some  
other way, then I give notice that I shall raise a Formal Objection at  
IETF Last Call.

--
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