Subject: [EAI] Name of new mesage/ subtype

From: John C Klensin <[email-masked]>
Date: Thu, 07 Jun 2007 05:00:15 -0400

Hi. 

There is an hypothesis that we should be using a new content
subtype for message/ to identify body parts whose headers may
contain UTF-8 material, if only to provide a specific message/
subtype that can be used (by extension of the MIME spec) with a
content-transfer-encoding.  At least some of us have concluded
that modifying MIME to permit a C-T-E on _any_ message/ subtype,
or even any message/subtype defined in RFC 2045/2046 is a bad
idea, especially in an experimental protocol.   

For those who still believe that message/rfc822 is appropriate
or that an application/ subtype should be used, please either
ignore this message or suspend disbelief long enough to get
through it and determine if you want to respond.  If you are
then going to comment other than to address the question, please
change the subject line.

The question of a rigorous definition for the body part that
conforms to the requirements of RFC 4288/4289 is also a separate
topic.

The WG has been informally using the terms message/utf8 or
message/utf8smtp to refer to this body part.  Neither is
satisfactory (at least IMO).   UTF-8 is a charset and having a
charset as a subtype seems likely to be confusing and unwise.
And, since this is a body part subtype, it really has nothing to
do with SMTP.

Proposals made in a brief design team brainstorming session
included:
   message/i18n
          /international
          /intl
and
          /global
plus "wait for an RFC number and parallel message/rfc822".  This
last one appears to be impractical for several reasons,
including experimental implementations before an RFC is
published and a number assigned, issues that would arise if
changes arose between experimental and standards-track
publication, and the general undesirability of having a
long-surviving reference to an Experimental document (RFC 822
was considered to be an Internet Standard before MIME came
along).

Other suggestions welcome: the WG needs to decide and the name
should be one that will come to mean something to users (since
they will inevitably hear about and refer to it) and not cause
confusion with other names and concepts.

    john

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 07 Jun 2007 14:34:27 +0100

> idea, especially in an experimental protocol.

Does "some of us" includes you? It is certainly the main reason why I am  
still arguing for message/rfc822.

> conforms to the requirements of RFC 4288/4289 is also a separate

I find it hard to discuss this new message subtype in the absence of any  
clear description of its properties - particularly as to whether, how and  
when it gets downgraded (first to 8BITMIME and then to 7bit). A rigorous  
definition would be fine, but even an informal definition would help. In  
comparison with that, the name by which it is to be called seems like a  
minor issue.
> message/utf8smtp to refer to this body part.

Which, as a working name, is fine for now. Agreed something better is  
needed before it get deployed.

> Proposals made in a brief design team brainstorming session

Of those, i18n is the best, but it still lacks any suggestion that this is  
for all objects in an email-like format. Maybe 'i18n-mail'.

> plus "wait for an RFC number and parallel message/rfc822".

Please not. RFCs regularly get changed as standards get upgraded.  
Message.rfc822 already made that mistake. Do not repeat it.

-- 
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: Andrew Sullivan <[email-masked]>
Date: Thu, 7 Jun 2007 11:08:53 -0400

>           /global

I like this idea, but I don't like the names (especially i18n, which
is perhaps not confusing to those already familiar with the shorthand,
but will undoubtedly be completely mysterious to
non-geeklish-speakers).  I haven't come up with a better idea that
doesn't suggest character sets in some way (/notascii, for example),
though, so I decalre support for /international.

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: Yuri Inglikov <[email-masked]>
Date: Thu, 7 Jun 2007 08:37:21 -0700

I18n is no more misterious than rfc822. In fact, there is a benefit in being "mysterious", as people avoid associating meaning and making assumptions which can be incorrect. OTOH, what about message/mail, or message/email? Internationalization is a momentary term, which will not be interesting ten years from now - it is just one of a "properties" of new e-mail format. Or, alternatively, what about message/rfc822u ?

> -----Original Message-----
> From: Andrew Sullivan [mailto:[email-masked]]
> Sent: Thursday, June 07, 2007 8:09 AM
> To: [email-masked]
> Subject: Re: [EAI] Name of new mesage/ subtype
>

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 7 Jun 2007 12:33:29 -0400

On Thu, Jun 07, 2007 at 08:37:21AM -0700, Yuri Inglikov wrote:

> I18n is no more misterious than rfc822. 

This is true, but I'm not sure that an argument from the obscurity of
one name is a reason to prefer another obscure name.

> In fact, there is a benefit
> in being "mysterious", as people avoid associating meaning and
> making assumptions which can be incorrect. 

On that basis, perhas we should prefer /xyzzy :)

A

---

From: Bill McQuillan <[email-masked]>
Date: Thu, 7 Jun 2007 09:59:11 -0700

> for all objects in an email-like format. Maybe 'i18n-mail'.

