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

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 05 Jul 2007 20:51:05 +0200

The poll close on Friday, 12:00 GMT.
Apart from my opinion, all of the opinions listed below have been posted to
the list. Not all respondents responded to all questions.

QUESTION 1: Should there be a new MIME type for UTF8SMTP messages when
carried inside messages in an UTF8SMTP environment?

A: No, message/rfc822 can be used.
   Kari Hurtta (very slight preference)
   Charles Lindsey
B: 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
   Bjoern Hoerhmann
   Andrew Sullivan
   Yoshiro Yoneya
C: I have another opinion, which is....

Based on this result, I am declaring this question closed.

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.

QUESTION 3: Should the new type be a subtype of Message/?

A: Yes
   Harald Alvestrand
   Chris Newman (slight preference)
   John Klensin
   Yangwoo Ko
   Martin Duerst
   Kazunori Fujiwara
   Mao Wei
   Randall Gellens
   Tony Hansen
   Abel Yang
   Andrew Sullivan
   Bjoern Hoehrmann
   Yoshiro Yoneya
B: No, it should be application/something
C: I have another opinion, which is....
   Kari Hurtta
   Charles Lindsey

Based on this result, I am declaring this question closed.

QUESTION 4: What should the new MIME type be called?

On this question, people tended to list "good" and "bad" names, with some
left unmentioned. This is reflected in the reporting format; however, this
format loses distinctions present in the original responses, such as
preferences between the "good" types.

A: Message/utf8smtp
   Good: Martin Duerst, Kazunori Fujiwara, Charles Lindsey, Abel Yang,
Andrew Sullivan
   Bad: Chris Newman, John Klensin
B: Message/i18n
   Good: Yangwoo Ko, Yao Jiankang, Tony Hansen
   Bad: Martin Duerst
C: Message/international
   Good: Chris Newman, Yangwoo Ko, Mao Wei, Randall Gellens, Tony Hansen,
        Jaeyoun Kim
   Bad: Martin Duerst
D: Message/global
   Good: Mao Wei, Randall Gellens, Yao Jiankang, Tony Hansen,
         Jaeyoun Kim
   Bad: Martin Duerst
E: Message/rfcxxxx (to be assigned)
   Bad: Chris Newman, John Klensin, Martin Duerst
F: Message/rfc822 (consistent with an "A" answer on question 1)
   Good: Kari Hurtta
   Bad: Chris Newman, John Klensin, Martin Duerst
G: Message/utf8
   Good: Chris Newman, Abel Yang
   Bad: John Klensin, Martin Duerst
H: Message/rfc822u
   Good: Martin Duerst
   Bad: Chris Newman, John Klensin
I: Message/mail
   Good: John Klensin, Martin Duerst, Randall Gellens
J: Message/i18n-email
   Good: Yangwoo Ko, Martin Duerst, Charles Lindsey, Yao Jiankang, Yoshiro
Yoneya
K: Message/eai
   Good: Yangwoo Ko, Martin Duerst, Kazunori Fujiwara, Tony Hansen,
         Abel Yang
L: Message/smtp
   Bad: Chris Newman, John Klensin, Martin Duerst
M: Message/smtp8
   Good: Martin Duerst
   Bad: Chris Newman, John Klensin
N: Message/utf8eai
   Good: Martin Duerst, Kari Hurtta, Yao Jiankang, Abel Yang
O: Message/utf8-headers
   Good: Martin Duerst, Charles Lindsey
   Bad: Chris Newman, John Klensin
P: Message/utf8-email
   Good: Martin Duerst, Kari Hurtta, Jaeyoun Kim, Yoshiro Yoneya
Q: Message/ima
   Good: Yangwoo Ko, Martin Duerst
R: Message/intl-email
   Good: Martin Duerst, Mao Wei, Charles Lindsey, Yoshiro Yoneya
S: I have another opinion, which is....
   Kari Hurtta (application/utf8-email, message-eai-email,
                application/eai-email)
   Yao Jiankang (message/i-address)

This response doesn't lend itself to a definite conclusion.

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 07 Jul 2007 22:20:17 +0100

> 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: [email-masked]      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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 15 Jul 2007 19:47:36 +0200

--On 7. juli 2007 22:20 +0100 Charles Lindsey <[email-masked]> wrote:

> draft-ietf-eai-utf8headers-06.txt.....

Charles,

you have made these arguments many times. I cannot see that you are 
bringing any argument to the discussion that you have not brought before.
The fact that the great majority of the respondents on this poll responded 
as they did means that they did not find your previous statements 
convincing. Repeating them is not likely to change anyone's minds.

This issue is declared closed.

                 Harald