Subject: draft-crocker-email-arch-13 (was: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard)

From: John C Klensin <[email-masked]>
Date: Sat, 16 May 2009 00:12:52 -0400

Comment on new text introduced into -13.  The text in a new
bullet in 6.3 says

> o MIME's [RFC2045] and [RFC2046] allow for the transport of
> true multimedia material, which has obvious applicability
> to internationalization.

It is not obvious at all.  MIME does three things:

	(i) It changes the email model from "message plus
	attachment" to multiple body parts.
	
	(ii) It provides a way to label textual messages with
	character set and language information.
	
	(iii) It provides a way to handle multimedia content.

These three are really independent of each other in the sense
that any one of them  without the other two.  Absent one of the
originally-anticipated uses of multipart/alternative, which has
never taken off for that use, the first is much more closely
related to the third than  the second and is, indeed, almost
irrelevant to the second.  

The assertion of obviousness is also unnecessary.  The
provisions in MIME for identification of charset and language
are, very specifically, internationalization provisions.  The
necessary and sufficient text for the bullet item is simply
something like

	o MIME [RFC2045] provides for the identification of
	coded character set ("charset") information and, if
	desired, language information, which directly support
	internationalization.

In addition, the last bullet reads 

>  o POP and IMAP do not introduce internationalization issues.

If that were true, the EAI work would not require special
specifications and treatment for POP or IMAP.

And, finally on this subject, with those three new bullets, the
"Hence" at the beginning of the last paragraph of that section
no longer makes sense, if it ever did.

    john

p.s. It is incorrect to infer from my willingness to try to help
with this document and correct either the type of small errors
identified earlier or the larger ones identified above that I
have dropped my broader and more conceptual objections to the
document or to advancing it onto the standards track.

---

From: [email-masked]
Date: Sat, 16 May 2009 07:23:25 -0700 (PDT)

> It is not obvious at all.

Excuse me? If it isn't obvious that a potential use of multimedia formats is
for internationalization, I don't know what is. The ability to send audio,
video, formats with mulltiple tracks, etc. etc. all have _obvious_ applications
to internationalization.

	
	
> 	(iii) It provides a way to handle multimedia content.

But the text is specifically only talking about the third at this point, so
what else MIME can do isn't relevant.

> The assertion of obviousness is also unnecessary.

Perhaps, but it is obvious, so the assertion has the virtue of accuracy.

> The

> 	desired, language information, which directly support

I agree that mention of this capability of MIME is necessary, but it is not
suffficient. And the text you have here is also technically incorrect - a coded
character set is simply an ordered set of characters, which is NOT sufficient
to specify a charset.

> specifications and treatment for POP or IMAP.

Er, not exactly. The inability of our current address format to handle
internationalized characters is what creates internationalization issues, not
the POP or IMAP protocols. The EAI work has seen fit to address this by
changing the message format in a way that then requires changes and additions
to all sorts of stuff, including but not limited to POP and IMAP. But POP and
IMAP did not introduce this issue, RFC 822 et al. did.

I therefore believe this statement is true, although perhaps given the lack of
any viable alternativce to the EAI approach it could be considered to be a
vacuous truth. Perhaps rewording this to say something along the lines of:

"POP and IMAP have no difficulties with handling MIME messages, including ones
containing 8bit, and therefore are not a source of of internationalization
issues."

> no longer makes sense, if it ever did.

Agreed - the "hence" is superfluous and should go.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sat, 16 May 2009 12:59:11 -0400

--On Saturday, May 16, 2009 07:23 -0700 Ned Freed
<[email-masked]> wrote:

> Excuse me? If it isn't obvious that a potential use of
> multimedia formats is for internationalization, I don't know
> what is. The ability to send audio, video, formats with
> mulltiple tracks, etc. etc. all have _obvious_ applications to
> internationalization.

Unless one proposes to say that the availability of such media
and that fact that they can be used to transmit non-English
materials is an application to internationalization, I don't
think the link is obvious.   And, if one does say that, I
suggest it is almost equivalent to saying that one doesn't
really need non-ASCII character set encoding if image data
(etc.) can be used to transmit images of the relevant other text.

If the document is trying to say what I infer from the above
that you believe it means, I suggest avoiding assertions about
obviousness (which are, I believe, a matter of perspective and
opinion) and say instead something like:

	o MIME [RFC2045] and [RFC2046] allows for the transport
	of true multimedia material.  Such material enables
	internationalization because it is not restricted to any
	particular language or locale.

I think, given your explanation, that is approximately what was
intended, but it does not make the reader make an inference
about the meaning.