Doesn't "message/" imply email-like?

Also, I like "/global" since it seems more inclusive and it would feel
natural for all messages even if they had nothing but ascii in the header
and body. I don't like anything with "mail" in it since I would hope that
this format would not be restricted to e-mail.

-- 
Bill McQuillan <[email-masked]>

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Jun 2007 13:01:56 -0400

> I18n is no more misterious than rfc822.

Yes, but, as Andrew points out, it is sort of a geek
abbreviation.  And if pronounced message/internationalization,
rather than message/i18n, it is grammatically strange.   I
could, however, live with it.

> In fact, there is a
> benefit in being "mysterious", as people avoid associating
> meaning and making assumptions which can be incorrect.

That implies a completely made-up word (string), which no one
has proposed one of yet.

> OTOH,
> what about message/mail, or message/email?

To me, odd but possible.

> Internationalization is a momentary term, which will not be
> interesting ten years from now - it is just one of a
> "properties" of new e-mail format. Or, alternatively, what
> about message/rfc822u ?

I think that the term/concept "rfc" is sufficiently well-known,
at least in the specialist community, that anything starting
with "rfc" followed by one or more digits, had better be one,
regardless of what follows the digits.  Otherwise, people are,
e.g., going to go off to RFC822 looking for the "u" option.

   john

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Jun 2007 13:06:29 -0400

--On Thursday, 07 June, 2007 14:34 +0100 Charles Lindsey
<[email-masked]> wrote:

>> subtype that can be used (by extension of the MIME spec) with
>> a content-transfer-encoding.  At least some of us have
>> concluded that modifying MIME to permit a C-T-E on _any_
>> message/ subtype, or even any message/subtype defined in RFC
>> 2045/2046 is a bad idea, especially in an experimental
>> protocol.
> 
> Does "some of us" includes you? It is certainly the main
> reason why I am still arguing for message/rfc822.

Yes, it includes me.  But, having changed my mind at least once
about this, I don't consider my opinion to be particularly
important.  And I was trying to present, rather than persuade.

>...
> Which, as a working name, is fine for now. Agreed something
> better is needed before it get deployed.

The longer these things persist as "temporary" usage, the more
likely they are to become permanent just because the people
working on or discussing the specs have gotten use to them.

> Of those, i18n is the best, but it still lacks any suggestion
> that this is for all objects in an email-like format. Maybe
> 'i18n-mail'.

Yes, that one, one i18n-email (with or without the hyphen)
should have been on the list -- I was just too fuzzy when I
wrote the note to remember (I plead 2AM Jabber chats as an
excuse).
 
> Please not. RFCs regularly get changed as standards get
> upgraded. Message.rfc822 already made that mistake. Do not
> repeat it.

Speaking personally, I agree.  

   john

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 08 Jun 2007 08:48:34 +0200

> Proposals made in a brief design team brainstorming session
of these, message/global is the one I dislike the least.

---

From: Martin Duerst <[email-masked]>
Date: Fri, 08 Jun 2007 15:43:03 +0900

>          /global

What about message/eai ? I'm sceptical about the above proposals
because even with message/rfc822, I can send any kind of message,
international or global or not. The two main new things, as far
as I understand them, are i18n addresses and raw use of UTF-8,
and it would be better in my view if the naming took that into
account. As a consequence, I wouldn't exclude message/utf8, either.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 08 Jun 2007 09:08:41 +0200

>Proposals made in a brief design team brainstorming session

I am not fond of the idea to make such entities something "special", be
that "international", "global", or anything else. message/mail, /e-mail,
/smtp, /smtp8, /eai, or something else less suggestive would be better.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Philip Guenther <[email-masked]>
Date: Fri, 8 Jun 2007 01:37:13 -0600

On Fri, 8 Jun 2007, Martin Duerst wrote:
> What about message/eai ? I'm sceptical about the above proposals because 
> even with message/rfc822, I can send any kind of message, international 
> or global or not. The two main new things, as far as I understand them, 
> are i18n addresses and raw use of UTF-8, and it would be better in my 
> view if the naming took that into account. As a consequence, I wouldn't 
> exclude message/utf8, either.

I agree.  The other existing message subtypes seem to describe what they 
contain, but the suggestions John lists seem to be more about intended 
applicability.  What is the point of the new subtype: to contain messages 
which may have non-ascii UTF-8 addresses.  "message/eai" is the only 
suggestion I've seen so far that mentions--albeit indirectly--addresses at 
all.  While "message/utf8" raises the spector of other charsets getting in 
on the act, it does at least have a correct basis: the header *is* in 
UTF-8.

Philip Guenther

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 8 Jun 2007 15:48:03 +0800

