Subject: [EAI] Poll for MIME type - revised schedule and details

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 14 Aug 2007 20:16:48 +0200

Hello folks,

after the discussions both on- and off-list after Chicago, we seem to have 
reached the following conclusions:

- In the list of MIME types, there are people who see actual technical 
issues with the MIME types - some are issues of style ("we don't do things 
that way"), others are issues of perception ("that will make the thing look 
silly in 5 years"), but they are very real issues that we should consider 
carefully.

- In the IETF tradition, we don't do voting - we do do opinion polls, and 
even allow close calls when it is more important to draw a conclusion than 
which one is chosen - but we never do anonymous polls. People are expected 
to stand for their opinions.

- Documented technical issues, where there's consensus that the issue is 
adequately described and merits consideration, always overrule opinions.

Based on this background, the process we will follow is as follows:

- FIRST, we need to have documented the issues perceived with the MIME type 
choice. I'm asking people to do that via mail to the mailing list, between 
now and FRIDAY, AUGUST 17.

- On FRIDAY, AUGUST 17, I will send out a message announcing the poll. This 
will ask you to rank *all* the alternatives for MIME type, reflecting your 
opinion of the technical issues raised on the list - that is, if you think 
an issue is very important, you put *all* the choices that are on one side 
of the issue first, and *all* the choices that are on the other side last.

- On FRIDAY, AUGUST 24, at 0800 GMT, the poll closes. (This chair will be 
away over the weekend, so the final result is unlikely to be announced 
until late the week after. But a week should be long enough for people to 
make up their minds.)
The result will consist of the "best" choice according to a Condorcet 
ranking of the preferences, with a Schultze tie-breaker if necessary, and 
will include the complete record of who-said-what (no secret ballot).

- If the result is acceptable to the WG, we're done. If not, we figure out 
some other way.

Seems OK?

             Harald Alvestrand

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 15 Aug 2007 13:08:31 +0100

On Tue, 14 Aug 2007 19:16:48 +0100, Harald Tveit Alvestrand  
<[email-masked]> wrote:

> Hello folks,
>
> after the discussions both on- and off-list after Chicago, we seem to  
> have reached the following conclusions:
>
> issues with the MIME types - some are issues of style ("we don't do  
> things that way"), others are issues of perception ("that will make the  
> thing look silly in 5 years"), but they are very real issues that we  
> should consider carefully.

I take it this refers to the naming of what has hitherto been known as  
message/utf8smtp, for which purpose the proposed procedure and poll seem  
fine. And also its method of downgrade needs to get covered in the  
downgrade draft.

As you know, I am unhappy about the decision to have such a new message  
type in the first place, but that is a separate matter which will likely  
come up again in IETF Last Call.

I have one further issue related to MIME types. In the current DSN, where  
only the headers are to be returned, the type used in text/rfc822-headers  
(which is required to be in pure ASCII, of course). In the proposed UTF-8  
DSN that type becomes message/utf-8-headers whereas, for consistency with  
the previous practice, one would have expected it to be  
text/utf-8-headers. So why the change? Downgrading of message/* types is  
messy (especially it it involves using encodings such as Q-P or Base64  
which is not supposed to happen, whereas downgrading of text/* types is a  
well understood practice, using Q-P or Base64 as needed). Existing agents  
would automatically apply that encoding to any text type without looking  
any further.

So why not simply use text/utf-8-headers for this job, probably with a  
charset=utf-8 parameter? Indeed, you might even get away with just adding  
a charset parameter to the existing text/rfc822-headers type - I suspect  
many current MUAs would display that correctly without even realizing they  
were doing anything unusual; but that might be considered a step too far.

Perhaps this needs a new Issue number.

-- 
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: John C Klensin <[email-masked]>
Date: Fri, 17 Aug 2007 08:57:42 -0400

--On Tuesday, 14 August, 2007 20:16 +0200 Harald Tveit
Alvestrand <[email-masked]> wrote:

> Hello folks,
> 
> after the discussions both on- and off-list after Chicago, we
> seem to have reached the following conclusions:
> 
> - In the list of MIME types, there are people who see actual
> technical issues with the MIME types - some are issues of
> style ("we don't do things that way"), others are issues of
> perception ("that will make the thing look silly in 5 years"),
> but they are very real issues that we should consider
> carefully.
> 
> - In the IETF tradition, we don't do voting - we do do opinion
> polls, and even allow close calls when it is more important to
> draw a conclusion than which one is chosen - but we never do
> anonymous polls. People are expected to stand for their
> opinions.
> 
> - Documented technical issues, where there's consensus that
> the issue is adequately described and merits consideration,
> always overrule opinions.
> 
> - FIRST, we need to have documented the issues perceived with
> the MIME type choice. I'm asking people to do that via mail to
> the mailing list, between now and FRIDAY, AUGUST 17.
>...
> Seems OK?

Harald, 

While, as you know, I've still got some process concerns, this
is probably close enough to reasonable that I can live with it
if those who "vote" actually express preferences all the way
down as you suggest.

Consistent with your suggestions above, I see the names falling
into three categories.  Let me identify them and then go into
details and examples below.

(1) Names that will encourage incompatible and non-conforming
extensions.

(2) Names that do not appropriately describe what is going on
and, more important, will cause long-term embarrassment by
branding i18n mail permanently as a second-class add-on.  We
should be looking for names that identify email i18n as the
mainstream for Internet mail, with systems that do not support
it as slightly-retarded (obsolete) legacy implementations.

(3) Names that are ok.  As I tried to say in Chicago, I don't
care how we pick among this: a preference ballot is fine, but
some would be a coin-toss or more elaborate random-choice
procedure.

The first two categories are not mutually exclusive: some names
fall into both of them.

Details and examples:

(1) In the MIME types definition, we were careful to make
distinctions between character set identification (properly
placed in "charset=" parameters when they are needed), encoding
and on-the-wire compression methods (properly placed in
Content-Transfer-Encoding (C-T-E)), and actual content types and
name things accordingly.  There are gray areas.  For example, we
have application/zip (or x-zip), rather than
"Content-transfer-encoding: zip" but that was after a long
discussion that hinged, in part, on the observations that "zip"
was 8bit and hence would require additional encoding and that,
while it might be reasonable for a final delivery MTA or the
server-side of a mail access protocol to decode other C-T-Es, it
was probably not reasonable for them to explode zip files.

There is an additional problem for character set designations,
which is that the use of one of them may encourage the use of
others.  For example message/utf8 (or message/utf8foo) might
encourage the non-standard development and deployment of
message/latin1 or message/8859-1 or message/EUC in areas where
those codings are still more popular than Unicode in UTF-8
encoding.

That reasoning and history make message/utf8 and, to a lesser
degree, the strings that contain "utf8", substantively bad
ideas, not just a matter of taste.

(2) As I said in Chicago, I'd like people considering the
various alternatives to think about how someone looking at these
strings a decade from now, when (we assume) the UTF8SMTP
extension and formats will be fully deployed, downgrading will
(almost) never occur, and message/rfc822 will be largely
history.  message/rfc822 has caused confusion as to whether the
messages conform to RFC822 and RFC2822 (or, soon, RFC2822bis).
The IDN WG was promised that "Punycode" --neither the name nor
the format-- would be seen outside the low-level technical
environment, but it leaked in ways that have created confusion
about just what the name refers to as well as some bad jokes
about IETF disrespect for the non-English-speaking community.

Names that contain RFC numbers (which seem to have dropped out
during the initial poll) or present or proposed IETF WG names
seem to me to be problematic in this regard.  Those include
message/eai, message/ima, and, to a lesser extent, strings
containing "eai" or "ima".  There is also some question about
variations of "internationalized" such as message/i18n or
strings containing "i18n": after all, long-term, what other sort
of messages should the be that are not internationalized?  Do we
really want to give long-term special status to ASCII-only email
and acknowledge that status by saying that this non-default form
is somehow transformed or adapted to be i18n (my apologies
non-native speakers of English, but there is a considerable
semantic difference between "internationalized", implying that
some action needed to be taken to get things that way from a
normal base that presumably isn't internationalized and
"international" which is just a statement of what something is)?
Message/international and Message/global are much less
problematic in this regard, at least to my sense of vocabulary.

(3) This is the more or less neutral group.  Of the proposals
that are now on the table (per the discussion in Harald's note
of Friday, 20 July, 2007 08:19 -0700), message/mail appears to
be the neutral choice: at least we are clearly talking about
mail messages, and not, e.g., IM messages or the like.
message/email or message/imail (for Internet mail) seem
equivalent.  As discussed above, message/international or
message/global are probably as good: a little redundant, but not
harmful.

Just my opinion, of course.

    john

---

From: Chris Newman <[email-masked]>
Date: Fri, 17 Aug 2007 12:02:17 -0700

Charles Lindsey wrote on 8/15/07 13:08 +0100:
> charset=utf-8 parameter? Indeed, you might even get away with just adding  a
> charset parameter to the existing text/rfc822-headers type - I suspect  many
> current MUAs would display that correctly without even realizing they  were
> doing anything unusual; but that might be considered a step too far.
>

With my former document author hat on, there were two reasons I switched to 
"message" from "text" for that media type.

First, return-of-headers is primarily useful as a correlation mechanism.  It's 
undesirable for a correlation mechanism to be transformed in a way that might 
break the correlation.  Using a text/* type with a charset=* parameter invites 
such transformation of the charset and makes it unclear what's expected of a 
client that's doing correlation (e.g. would it have to support 
text/international-header for all the charsets mentioned in RFC 2049 for 
minimal MIME compliance?).

Second, message headers are fundamentally content related to a "message". 
After discussing it with other MIME experts, we felt the name 
text/rfc822-headers was probably a design error and it should have been a 
message content type.  So the change was deliberate on that front as well.

The inconsistency between naming of the ASCII and international variants of 
this media type is unfortunate, but I felt it was the lesser of evils.

I agree this should go on the issue list to gauge WG rough consensus on the 
topic.

                - Chris

---

From: Chris Newman <[email-masked]>
Date: Fri, 17 Aug 2007 12:07:29 -0700

For completeness, let me attempt to summarize the three other naming issues 
I've heard discussed in this thread:

4. Using the name of a protocol ("SMTP") in a media type name when that media 
type is likely to be used outside that protocol more often than not (e.g., 
IMAP, POP, webmail, mail stores, MUAs) is misleading about the purpose of the 
media type.

5. The message/rfc822 media type is used for 7-bit news messages today and this 
is part of the original message/rfc822 definition.  Just as it is desirable to 
have one compound type for all message objects that look like 7-bit header mail 
(to avoid lots of subtly different compound types to descend), it is also 
desirable to use one compound type for all message objects that look like utf-8 
header email.  As a result, the term "mail" is somewhat misleading about the 
scope of the media type.  Of course, rfc822 is also misleading and we've lived 
with it.

6. Descriptiveness of name.  It's desirable for the name to have some useful 
meaning to a non-technical user as MIME media types leak into user interfaces.

I don't disagree with any of John's issues, but it's likely the relative weight 
I attach to these five naming issues is different from the relative weight John 
attaches to them.

                - Chris

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 20 Aug 2007 14:42:19 +0100

On Fri, 17 Aug 2007 20:02:17 +0100, Chris Newman <[email-masked]>  
wrote:

> With my former document author hat on, there were two reasons I switched  
> to "message" from "text" for that media type.
>
> First, return-of-headers is primarily useful as a correlation  
> mechanism.  It's undesirable for a correlation mechanism to be  
> transformed in a way that might break the correlation.  Using a text/*  
> type with a charset=* parameter invites such transformation of the  
> charset and makes it unclear what's expected of a client that's doing  
> correlation (e.g. would it have to support text/international-header for  
> all the charsets mentioned in RFC 2049 for minimal MIME compliance?).

OK, so omit the charset parameter, and state up-front that the charset  
MUST be utf-8. Or say that if charset is present it MUST be of the form  
charset=utf-8 (the only advantage of having a charset parameter at all is  
that some existing agents might be kind enough to act on it - but then  
DSNs will normally be sent to people with upgraded MUAs, even if some  
intermediate hop isn't).
>
> Second, message headers are fundamentally content related to a  
> "message". After discussing it with other MIME experts, we felt the name  
> text/rfc822-headers was probably a design error and it should have been  
> a message content type.  So the change was deliberate on that front as  
> well.

It was always am oddity that text/rfc822-headers was used originally, but  
now it is there noone can complain if the new DSNs use  
text/utf8-headers/whatever. The disadvantage of using  
message/rfc822-headers is that some agents will fail to handle it properly  
when downgrading for some non-8BITMIME systems (sendmail will just leave  
it as 8bit, for example). That is hardly robust. But every agent should be  
able to downgrade a text type in that situation.

> I agree this should go on the issue list to gauge WG rough consensus on  
> the topic.

+1

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 20 Aug 2007 11:34:04 -0400

Dear colleagues,

On Mon, Aug 20, 2007 at 02:42:19PM +0100, Charles Lindsey wrote:
> text/utf8-headers/whatever. 

The above strikes me as a strange argument.  It suggests that, because
some wart was selected once in the past, all future warts are
automatically unobjectionable.  Surely that's not something we
believe, is it?

Best regards,
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: Alexey Melnikov <[email-masked]>
Date: Wed, 22 Aug 2007 22:55:28 +0100

John,
May apologies to you (and probably Harald) for the late comment on this 
message.

>ideas, not just a matter of taste.
This is a very convincing argument. Thank you.

>containing "eai" or "ima".
>
I agree regarding use of RFC numbers, but I find eai and ima to be much 
less problematic. Just think they are are acronyms in a long forgotten 
language.
In this respect message/dragon might be just as good ;-).

>  There is also some question about
>of messages should the be that are not internationalized?
>
I agree on this. I also think that MIME is sufficiently 
internationalized (as far as subject and message bodies are concerned, 
so I also fine the label i18n to be somewhat confusing)

>Do we really want to give long-term special status to ASCII-only email
>equivalent.
but I should mention that I somewhat disagree with John on this point. I 
think using any MIME types containing "mail" is bad, because the new 
MIME type is not necessarily limited to email (usenet and SIP might be 
some other places where this will be used eventually).

>  As discussed above, message/international or

---

From: John C Klensin <[email-masked]>
Date: Thu, 23 Aug 2007 06:43:40 -0400

--On Wednesday, 22 August, 2007 22:55 +0100 Alexey Melnikov
<[email-masked]> wrote:

> I agree regarding use of RFC numbers, but I find eai and ima
> to be much less problematic. Just think they are are acronyms
> in a long forgotten language.

I agree that, in some hierarchy of problems, eai and ima are
less problematic than RFC numbers or the equivalent.   And, if
we could be assured that the entities being referenced were
friendly Asian dragons rather than nasty European ones, I would
prefer message/dragon to either one :-)
 
>> strings containing "i18n": after all, long-term, what other
>> sort of messages should the be that are not internationalized?
>> 
> internationalized (as far as subject and message bodies are
> concerned, so I also fine the label i18n to be somewhat
> confusing)

Indeed.

> but I should mention that I somewhat disagree with John on
> this point. I think using any MIME types containing "mail" is
> bad, because the new MIME type is not necessarily limited to
> email (usenet and SIP might be some other places where this
> will be used eventually).

As I have tried to say before, I am not completely happy about
any of the offered choices.   I do not consider "mail" to be a
really good choice, merely one of the less problematic ones.  I
don't know whether I would classify it as better or worse than
"message/dragon" or, given the possible confusion about
dragon-behavior, perhaps "message/dolphin" or "message/penguin".

       john

---

From: Pete Resnick <[email-masked]>
Date: Thu, 23 Aug 2007 13:11:02 -0500

On 8/23/07 at 6:43 AM -0400, John C Klensin wrote:

>>I agree regarding use of RFC numbers, but I find eai and ima to be 
>>much less problematic. Just think they are are acronyms in a long 
>>forgotten language.
>I agree that, in some hierarchy of problems, eai and ima are less 
>problematic than RFC numbers or the equivalent. And, if we could be 
>assured that the entities being referenced were friendly Asian 
>dragons rather than nasty European ones, I would prefer 
>message/dragon to either one :-)

Yeah, I think Alexey has convinced me that "eai" and "ima" belong in 
your category 3: Pretty much neutral.

>>but I should mention that I somewhat disagree with John on this 
>>point. I think using any MIME types containing "mail" is bad, 
>>because the new MIME type is not necessarily limited to email 
>>(usenet and SIP might be some other places where this will be used 
>>eventually).
>
>As I have tried to say before, I am not completely happy about any 
>of the offered choices. I do not consider "mail" to be a really good 
>choice, merely one of the less problematic ones. I don't know 
>whether I would classify it as better or worse than "message/dragon" 
>or, given the possible confusion about dragon-behavior, perhaps 
>"message/dolphin" or "message/penguin".

Again, I'm with Alexey. I consider "mail" *far* worse than "dragon" 
(or "dolphin" or "penguin" for that matter :-) ) simply because it is 
meaningful ("This is a mail message") and at the same time 
meaningless ("This might be a news or other kind of message, and what 
about its 'mailness' distinguishes it from an 'rfc822'?").

I am, however, less worried about the utf8 ones than either John or 
Alexey; I agree that they invite stupidity, but really, utf8-ness is 
what distinguishes these things. Not my number 1 pick though.

I find myself wanting to rate 1-5 on the list, and mark everything 
else as 11. :-/

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102