ietf
[Top] [All Lists]

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

2009-05-16 10:45:40
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.

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.

  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.

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.

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
issues."

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.

                                Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf