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

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

--On Tuesday, 14 August, 2007 20:16 +0200 Harald Tveit
Alvestrand <harald at alvestrand.no> 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.
> 
> 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.
>...
> 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



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