----- Original Message ----- 
From: "Philip Guenther" <[email-masked]>
To: "Martin Duerst" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, June 08, 2007 3:37 PM
Subject: Re: [EAI] Name of new mesage/ subtype

> which may have non-ascii UTF-8 addresses.  "message/eai" is the only 

how about message/utf8eai?

YAO Jiankang
CNNIC

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 08 Jun 2007 10:40:11 +0100

------- Forwarded message -------
From: "Bill McQuillan" <[email-masked]>
To: "IMA Discussion" <[email-masked]>
Subject: Re: [EAI] Name of new mesage/ subtype
Date: Thu, 07 Jun 2007 17:59:11 +0100

Are all the currently registered message types email-like? Message/CPIM  
for example? Or message/http?

I will accept that most people believe that news is email-like.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 11 Jun 2007 11:34:15 +0100

>account. As a consequence, I wouldn't exclude message/utf8, either.
I don't like message/global, as it sounds ambiguous.
I am Ok with message/i18n, message/international, message/eai or 
message/utf-8.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 11 Jun 2007 12:10:57 +0100

> account. As a consequence, I wouldn't exclude message/utf8, either.

But in that case you want something more explicit, such as  
message/utf8-headers or message/utf8-email.

Though the first might be confused with a DSN returning headers only :-( .

---

From: Yangwoo Ko <[email-masked]>
Date: Tue, 12 Jun 2007 09:44:51 +0900

I am in favor of message/eai because this message type is a result of 
eai WG effort.

I have mixed feelings with message/utf8. It means to me that, unlike 
i18n or global,  we do not prevent any other internationalization of 
email from being explored, which can be good and bad news.

---

From: John C Klensin <[email-masked]>
Date: Mon, 11 Jun 2007 20:50:22 -0400

--On Tuesday, June 12, 2007 09:44 +0900 Yangwoo Ko 
<[email-masked]> wrote:

> I am in favor of message/eai because this message type is a
> result of eai WG effort.

Remember that "EAI" was chosen for the WG name/ abbreviation 
only because "IMA" had been used for something else.  It is not 
a particularly good name, although I could certainly live with 
it.

> I have mixed feelings with message/utf8. It means to me that,
> unlike i18n or global,  we do not prevent any other
> internationalization of email from being explored, which can
> be good and bad news.

In particular, I fear that it would encourage (non-standard and 
possibly non-registered) use of
   message/utf-32
   message/Latin-1
   message/Klingon-666

And so on.  It is not the character set that is the issue here.

      john

---

From: Yangwoo Ko <[email-masked]>
Date: Tue, 12 Jun 2007 10:03:48 +0900

John C Klensin wrote:
>
>
>
> --On Tuesday, June 12, 2007 09:44 +0900 Yangwoo Ko <[email-masked]>
> wrote:
>
> Remember that "EAI" was chosen for the WG name/ abbreviation only
> because "IMA" had been used for something else. It is not a
> particularly good name, although I could certainly live with it.
>

I also share this fear.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 12 Jun 2007 11:03:25 +0900

At 09:50 07/06/12, John C Klensin wrote:
>
>
>--On Tuesday, June 12, 2007 09:44 +0900 Yangwoo Ko <[email-masked]> wrote:
>
>Remember that "EAI" was chosen for the WG name/ abbreviation only because "IMA" had been used for something else.  It is not a particularly good name, although I could certainly live with it.

We definitiely could also make it message/ima.

>In particular, I fear that it would encourage (non-standard and possibly non-registered) use of
>   message/utf-32
>   message/Latin-1
>   message/Klingon-666
>

Well, the two issues are raw utf-8 in headers and non-ASCII characters
in email addresses. The former is clearly the means that was choosen
for achieving the later.

Regards,    Martin.

---

From: SM <[email-masked]>
Date: Tue, 12 Jun 2007 22:43:25 -0700

>We definitiely could also make it message/ima.

How about message/intl-email ?

The subtype is somewhat more descriptive about the content.

Regards,
-sm

---

From: Kari Hurtta <[email-masked]>
Date: 20 Jun 2007 21:52:34 +0300

> important.  And I was trying to present, rather than persuade.

And updating RFC 2045 for allowing  C-T-E does not really help.

On UTF8SMTP environment this is not needed.

And outside of UTF8SMTP environment it can not be assumed that this
change is known.   Therefore that is not compatible.

Saying that 8BITMIME -> 7bit downgraders can encode  message/
does not work. 

8BITMIME -> 7bit downgraders do not know that they are allowed to
to encode message/utf-8-future. It does not help that specification
of message/utf-8-future updates RFC 2045.  8BITMIME -> 7bit downgraders 
knows only original RFC 2045 specification where is this famous 
"EXPRESSLY FORBIDDEN".

( This does not prevent using message/utf-8-future inside of
  UTF8SMTP environment. )

/ Kari Hurtta