The slight editorial change (from "MIME's ... allow" to "MIME
... allows" is a matter of taste, but I believe the existing
form is confusing because 2045 and 2046 define parts of MIME
rather than being something that MIME owns.   A different
formulation would be

	o In [RFC2045] and [RFC2046], MIME allows for the
	transport of true multimedia material.  Such material
	enables internationalization because it is not
	restricted to any particular language or locale.

Per Alexey's note, I believe that this could reasonably have
been left to the RFC Editor and would not have mentioned it had
I not been suggesting a rewrite to the bullet point for other
reasons.

> But the text is specifically only talking about the third at
> this point, so what else MIME can do isn't relevant.

Not the way I read it.  That bullet is one among six.  As a
collection, they are fairly wide-ranging.   One could make the
intention of separate topics and capabilities clear by, e.g.,
changing the bulleted list to an indented one with short titles
that identified the capability groupings.
 
>...
 
> Perhaps, but it is obvious, so the assertion has the virtue of

Ned, whatever our positions on it from a 10K meter perspective,
I think many (probably most) of us are tired of iterating on
this document.  That tiredness may be contributing to
differences of opinion about what will be clear and/or obvious
and/or well-explained (and what will not be) to a first-time
reader who does not already have a deep understanding of
Internet mail.  In the case of this relatively new i18n section,
I'm reading it admittedly quickly and through the lens of
spending most of my time lately (both inside and outside the
IETF) on i18n issues.   Perhaps if I were less immersed, or more
immersed, the reading you get would be obvious to me.  But it
wasn't when I read it yesterday. 

When I see "obvious" used in this way, I expect that to be true
for all readers no matter how little exposure they have to the
material.  Otherwise, it conjures up all of the old jokes about
stopping a proof part way with "left as an exercise for the
reader", "remaining steps are obvious and trivial", and so on.

And, fwiw, I am willing to suggest alternate text that
accomplishes the same thing without making that assertion and
have done so above.  I am not being deliberately obstructive
here-- I want to see the document published and I am trying to
make it better for what I assume is the intended audience.

> I agree that mention of this capability of MIME is necessary,
> but it is not suffficient. And the text you have here is also
> technically incorrect - a coded character set is simply an
> ordered set of characters, which is NOT sufficient to specify
> a charset.

You are, of course, correct about charsets.  Having reread the
entire section this morning, that suggested paragraph is also
completely unnecessary -- the topic is covered adequately (and
more accurately) in the first bullet.  FWIW, I do think the
section could be made slightly more clear by ordering or
grouping the bullet points so that all of the MIME material
comes together, e.g., that the "multimedia" bullet point should
not be separated from the other MIME material by the EAI one.
But that is probably just a matter of taste.

> Er, not exactly. The inability of our current address format
> to handle internationalized characters is what creates
> internationalization issues, not the POP or IMAP protocols.
> The EAI work has seen fit to address this by changing the
> message format in a way that then requires changes and
> additions to all sorts of stuff, including but not limited to
> POP and IMAP. But POP and IMAP did not introduce this issue,
> RFC 822 et al. did.

That is correct ("obviously" so).  As with the above, I think we
are being a little too terse here because, while the sentence is
strictly true as written, I believe that a casual reader might
infer that it implies that no changes to POP or IMAP are needed
for internationalization.   Even that inference is true until
one starts to put internationalized characters in addresses.

> I therefore believe this statement is true, although perhaps
> given the lack of any viable alternativce to the EAI approach
> it could be considered to be a vacuous truth. Perhaps
> rewording this to say something along the lines of:
> 
> "POP and IMAP have no difficulties with handling MIME
> messages, including ones containing 8bit, and therefore are
> not a source of of internationalization issues."

I typed out a different formulation, but this one works for me.

>...

     john

---

From: [email-masked]
Date: Sat, 16 May 2009 10:05:58 -0700 (PDT)

> 	particular language or locale.

That seems like reasonable text to me and I fully support using it
instead of what's there now.

> I typed out a different formulation, but this one works for me.

Good enough then.

				Ned

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 17 May 2009 07:24:55 +0900

>>>It is not obvious at all.

It's actually wrong.

Considering that 7bit e-mail was already internationalized by ISO
2022, which can encode all the characters in the world in 7 bit, as
exemplified by RFC1468, RFC1554 and RFC1557, supporting Japanese,
Korean and non-Latin European character sets with 7bit, which can
be carried over RFC821/RFC822 environment, 8bit support of MIME has
nothing to do with the internationalization.
 
>	restricted to any particular language or locale.

You badly confuse language, character encoding and characters.

MIME does enable 8 bit encoding. However, all the characters in
the world can be transported in 7 bit over RFC821/RFC822.

Language has nothing to do with 7/8 bit differentiaiton.

The text should be:

   o MIME's [RFC2045] and [RFC2046] allow for the transport of
   8bit characters and binary data, which has obvious applicability
   to true multimedia material.

						Masataka Ohta