Charles Lindsey wrote: > fixing the problem I shall describe would have repercussions in > draft-ietf-eai-smtpext-11.txt [EAI-SMTP-extension] and in > draft-ietf-eai-dsn-06.txt [EAI-dsn] > (especially the latter), it should be construed as a formal > objection to those as well. [procedural nit] IMO it is slightly beside the point to dispute the right to start a "Last Call". If it doesn't get out of hand ADs can "Last Call" whatever and whenever they like. Figuring out what the community wants before stating what the consensus is is the purpose of this exercise, a good reason for objections could be when the alleged consensus is dubious. [technical] Of course the EAI drafts to varying degrees depend on each other, but I'm confident that UTF8SMTP (the SMTP extension) makes sense, therefore I posted a draft with a normative UTF8SMTP reference yesterday, <http://tools.ietf.org/html/draft-ellermann-spf-eai>. >From my POV the DSN draft is also in excellent shape. I'd like it better to reference BCP 137, because the DSN draft ended up with using an in theory problematic "unicode escape", but that's perfectionism, at best an editorial nit. > my concern is that a new MIME subtype message/global is > defined, and that this new message subtype is in breach > of RFC2045, which currently has the status of Draft Standard. I strongly support to introduce message/global, an EAI message is *NOT* an ordinary US-ASCII message/rfc822, an EAI message uses UTF-8 "as is" in its header. Simplified message/global vs. message/rfc822 is like IRI vs. URI, or IDNAbis vs. LDH, and it is very important to have these differences clear. Taking the message/global idea as given the details of its definition are indeed fascinating. I had a long chat with Ned (the co-author of RFC 2045) some days ago on the SMTP list in a thread about "I18N considerations" for the email-arch draft, mostly we discussed message/global and the history of MIME, see <http://thread.gmane.org/gmane.ietf.smtp/6678/focus=6697> Highly recommended for reading, I dare not summarize it here. > I have no problem with defining extensions to RFC 2822 and > even to RFC204[56] (e.g. to permit UTF-8 in places where > those current documents do not allow it). I'd prefer to stay away from MIME, for the job at hand (EAI) it is unnecessary to "embrace and extend" MIME version 1.0. There are "only" two places in the EAI drafts where MIME is touched: 1 - The use of a "nested" CTE B64 if all else fails to send DSNs to an EAI sender with a 7bit bit hop on the route. 2 - The use of UTF-8 in MIME version 1.0 part headers, this can require to parse the MIME structure of a message to figure out if it's a message/global or a message/rfc822, instead of only looking at the message header. I'm concerned about (2), different from your concerns. And I considered (1) as negligible, maybe a 2045 erratum. Nobody - now also including Ned - liked my erratum idea, admittedly it was formalistic, it would be "editorial", not "technical". [...skipping your problem description...] > I might well agree that that restriction is unfortunate and > misguided, and even that it ought to be changed. But RFC2045 > is a Draft Standard, and it is entirely outside the remit of > the EAI WG to attempt to change what is in a Draft Standard. Oddly you don't have this problem with (1), and I don't have it with (2). For both issues I think they could be fixed in MIME, and I don't insist on an erratum or 2045bis for (2), or on a MIME versin 1.1 for (1). And for you issue (= my 2) it might be precisely the purpose of an "IETF experiment" to see if it works out in practice. I could say the same about (1), but I'd hate it if (1) turns out to be critical and kills the EAI effort, because (1) is not really necessary to experiment with "Email Address I18N". Arguably (2) is also not really necessary, but Ned told me that application/message ideas to solve this problem are old and never made it, and without something in the direction of application/message (2) is necessary. Somehow those DSNs to an EAI sender with 7bit hops on the return path must make it. This should be a rare situation, what does an old 7bit relay do on the return path to an UTF8SMTP sender, and accepting it as given oddity all UTF8SMTP senders can be expected to know how to "unpack" a B64 message/global part in a DSN. Of course the security considerations need to be very clear. B64 message/global is not designed for forward paths, it is no ersatz-downgrading, it is a loophole for rare cases where the alternative would be to drop DSNs. > Furthermore, if the interpretation of RFC2046 Section 5.2.4 > suggested in [EAI-utf8header] is correct, it follows that > RFC2046 is inconsistent with RFC2045. Inconsistency between > two Draft Standards is a serious matter, but one which is > to be resolved by the IESG rather than by an individual WG > such as EAI. For my purposes I "resolved" it in a discussion about I18N in email-arch. I didn't know that apparently technical details in MIME were actually results of "political" decisions at the time when 204[56] were published (1996, twelve years ago). Frank _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf