Re: draft-crocker-email-arch-13 (was: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard)
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-crocker-email-arch-13 (was: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard)
--On Saturday, May 16, 2009 07:23 -0700 Ned Freed ned.fr...@mrochek.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. 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
draft-crocker-email-arch-13 (was: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard)
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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
