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: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
At 05:27 13-04-2009, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Internet Mail Architecture ' draft-crocker-email-arch-12.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the In the Introduction section: The underlying technical standards for Internet Mail comprise a rich array of functional capabilities. The specifications form the core: * Simple Mail Transfer Protocol (SMTP) [RFC0821], [RFC2821], [RFC5321] moves a message through the Internet. * Internet Mail Format (IMF) [RFC0733], [RFC0822], [RFC2822], [RFC5321] defines a message object. RFC 733 was obsoleted by RFC 822. Section 2.2.1 of the draft defines the Originator as: The Originator ensures that a message is valid for posting and then submits it to a Relay. In Section 2.2.3: The basic test of Gateway design is whether an Author on one side of a Gateway can send a useful message to a Recipient on the other side, without requiring changes to any components in the Author's or Recipient's mail services other than adding the Gateway. As it is the Originator doing the submission, Author should be replaced by Originator in the above paragraph. In Section 3.4 of RFC 5322, it is mentioned that: A mailbox receives mail. It is a conceptual entity that does not necessarily pertain to file storage. Section 3.1 of the draft has: A mailbox sends and receives mail. It is a conceptual entity which does not necessarily pertain to file storage. [RFC5322] In Section 3.3 of the draft: The name is structured as a hierarchical sequence of names, separated by dots (.), with the top of the hierarchy being on the right end of the sequence. There can be many names in the sequence -- that is, the depth of the hierarchy can be substantial. Section 3.1 of RFC 1035 uses sequence of labels instead of sequence of names. Section 4.4 of the draft mentions that the the MIME Header is set by the Author. It should be the Originator as that is done when the message is submitted. RFC5321.ORCPT: Set by - Author. This is an optional parameter to the RCPT command, indicating the original address to which the current RCPT TO address corresponds, after a mapping was performed during transit. An ORCPT is the only reliable way to correlate a DSN from a multi- recipient message transfer with the intended recipient. Table 1 lists ORCPT as being set by the Originator. As the RcptTo is at the SMTP layer, it might be more appropriate to have it Set By the Originator instead of the Author. RFC5321.Return-Path: Set by - Originator The MDA records the RFC5321.MailFrom address into the RFC5322.Return-Path field. The RFC5321.Return-Path looks like a typo. It should be RFC5322.Return-Path and it is Set by the MDA according to the Table 1. RFC 2298 is obsoleted by RFC 3798. There is a typo (RFC 2304) in the reference for RFC3192. If the author of the draft wants to reference RFC 2821 and RFC 2822, he could make it an Informative reference instead of a Normative reference. The author of MAIL-I18N mentioned that the document should not be referenced in a modern architecture document. Regards, -sm ___ 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
(just in time for shipping the final version for IESG consideration after Last Call...) SM wrote: In the Introduction section: The underlying technical standards for Internet Mail comprise a rich array of functional capabilities. The specifications form the core: * Simple Mail Transfer Protocol (SMTP) [RFC0821], [RFC2821], [RFC5321] moves a message through the Internet. * Internet Mail Format (IMF) [RFC0733], [RFC0822], [RFC2822], [RFC5321] defines a message object. RFC 733 was obsoleted by RFC 822. The text is not normative and is providing the historical chain of development for transfer and content specifications. Section 2.2.1 of the draft defines the Originator as: The Originator ensures that a message is valid for posting and then submits it to a Relay. In Section 2.2.3: The basic test of Gateway design is whether an Author on one side of a Gateway can send a useful message to a Recipient on the other side, without requiring changes to any components in the Author's or Recipient's mail services other than adding the Gateway. As it is the Originator doing the submission, Author should be replaced by Originator in the above paragraph. 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. In Section 3.4 of RFC 5322, it is mentioned that: A mailbox receives mail. It is a conceptual entity that does not necessarily pertain to file storage. Section 3.1 of the draft has: A mailbox sends and receives mail. It is a conceptual entity which does not necessarily pertain to file storage. [RFC5322] fixed. thanks. In Section 3.3 of the draft: The name is structured as a hierarchical sequence of names, separated by dots (.), with the top of the hierarchy being on the right end of the sequence. There can be many names in the sequence -- that is, the depth of the hierarchy can be substantial. Section 3.1 of RFC 1035 uses sequence of labels instead of sequence of names. 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. Section 4.4 of the draft mentions that the the MIME Header is set by the Author. It should be the Originator as that is done when the message is submitted. Section 4.1.4, Table 1? 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. RFC5321.ORCPT: Set by - Author. This is an optional parameter to the RCPT command, indicating the original address to which the current RCPT TO address corresponds, after a mapping was performed during transit. An ORCPT is the only reliable way to correlate a DSN from a multi- recipient message transfer with the intended recipient. Table 1 lists ORCPT as being set by the Originator. fixed. As the RcptTo is at the SMTP layer, it might be more appropriate to have it Set By the Originator instead of the Author. The Legend for Table 1 notes: Set By - The actor role responsible for specifying the identifier value (and this can be different from the actor that performs the fill-in function for the protocol construct) Again referring to the logical view, Authors send to Recipients. Authors specify Recipients. The underlying mechanism that populates the RcptTo SMTP command is following a choice made by the Author. RFC5321.Return-Path: Set by - Originator The MDA records the RFC5321.MailFrom address into the RFC5322.Return-Path field. The RFC5321.Return-Path looks like a typo. It should be RFC5322.Return-Path and it is Set by the MDA according to the Table 1. 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. So email-arch does have an error, here, but it's the opposite of what you note. Now fixed. RFC 2298 is obsoleted by RFC 3798. fixed. There is a typo (RFC 2304)
Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
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 ___ 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
John C Klensin wrote: This is a tiny nit, but, since -13 has not yet been posted... Thanks. Since the latest draft has been modified to respond to your recent observations about internationalization and the role of an architecture document I'm glad to see that your concerns are reduced to these few typos. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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
FYI, Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-crocker-email-arch-13 and the usual pretty stuff (and diff) are at: http://bbiw.net/recent.html#emailarch d/ Original Message Subject: New Version Notification for draft-crocker-email-arch-13 Date: Fri, 15 May 2009 19:57:43 -0700 (PDT) From: IETF I-D Submission Tool idsubmiss...@ietf.org To: dcroc...@bbiw.net A new version of I-D, draft-crocker-email-arch-13.txt has been successfuly submitted by Dave Crocker and posted to the IETF repository. Filename:draft-crocker-email-arch Revision:13 Title: Internet Mail Architecture Creation_date: 2009-05-15 WG ID: Independent Submission Number_of_pages: 54 Abstract: Over its thirty-five year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants must work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. The IETF Secretariat. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
I support this version of the document. Tony Hansen t...@att.com The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Internet Mail Architecture ' draft-crocker-email-arch-12.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-05-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This is a second IETF LC on the document, after the author has addressed most of the issues raised during the first IETF LC. Please see http://tools.ietf.org/rfcdiff?difftype=--hwdiffurl2=http://tools.ietf.org/id/draft-crocker-email-arch-12.txt for the list of changes. In particular note that the Internationalization section has been updated. The file can be obtained via http://www.ietf.org/internet-drafts/draft-crocker-email-arch-12.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=11811rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Internet Mail Architecture ' draft-crocker-email-arch-12.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-05-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This is a second IETF LC on the document, after the author has addressed most of the issues raised during the first IETF LC. Please see http://tools.ietf.org/rfcdiff?difftype=--hwdiffurl2=http://tools.ietf.org/id/draft-crocker-email-arch-12.txt for the list of changes. In particular note that the Internationalization section has been updated. The file can be obtained via http://www.ietf.org/internet-drafts/draft-crocker-email-arch-12.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=11811rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
Ned Freed writes: But that's the problem - this is not what RFC 5321 says. It's not what 3501 says either ;) More of a one-sentence simplification than a full and exact description. ... SMTP server do stuff like expand lists all the time. For those tests to be done competently some amount of interpretation of local parts may be needed, such as ignoring the possibility that the local part is case sensitive. Oh, this makes sense. I wasn't aware of that. I ran into the same issue whem implementing group reply in a MUA, but hadn't realised that MTAs could run into that. While there may not be any conflict between RFC 3501 and RFC 5321 since they deal with separate components, the fact remains that there's a conflict between what real world implementations do and what RFC 5321 says must not be done. I agree with that. Email-arch, however, deals with both, and attempts to describe the running code too, so IMO it can't just cite 5321. That would be overly simplistic. Arnt ___ 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
s...@resistor.net writes: If there isn't an authoritative reference and there are differences in semantics or syntax between the draft and RFC5321/5322 or future revisions of these documents, it can lead to serious issues. Standards Track documents are around years. The documents may be edited by different authors as they get updated. Errors can happen; the documents can diverge. In my opinion, it is better to clarify that now or else we will end up having discussions ten years from now to determine which interpretation is correct or which standard to follow. So. RFC 3501 (page 50-51), says that the localpart of a From: address is matched case-insensitively when IMAP servers process SEARCH or UID SEARCH commands. RFC 5321 says that SMTP servers process localparts case-sensitively. Both rules go back essentially unchanged to very old RFCs. Do we need to discuss which is correct or which standard to follow? I fail to see any conflict. Arnt ___ 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
s...@resistor.net writes: If there isn't an authoritative reference and there are differences in semantics or syntax between the draft and RFC5321/5322 or future revisions of these documents, it can lead to serious issues. Standards Track documents are around years. The documents may be edited by different authors as they get updated. Errors can happen; the documents can diverge. In my opinion, it is better to clarify that now or else we will end up having discussions ten years from now to determine which interpretation is correct or which standard to follow. So. RFC 3501 (page 50-51), says that the localpart of a From: address is matched case-insensitively when IMAP servers process SEARCH or UID SEARCH commands. RFC 5321 says that SMTP servers process localparts case-sensitively. Both rules go back essentially unchanged to very old RFCs. But that's the problem - this is not what RFC 5321 says. It says: Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address. SMTP server do stuff like expand lists all the time. For those tests to be done competently some amount of interpretation of local parts may be needed, such as ignoring the possibility that the local part is case sensitive. Now, if RFC 5321 instead said that interpretation of local parts MUST be limited to comparison operations, and local parts MUST NOT be modified, the problem mostly goes away. (There are probably still some odd corner cases left for gateways, but after thinking about it some more I think we can ignore those.) Do we need to discuss which is correct or which standard to follow? I fail to see any conflict. I have to disagree. While there may not be any conflict between RFC 3501 and RFC 5321 since they deal with separate components, the fact remains that there's a conflict between what real world implementations do and what RFC 5321 says must not be done. 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
At 20:21 01-03-2009, Dave CROCKER wrote: As this draft is being considered as a Proposed Standard, will it be authoritative instead of RFC 5821/5322? This presumes that there are different semantics or syntax offered by them. I'm replying to this point separately so that it does not get confused with the rest of my comments. If there isn't an authoritative reference and there are differences in semantics or syntax between the draft and RFC5321/5322 or future revisions of these documents, it can lead to serious issues. Standards Track documents are around years. The documents may be edited by different authors as they get updated. Errors can happen; the documents can diverge. In my opinion, it is better to clarify that now or else we will end up having discussions ten years from now to determine which interpretation is correct or which standard to follow. Regards, -sm ___ 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
For the content that overlaps in RFC5322 and RFC5321, which one is authoritative? d/ SM wrote: At 20:21 01-03-2009, Dave CROCKER wrote: As this draft is being considered as a Proposed Standard, will it be authoritative instead of RFC 5821/5322? This presumes that there are different semantics or syntax offered by them. I'm replying to this point separately so that it does not get confused with the rest of my comments. If there isn't an authoritative reference and there are differences in semantics or syntax between the draft and RFC5321/5322 or future revisions of these documents, it can lead to serious issues. Standards Track documents are around years. The documents may be edited by different authors as they get updated. Errors can happen; the documents can diverge. In my opinion, it is better to clarify that now or else we will end up having discussions ten years from now to determine which interpretation is correct or which standard to follow. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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
On Mon Mar 2 15:49:09 2009, Dave CROCKER wrote: For the content that overlaps in RFC5322 and RFC5321, which one is authoritative? Whichever is cited by the document referencing the content, of course. Alternately, we could have a public food fight between Klensin, Resnick, and Crocker. If this does happen in SF, can someone ensure it gets filmed for posterity? Thanks, Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ 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
Dave Cridland wrote: On Mon Mar 2 15:49:09 2009, Dave CROCKER wrote: For the content that overlaps in RFC5322 and RFC5321, which one is authoritative? Whichever is cited by the document referencing the content, of course. That sounds pretty unstable, since it produces context-dependent resolution. Alternately, we could have a public food fight between Klensin, Resnick, and Crocker. If this does happen in SF, can someone ensure it gets filmed for posterity? Pete usually has too much class to engage in these, publicly. John and I get into public food fights all the time, using food for thought. We're in the middle of one now, on these same lists, and I have to tell you, it's neither pretty nor interesting. Save your film. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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
At 20:21 01-03-2009, Dave CROCKER wrote: What inconsistencies are you seeing, specifically, so we can fix them. email-arch Section 2.2.2 The Relay performs MHS-level transfer-service routing and store-and- forward, by transmitting or retransmitting the message to its Recipients. The Relay adds trace information [RFC2505] but does not modify the envelope information or the message content semantics. It can modify message content representation, such as changing the form of transfer encoding from binary to text, but only as required to meet the capabilities of the next hop in the MHS. RFC 5321 Section 2.3.10: A relay SMTP system (usually referred to just as a relay) receives mail from an SMTP client and transmits it, without modification to the message data other than adding trace information, to another SMTP server for further relaying or for delivery. The draft says that a relay can modify message content representation whereas RFC 5321 says that a relay does not do any modification to the message data other than adding trace information. Regards, -sm ___ 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
At 20:21 01-03-2009, Dave CROCKER wrote: What inconsistencies are you seeing, specifically, so we can fix them. email-arch Section 2.2.2 The Relay performs MHS-level transfer-service routing and store-and- forward, by transmitting or retransmitting the message to its Recipients. The Relay adds trace information [RFC2505] but does not modify the envelope information or the message content semantics. It can modify message content representation, such as changing the form of transfer encoding from binary to text, but only as required to meet the capabilities of the next hop in the MHS. RFC 5321 Section 2.3.10: A relay SMTP system (usually referred to just as a relay) receives mail from an SMTP client and transmits it, without modification to the message data other than adding trace information, to another SMTP server for further relaying or for delivery. The draft says that a relay can modify message content representation whereas RFC 5321 says that a relay does not do any modification to the message data other than adding trace information. Another place where RFC 5321 is at odds with reality, I'm afraid. MIME downgrading is the obvious example where relays alter message content and such alterations are explicltly condoned by other standards. The customary fig leaf we try and draw over this is that systems that perform such alterations are gateways, not relays. But this particular fig leaf has gotten awfully small and thin over time. In any case, this is one where I think the email-arch document is right, RFC 5321 is wrong, and we should fix RFC 5321. 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
Maybe Dave you should add an Updates tag to your draft? Eliot On 3/2/09 5:26 PM, ned+i...@mauve.mrochek.com wrote: At 20:21 01-03-2009, Dave CROCKER wrote: What inconsistencies are you seeing, specifically, so we can fix them. email-arch Section 2.2.2 The Relay performs MHS-level transfer-service routing and store-and- forward, by transmitting or retransmitting the message to its Recipients. The Relay adds trace information [RFC2505] but does not modify the envelope information or the message content semantics. It can modify message content representation, such as changing the form of transfer encoding from binary to text, but only as required to meet the capabilities of the next hop in the MHS. RFC 5321 Section 2.3.10: A relay SMTP system (usually referred to just as a relay) receives mail from an SMTP client and transmits it, without modification to the message data other than adding trace information, to another SMTP server for further relaying or for delivery. The draft says that a relay can modify message content representation whereas RFC 5321 says that a relay does not do any modification to the message data other than adding trace information. Another place where RFC 5321 is at odds with reality, I'm afraid. MIME downgrading is the obvious example where relays alter message content and such alterations are explicltly condoned by other standards. The customary fig leaf we try and draw over this is that systems that perform such alterations are gateways, not relays. But this particular fig leaf has gotten awfully small and thin over time. In any case, this is one where I think the email-arch document is right, RFC 5321 is wrong, and we should fix RFC 5321. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ 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
ned+ietf-s...@mrochek.com wrote: At 20:21 01-03-2009, Dave CROCKER wrote: What inconsistencies are you seeing, specifically, so we can fix them. email-arch Section 2.2.2 The Relay performs MHS-level transfer-service routing and store-and- forward, by transmitting or retransmitting the message to its Recipients. The Relay adds trace information [RFC2505] but does not modify the envelope information or the message content semantics. It can modify message content representation, such as changing the form of transfer encoding from binary to text, but only as required to meet the capabilities of the next hop in the MHS. RFC 5321 Section 2.3.10: A relay SMTP system (usually referred to just as a relay) receives mail from an SMTP client and transmits it, without modification to the message data other than adding trace information, to another SMTP server for further relaying or for delivery. The draft says that a relay can modify message content representation whereas RFC 5321 says that a relay does not do any modification to the message data other than adding trace information. Another place where RFC 5321 is at odds with reality, I'm afraid. MIME downgrading is the obvious example where relays alter message content and such alterations are explicltly condoned by other standards. Which ones? With middle ware? The customary fig leaf we try and draw over this is that systems that perform such alterations are gateways, not relays. But this particular fig leaf has gotten awfully small and thin over time. +1. In any case, this is one where I think the email-arch document is right, RFC 5321 is wrong, and we should fix RFC 5321. -1. I hate middle ware, passthrus, relays, routers, what have you, that alter the original mail integrity. It should be against the law. hmm, in fact, if push came to shove there might be some legal (US) precedence for such mail tampering claims. I know society has been molded to believe that we can SNIFF transmissions, but alterations within a homogeneous network should not be encourage, nor tolerated. Be very careful to [further] open Pandora's Box here. -- Sincerely Hector Santos http://www.santronics.com ___ 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
On Mon Mar 2 16:05:16 2009, Dave CROCKER wrote: Dave Cridland wrote: On Mon Mar 2 15:49:09 2009, Dave CROCKER wrote: For the content that overlaps in RFC5322 and RFC5321, which one is authoritative? Whichever is cited by the document referencing the content, of course. That sounds pretty unstable, since it produces context-dependent resolution. It is unstable, yes, but I'm not convinced that's a bad thing - it's stable per document, at least. What it means is that if a document says Relay (as defined in [MAIL-ARCH]), or a more generic and sweeping Terms are as defined in [MAIL-ARCH], then it's absolutely obvious which definition is being used, and if there is doubt, the reference can be checked. That the terms differ is, of course, important to resolve in and of itself, but I'm not clear that a definition of a term - which *will* need a citation and reference anyway - needs to have a particular definition set in stone right here and now. To get consensus behind a single definition requires rather a lot of work, and one simple method of finding the consensus (if one exists) is to have two definitions out there and see which is cited in practise. Alternately, we could have a public food fight between Klensin, Resnick, and Crocker. If this does happen in SF, can someone ensure it gets filmed for posterity? Pete usually has too much class to engage in these, publicly. John and I get into public food fights all the time, using food for thought Yes, well those aren't half as much fun. Don't use food for thought, use custard pies. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ 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
At 07:49 02-03-2009, Dave CROCKER wrote: For the content that overlaps in RFC5322 and RFC5321, which one is authoritative? There are several possible answers: 1. The author of the draft chooses the email-arch draft 2. The author of the draft chooses RFC 5321 and RFC 5332 3. Have the people listed in the author field for these documents make the choice 4. The author of the draft makes a choice based on the Last Call comments 5. Leave it to the IESG to decide 6. Ignore the question Regards, -sm ___ 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
At 10:10 26-02-2009, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Internet Mail Architecture ' draft-crocker-email-arch-11.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the Some of the terms in the draft are also used in RFC 5321/5322 which are on the Standards Track :- email-arch Section 2.1: The Author is responsible for creating the message, its contents, and its list of recipient addresses. RFC 5322 Section 3.6.2: The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. email-arch Section 2.2.2 The Relay performs MHS-level transfer-service routing and store-and- forward, by transmitting or retransmitting the message to its Recipients. The Relay adds trace information [RFC2505] but does not modify the envelope information or the message content semantics. It can modify message content representation, such as changing the form of transfer encoding from binary to text, but only as required to meet the capabilities of the next hop in the MHS. RFC 5321 Section 2.3.10: A relay SMTP system (usually referred to just as a relay) receives mail from an SMTP client and transmits it, without modification to the message data other than adding trace information, to another SMTP server for further relaying or for delivery. email-arch Section 2.2.3: A Gateway is a hybrid of User and Relay that connects heterogeneous mail services. Its purpose is to emulate a Relay and the closer it comes to this, the better. A Gateway operates as a User when it needs the ability to modify message content. RFC 5321 Section 2.3.10: A gateway SMTP system (usually referred to just as a gateway) receives mail from a client system in one transport environment and transmits it to a server system in another transport environment. Differences in protocols or message semantics between the transport environments on either side of a gateway may require that the gateway system perform transformations to the message that are not permitted to SMTP relay systems. As this draft is being considered as a Proposed Standard, will it be authoritative instead of RFC 5821/5322? In Section 1.2 of the draft, RFC2822.From and RFC2821.MailFrom are used to refer to structured fields of a message. I prefer Header.From and SMTP.MailFrom as it doesn't require any changes if RFC 5321 and RFC 5322 are updated. There was a similar discussion about the replacement for message/rfc822 in the EAI Working Group. In the Security Considerations Section (6.1): As mentioned in Section 4.1.4, it is common practice for components of this architecture to use the [RFC0791].SourceAddr to make policy decisions [RFC2505], although the address can be spoofed. As the focus of the draft is email architecture, this doesn't fit under security considerations. Regards, -sm ___ 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
SM wrote: As this draft is being considered as a Proposed Standard, will it be authoritative instead of RFC 5821/5322? This presumes that there are different semantics or syntax offered by them. What inconsistencies are you seeing, specifically, so we can fix them. Again, we should note that 5322 and 5321 have their own redundancies and opportunities for inconsistencies. Would that Postel and I had coordinated better for 821/822, but alas we didn't. At the time, I thought we did, but it's been clear for a long time that we didn't. I remember wondering about that at the time, but certainly had no concept of the long-term hassles it would cause. Kinda makes one appreciate the benefit of being more careful. We probably should have taken another 10 or 15 years to figure it out... In Section 1.2 of the draft, RFC2822.From and RFC2821.MailFrom are used to refer to structured fields of a message. I prefer Header.From and SMTP.MailFrom as it doesn't require any changes if RFC 5321 and RFC 5322 are updated. There was a similar discussion about the replacement for message/rfc822 in the EAI Working Group. As I recall, the choice of rfc#. versus acronym. or std#. was discussed during development of the draft. Perhaps separately, but it has come up in recent years. From what I've seen, folks generally seem to prefer using the RFC number. Personally, I'd prefer acronym#, although the other side of not having to make changes when there's a new RFC is not being sure whether the meaning has changed... In the Security Considerations Section (6.1): As mentioned in Section 4.1.4, it is common practice for components of this architecture to use the [RFC0791].SourceAddr to make policy decisions [RFC2505], although the address can be spoofed. As the focus of the draft is email architecture, this doesn't fit under security considerations. Email-arch discusses implications in various places. From what I've seen, the IETF's security geeks vastly prefer having extra Security Considerations, rather than missing important ones. And in terms of advising the community about security holes in email, more is definitely better. So I'd rather see this tidbit retained. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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
More than a +1: it is about time we got this out. For example, we would like to reference a document like this in the LEMONADE series of documents. That said, this particular document is well written, gets the point across, and does the job nicely. Of course, we could hold up publication for another three months, just so it can be an even five years since Dave submitted -00 :-( On Feb 26, 2009, at 4:06 PM, Eliot Lear wrote: Lisa, I think this document is fairly well written, and I would support its publication. Eliot On 2/26/09 9:59 PM, Lisa Dusseault wrote: FYI -- Forwarded message -- From: The IESGiesg-secret...@ietf.org Date: Thu, Feb 26, 2009 at 10:10 AM Subject: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard To: IETF-Announceietf-annou...@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Internet Mail Architecture ' draft-crocker-email-arch-11.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-crocker-email-arch-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=11811rfc_flag=0 The following IPR Declarations may be related to this I-D: ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Apps-Discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ___ Apps-Discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Shouldn't the document reference RFC5321 and RFC5322 instead of the older ones? -- Sincerely Hector Santos http://www.santronics.com Dave CROCKER wrote: Folks, After 5 years and 11 public versions, the email-arch document has finally made its way into the formal IETF standardization process, starting with a Last Call for comments from the community. The document is available in several formats from: http://bbiw.net/recent.html#emailarch The HTML and PDF versions include figures that are markedly easier to view than the ASCII art in the (official) txt version... The document is an individual submission. Although many people have contributed to it, it was not the product of a working group. So the IESG cannot presume it has support. Hence, the Last Call of an individual submission carries an extra burden, to assess the amount of support that the document has from the community. This requires affirmative postings from the community. However verbose or terse, positive or negative, it will aid the IESG's assessment to see postings from you about whether to make Internet Mail Architecture an IETF standard. In particular, note the enclosed announcement's: Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-26. Thanks. d/ Original Message Subject: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard Date: Thu, 26 Feb 2009 10:10:17 -0800 (PST) From: The IESG iesg-secret...@ietf.org Reply-To: ietf@ietf.org To: IETF-Announce ietf-annou...@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Internet Mail Architecture ' draft-crocker-email-arch-11.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-crocker-email-arch-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=11811rfc_flag=0 The following IPR Declarations may be related to this I-D: ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ 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
Since this is a substantive comment on a document that is in Last Call for Standards Track, I'm posting the note to the IETF list. Since I use different addresses for the SMTP list and the IETF one, I don't know when or if this will appear on the latter. With the exception of the last point, this note addresses Section 6.3 of this document (on Internationalization) exclusively. I will post another note before the cutoff to address other issues. --On Friday, February 27, 2009 15:49 -0700 J.D. Falk jdfalk-li...@cybernothing.org wrote: Dave CROCKER wrote: Just to make this explicit, SM's note is to the rest of you, not to me. I asked him to solicit comments from the group, since I have only tried to make the document parrot what I8N folk say. My own comprehension of the topic remains muddled. Mine is similarly muddled, but I wonder...is it appropriate to reference a recent (and presumably temporary) experiment alongside documenting the current state of the art? Particularly when email-arch is unlikely to be updated for another five years? Well, while my comprehension may be equally muddled, it isn't for lack of trying and involvement. A few observations: (1) The use of international (non-ASCII) characters in message bodies and content has been a done deal since MIME came in. That should probably be said explicitly. If we were redoing that work today, we would probably strongly recommend the use of UTF-8, rather than alternate encodings, and might require a charset parameter on all instances of text/plain. But no WG has ever been willing to move on either of those two points. (2) Given the requirement for an Internationalization Considerations section, which this document honors with Section 6.3, handing the substance of that section off to an non-consensus document (IMC's Mail-I18N) in what is clearly a normative reference despite being listed as an informative one (the previous sentence has essentially no content other than to indicate that i18n is an ongoing challenge) seems dubious and probably inappropriate. (3) There are some useful things that can be said that are, at this point, settled parts of the architecture or at of least the relevant protocols. As suggested above, one is that the content matter is settled and that UTF-8 is the winner in the character set wars (although other things are certainly around). Another is that work on i18n of email headers and addresses is progressing, but that, until that work completes, IDNs can be expressed in ACE form (with appropriate references). I would personally avoid making anything resembling a normative reference to the experimental documents, largely because they introduce more new syntax and terminology that would then need to be discussed. (4) It is a nit, but Because its origins date back to the use of ASCII leaves an impression that is not strictly correct. It would be accurate to say that its origins date back to the time when even the use of ASCII was controversial. However, the origins have nothing to do with anything: the email architecture of today is defined in ASCII terms. RFCs 5321, 5322, and 2045ff are written in ASCII terms and require ASCII (except in body-part content) as are most of the other protocols referenced. It would be far more accurate to simply say that we have an ASCII-based protocol suite that is gradually being adapted to accommodate non-ASCII elements where those are appropriate, with the current thread and model starting with the introduction of text/ content-types in MIME. (5) The document needs to be updated to reflect current references. In particular, RFCs 5321 and 5322 were published almost six months ago. They also contain some slight adjustments to terminology and this document should be carefully checked to be sure its terminology is still consistent with them. regards, john ___ 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
John, With respect to character set, internationalization, and the like, I cannot tell what text changes you propose for the document. The current text was developed through community discussion. What specific changes are you proposing? s/old/new/ form, or a multiline equivalent, would be most helpful. I suggest that the bulk of any changes really does need to refer to community consensus documents, rather than trying to summarize the topic. d/ John C Klensin wrote: A few observations: ... (3) There are some useful things that can be said that are, at this point, settled parts of the architecture or at of least the relevant protocols. As suggested above, one is that the content matter is settled and that UTF-8 is the winner in the character set wars (although other things are certainly around). Another is that work on i18n of email headers and addresses is progressing, but that, until that work completes, IDNs can be expressed in ACE form (with appropriate references). I would personally avoid making anything resembling a normative reference to the experimental documents, largely because they introduce more new syntax and terminology that would then need to be discussed. (4) It is a nit, but Because its origins date back to the use of ASCII leaves an impression that is not strictly correct. It would be accurate to say that its origins date back to the time when even the use of ASCII was controversial. However, the origins have nothing to do with anything: the email architecture of today is defined in ASCII terms. RFCs 5321, 5322, and 2045ff are written in ASCII terms and require ASCII (except in body-part content) as are most of the other protocols referenced. It would be far more accurate to simply say that we have an ASCII-based protocol suite that is gradually being adapted to accommodate non-ASCII elements where those are appropriate, with the current thread and model starting with the introduction of text/ content-types in MIME. (5) The document needs to be updated to reflect current references. In particular, RFCs 5321 and 5322 were published almost six months ago. They also contain some slight adjustments to terminology and this document should be carefully checked to be sure its terminology is still consistent with them. regards, john -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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
At 8:30 PM -0500 2/27/09, John C Klensin wrote: Instead, it references (given how little text is in the Internationalization section, incorporates by reference might be more accurate) a somewhat-outdated private consortium document that has never had anything resembling formal IETF review. +1. I am slowly going through draft-crocker-email-arch, but when I saw John bring this up, I thought it had to be a mistake. I haven't touched the reference in question in over a decade. (There is no URL for the document in the draft, but it can be found at http://www.imc.org/mail-i18n.html.) For those of you checking your chronometers, that means it predates IDNs, much less EAI. It should not be referenced in a modern architecture document. --Paul Hoffman, Director --VPN Consortium ___ 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
John C Klensin wrote: What specific changes are you proposing? Really, John, whatever folks agree on is more than fine with me. However, I also note that some other experienced IETFers have indicated that they consider it acceptable to leave the text as-is. Please note that besides the terse Section 6.3, the document does duly cite RFC 2045 and RFC 2047, for body and header extensions, in Section 4.1. My own sense of why the current I8N section is so sparse is because the additional capabilities have yet to be all that well established into the service, except for very narrow (albeit useful) exceptions. Since the document seeks to describe what is standardized as accepted practice, that leaves a bit of a hole for I8N details. The incorporation-by-reference done in the draft is an attempt to limit the document's being drawn into a topic that seems to be email's third rail. Since you feel strongly about the document's failings in this regard and since you happen to be a tad more knowledgeable about the topic than I (or most others), what do you want included, *specifically*? Actually, Dave, I can remember no community discussion of the Internationalization section of this document. http://www.imc.org/ietf-smtp/mail-archive/msg04377.html While this document has been kicking around the community for quite a while and gotten comments and input from far more people than are listed in the Acknowledgements, it is an individual I've variously done two or three detailed audits, to find and list the name of every person who made posted a substantive note about any of the email-arch drafts. This of course does not mean that I found everyone who should be listed. I know there are many others who have looked at the document, but if you know of any contributors who are missing from the section, please let me know. the question is is it ready rather than can the author insist that IETF participants put other work aside to do a sufficiently close review of a 49 page document to suggest alternate text that is consistent with other text in the document. First, is it ready sounds like exactly the question that folks responding to the Last Call have been answering. Second, in your own case this document is not exactly being sprung on you without notice. It's been circulated in the ietf-smtp mailing list with 11 revisions over 5 years, including 2 or 3 (or maybe even) four postings that characterized themselves as pseudo Last Call. And as cited above, there was an explicit request for discussion about internationalization last March on that list. And many of those people cited in the Acknowledgments section performed detailed reviews. Since shyness is not one of my failings, you know that anyone with an interest in email technology and standards has had this document intrude on their screen more than once over the last five years -- and I don't mean just folk within the IETF sphere. So it doesn't make sense that you would suggest that there is somehow some sudden demand for review by folks within the email community. I've demonstrated (and will demonstrate further below) that at least this one section is not ready and have suggested what is Now all you have to do is to convince those other folk who feel that the current text in the section is sufficient. Personally, I suspect you'll have an easier time of it if you suggest specific text. (As for making the text consistent with other text in the document I'd be glad to perform that task, given any rough approximation that folks like.) An alternative, if you could get the IESG to agree to it, would be to say, somehow, the Internet's email system is mostly ASCII although various changes have been made and are being made to accommodate non-ASCII strings in appropriate contexts; internationalization is not further discussed in this document. Well that is, indeed, specific text. Are you suggesting it replace the existing Section 6.3 text? Are you seeking support for that replacement from others on the list? For example, [MAIL-I18N] points to RFC 2279, which has been obsolete for more than five years due to a definitional change, What is the superior reference you suggest be used? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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
Dave, I don't think much can be accomplished by an extended debate about our respective points. I've injected my comments into the Last Call bin, you have injected yours. As both of us have pointed out on many other occasions, this is not about seeing how many endorsers one can get. You will probably like some of my more general comments on the document even less. Please at least acknowledge that I am entitled to have those opinions. --On Friday, February 27, 2009 18:52 -0800 Dave CROCKER d...@dcrocker.net wrote: ... Personally, I suspect you'll have an easier time of it if you suggest specific text. (As for making the text consistent with other text in the document I'd be glad to perform that task, given any rough approximation that folks like.) That is a reasonable proposed compromise. I am still concerned that elements of this may be controversial enough that a WG process is really required. Most of those issues have been aired before, especially vis-a-vis terminology that carries highly loaded semantics with it, semantics are are particularly sensitive given various efforts to establish mechanisms for email sender authentication or authorization. I will explain that further in another note, but they are issues that have been raised before. An alternative, if you could get the IESG to agree to it, would be to say, somehow, the Internet's email system is mostly ASCII although various changes have been made and are being made to accommodate non-ASCII strings in appropriate contexts; internationalization is not further discussed in this document. Well that is, indeed, specific text. Are you suggesting it replace the existing Section 6.3 text? What I'm suggesting is that you need to do one of two things: (i) Get community consensus and IESG agreement to explicitly blow off the internationalization issues. I can personally live with that as long as it is done explicitly, either with a just not discussed here statement like the one above or with a forward pointer to a document that may never be written. I note that either one would violate a BCP and some explicit policy statements but that procedural issue is a separate problem. (ii) Write something real for Section 6.3 and put it there. That might start with a trimming and reworking of the IMC document (see Paul's should not be referenced in a modern architecture document comment -- one of the few I18N-related areas in which the two of us are in agreement). Much of the material there is good. Some can just be left out. The references need to be updated and some of the text needs reconsideration in the light of things that have happened in the last decade. I would volunteer to work with you and/or Paul on the rewrite, but I really have to devote all of my internationalization cycles right now to the IDNABIS WG. However, if a revised version of that text were folded into the architecture document and included in a Last Call, that would obviously satisfy my concern about a normative reference to a non-consensus document. Are you seeking support for that replacement from others on the list? No. I am asserting my belief that, without one of the choices above, the document is incomplete and not ready for prime time. I am completely agnostic about which choice is made although I believe that the requirements for a meaningful internationalization session are more comfortably waived for an informational document than for a standards track one. For example, [MAIL-I18N] points to RFC 2279, which has been obsolete for more than five years due to a definitional change, What is the superior reference you suggest be used? A quick glance at the rfc-index, or faking an I-D format for [MAIL-I18N] and pushing it through the reference checker, will quickly point you to RFC 3629, a full Internet Standard. Depending on what else is being said, an additional reference to RFC 5198 might also be relevant. But note that these are references out of [MAIL-I18N] and not the architecture document itself. They are irrelevant if you adopt the first option above and would probably fall out fairly automatically in any extraction of text from, and revision of [MAIL-I18N] for incorporation into the architecture document as suggested in (ii). john ___ 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
The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Internet Mail Architecture ' draft-crocker-email-arch-11.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-crocker-email-arch-11.txt I've reviewed the latest version and it addresses my earlier comments I've sent to Dave Crocker privately. I think it is an important document and it is long overdue for publication. While I can see people asking for improvements forever, I think it is important to publish a snapshot ASAP. ___ 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
The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Internet Mail Architecture ' draft-crocker-email-arch-11.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-crocker-email-arch-11.txt I've reviewed the latest version and it addresses my earlier comments I've sent to Dave Crocker privately. I think it is an important document and it is long overdue for publication. While I can see people asking for improvements forever, I think it is important to publish a snapshot ASAP. +1 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
Tony Hansen wrote: Should it be using RFC5321/RFC5322 instead of RFC2821/RFC2822, such as RFC5322.From instead of RFC2822.From? yes. current draft came out just before the latest RFCs were published. final publication will be revised (and nits fixed -- thanks for the close read.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
