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
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
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.
But the text is specifically only talking about the third at this point, so
what else MIME can do isn't relevant.
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.
Perhaps, but it is obvious, so the assertion has the virtue of accuracy.
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
o MIME [RFC2045] provides for the identification of
coded character set ("charset") information and, if
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.
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.
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
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.
Agreed - the "hence" is superfluous and should go.
Ietf mailing list