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 13:10:10


--On Saturday, May 16, 2009 07:23 -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:

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.

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.

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

...

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.

Good enough then.

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