<[EMAIL PROTECTED]> wrote: > The email architecture documeent is needed now and shouldn't > have to wait for any of this.
The text I've proposed just offers a pointer to the existing RFC 4952, nothing extravagant like assuming that 2822upd will be ready before email-arch, or missing normative references for EAI will be trivial, e.g., mailing-lists => mailto-eai => mailto-bis is a chain with a very difficult mailto-bis step. Not mentioning EAI at all in the I18N considerations would be odd. FWIW my proposal also covers "euclidean MIME" RFC 2231, RFC 1869, BCP 15, RFC 3282, STD 63, and BCP 47. Of course it depends on what folks reading email-arch actually expect. If email-arch is for email what TAObis or roadmap are for the IETF, then it should offer the most relevant references for all important aspects of the architecture, the 7bit or 8bit or Unicode aspect is important, many RFCs tried to tackle it, and there will be more (not limited to EAI). If readers try to find out how email really works, starting with the fundamental concepts of "route" vs." "MX", then I can only hope that they read 821/822 first, then 1123, after that 2821bis or (2)822(upd) or email-arch could make sense. IMO email-arch is more a FYI than standards track. The lack of an explanation for "border MTA" is a problem, and there is no way to solve it (in this memo). Back to EAI: >> For one (= ignoring an "expressly forbidden") I think it >> is actually only a subtle error in RFC 2045. > I'm well aware of this issue, and I disagree completely with > your chararacterization of this as a "subtle error". Well, I went as far as a *request* for external review by the unknown MIME expert cited in a mail by John on the EAI list, and that boils down to "could please one of Ned / Keith / ... confirm that EAI got it right". > The fact of the matter is that nested encodings were > extremely contentious issue at the time MIME was created > and we were well aware of the consequence - both short and > long term - of including this restriction. It was quite > simply the only possible path forward. > It may be that the time has come to remove the restriction. > Or it may not. But no matter how it plays out, the reality > is that without this restriction MIME would not have made it > out in a usable form. Yes, so far it is clear, and as you probably know from some USEFOR debates I like MIME 1.0 so much that I even considered "euclidean MIME" RFC 2231 as suspicious. And fortunately you told USEFOR in time what you think about "non-euclidean" MIME with name=value1; name=value2 instead of name="value1 value2", no matter how ugly the effect is for values in quoted strings. > This choice is therefore a lot of things, some of them not > especially nice, but "subtle error" isn't even close to > being on the list. If you think that "expressly forbidden" in RFC 2045 is still state of the art also for message subtypes EAI has a problem. And the "subtle error" ends up in RFC 2046, where the message subtypes explicitly specify which CTEs are okay, and multipart subtypes have an overall rule, reflecting the 2045 "expressly forbidden" rule <http://article.gmane.org/gmane.ietf.ima/2150> s/subtle error/obvious inconsistency/ if that is clearer. The EAI folks convinced me that their solution should be acceptable and that 2045 slightly exaggerated the intentions for message/* in comparison with multipart/*. [UTF-8 in MIME part headers] > It could go either way, alrhough my guess is the real issues > with EAI will turn out to be things none of us anticipate now. ACK, actually I don't care too much about the odd UTF-8 in MIME part headers of MIME version 1.0, of course it is wrong, but so what, saying version 1.2 (1.1 is a secret for "euclidean MIME") could be a worse idea. I am worried about the *definition* of messasge/global requiring MTAs to parse the MIME structure: If MTAs look for trouble they will find trouble, and it is not my fault if some embedded MIME structures have syntax errors. Looking at the message header instead of the complete structure should suffice to identify a message/global. > For example, I'm very concerned about how EAI will interact > with existing antispam mechanisms. A widespread conflict in > this regard could render it effectively undeployable. No serious conflict with RFC 4408, and for RFC 4871 both sides apparently decided to ignore each other for now. Admittedly I was perplexed that folks spend time on EAI instead of trying to "solve" the spam problem first, OTOH they'd likely have to wait forever otherwise. > none of this is in any way relevant to the matter at hand, > which is getting the email architecture document done and > out the door. Without "border MTA" I can't do much with it in discussions on the SPF list, a glossary and overview. I'll stick to MON and MRN and envelope sender address when it better expresses what I mean. > You may believe that holding up this document in order to > get EAI into it makes sense, but I quite simply disagree. I don't believe this, I only answered the question what to put in the I18N consideration. And if the author prefers to ignore RFC 2277 that is his decision. I like Harald's wild 50 years master plan (still 40 years to go until UTF-8 will be the only charset, according to RFC 2277 ;-) Frank -- <http://omniplex.blogspot.com/2008/02/patch-that-zeppelin.html>
