Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
John C Klensin wrote: Hi. This is a tiny nit, but, since -13 has not yet been posted... A few of the references list organizations and not authors as authors and should probably be fixed.[RFC5335] sort of leapt out at me. A quick scan also turned up [RFC1652], but I have not done a comprehensive check for others. John, I think RFC Editor can handle these. ___ 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)
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: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
Hi Dave, At 08:33 15-05-2009, Dave CROCKER wrote: The text is not normative and is providing the historical chain of development for transfer and content specifications. If you want to provide the historical chain of development, you'll have to start with RFC 1341 for MIME. Mail routing is covered in RFC 974. There's also RFC 1123 which updates or annotates portions of RFC 821 to conform to current usage (at that time). RFC 1123 discouraged all source routing and tried to abolish explicit source routing for mail delivery. The words for Originator are posting and submits. Send is a different word. It is commonly used in a variety of ways, some rather vague. As shown in Figure 2, there really is a logical connection between Author and Recipient. Referring to the use of that connection as sending to a Recipient. One of the key points behind a layered architecture like this is that these higher-level, logical, end-to-end relationships are primary. Author and Recipient perceive themselves as sending to each other. They mostly don't perceive all the underlying mechanism. The paragraph is about the basic test of Gateway design. At the higher level, they may be a perception that the author is sending a message to the recipient. But we are not operating at that level as the section is about gateways. The end points are the sender (in your draft the Originator fits in there) and the recipient. We are looking at the connection between these points where a change in addressing, for example, isn't required for the message to get through. H. Ok. Since the cited specifications do say 'label', I've switched the text to say that, although I personally view 'names' as more helpful to the reader. That would have been helpful for a less technically inclined audience. Section 4.1.4, Table 1? Yes. The Author, not the Originator, defines the body. MIME structuring and labeling is defining the body. It is very much *not* the job of the Originator, which has more clerical duties. We are talking about the Message Body here. That should not be confused with the message content (what the recipient views and not the raw message. My use of the word content may not be technically correct). MIME structuring is not really part of the content from the author's perspective if the author and originator are not the same person. It's up to the originator to see that the message conforms to Internet Mail standards (Section 2.2.1 of the draft). RFC 5321, Section 4.4: When the delivery SMTP server makes the final delivery of a message, it inserts a return-path line at the beginning of the mail data. RFC 5322, Section 3.6.7 -Trace Fields: A full discussion of the Internet mail use of trace fields is contained in [RFC5321] As usual, it is indeed confusing to have redundant definitions in two different specifications. Happily, here, one makes clear the other is the controlling spec for this item. Your comment elicited a smile. :-) You mentioned RFC 5322, Section 3.6.7 which references RFC 5321 to explain trace fields. The draft references RFC 2505 for trace information. So email-arch does have an error, here, but it's the opposite of what you note. Now fixed. This brings us back to the document conventions used in the draft where the first part of a structured field cites the specification for the field. RFC 5322 has a registration for Return-Path in the Permanent Message Header Field Names registry. The Received header field registration references both RFC 5321 and RFC 5322. It needs to be normative. At the beginning of your reply, you said that the text with a reference to RFC 2821 and RFC 2822 is not normative. In the draft STD 10 and STD 11 are Informational references. Regards, -sm ___ 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
Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
On 5/16/09 5:28 PM, SM wrote: If you want to provide the historical chain of development, you'll have to start with RFC 1341 for MIME. Mail routing is covered in RFC 974. There's also RFC 1123 which updates or annotates portions of RFC 821 to conform to current usage (at that time). RFC 1123 discouraged all source routing and tried to abolish explicit source routing for mail delivery. I think Dave is aware of that as he was in the room when that text was written (I was one of the people writing it). Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-crocker-email-arch-13
John C Klensin wrote: 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. It's actually wrong. Considering that 7bit e-mail was already internationalized by ISO 2022, which can encode all the characters in the world in 7 bit, as exemplified by RFC1468, RFC1554 and RFC1557, supporting Japanese, Korean and non-Latin European character sets with 7bit, which can be carried over RFC821/RFC822 environment, 8bit support of MIME has nothing to do with the internationalization. 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. You badly confuse language, character encoding and characters. MIME does enable 8 bit encoding. However, all the characters in the world can be transported in 7 bit over RFC821/RFC822. Language has nothing to do with 7/8 bit differentiaiton. The text should be: o MIME's [RFC2045] and [RFC2046] allow for the transport of 8bit characters and binary data, which has obvious applicability to true multimedia material. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf