--On Saturday, May 16, 2009 07:23 -0700 Ned Freed
<ned.freed@xxxxxxxxxxx> 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.
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.
> 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.
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.
>...
>> The assertion of obviousness is also unnecessary.
>
> Perhaps, but it is obvious, so the assertion has the virtue of
> accuracy.
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.
>> 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.
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.
>> 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.
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
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf