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

[John C Klensin <klensin at jck.com>]

--On Friday, 22 June, 2007 08:15 +0200 Harald Alvestrand
<harald at alvestrand.no> wrote:

> The questions below are not unrelated; the poll is intended to
> show strong preferences, it is not a replacement for informed
> debate.
> 
> 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.
> B: Yes.
> C: I have another opinion, which is....

B

> 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.
> B: No, that should not be allowed.
> C: I have another opinion, which is....

A.  Not completely satisfactory, but all other options proposed
so far have been worse.

> QUESTION 3: Should the new type be a subtype of Message/?
> 
> A: Yes
> B: No, it should be application/something
> C: I have another opinion, which is....

A.   I think that having it as an application/ subtype would
violate the principle of least astonishment and that, in the
long term, people would wonder why we took leave of our sanity.

> QUESTION 4: What should the new MIME type be called?
> 
> A: Message/utf8smtp
> B: Message/i18n
> C: Message/international
> D: Message/global
> E: Message/rfcxxxx (to be assigned)
> F: Message/rfc822 (consistent with an "A" answer on question 1)
> G: Message/utf8
> H: Message/rfc822u
> I: Message/mail
> J: Message/i18n-email
> K: Message/eai
> L: Message/smtp
> M: Message/smtp8
> N: Message/utf8eai
> O: Message/utf8-headers
> P: Message/utf8-email
> Q: Message/ima
> R: Message/intl-email
> S: I have another opinion, which is....

I agree with Chris's "technically flawed" list.  I would add G
to that list: I believe that is technically flawed -- this is
about formats and mail handling, not about a character set, and
would introduce confusion with the charset parameter on
text/plain.  I also believe that G invites mischief.  Also like
Chris, I find E and H aesthetically unattractive (in part
because, while I understood the reasons -- which do not apply
here-- I believe that "message/rfc822" was a mistake the first
time around).

That leaves me with some preference for C or I although I'm not
wild about any of these.  I could easily live with D or some
contraction of "international" that is not on the list (e.g.,
message/intl).   

As I think more about it, the more appeal "I" has.  If one
performs the experiment of pretending to be some years in the
future, with this work widely deployed, message/mail would seem
fairly natural.  It conveys the impression that the
internationalized case is the normal one, with message/rfc822
being the restricted case for those poor backward types who
haven't caught up yet.  That, it seems to me, is exactly what we
want.  Message/mail also connects with some of my aesthetic
objection to many of the other ideas, which stress that this is
an extension rather than the [long-term] normal case.    On that
theory, if message/mail is problematic for some reason,
message/email or message/netmail or message/imail (for Internet
mail, not "international") would be alternatives in the same
spirit. (For those who don't know but still care, as Mike
Padlipsky regularly points out, "'netmail' is what we called
this stuff when we were inventing it".)

      john



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