On Wed, 19 Mar 2008 09:32:42 +0100
Frank Ellerman <nobody at xyzzy.claranet.de> said:
>Apologies, I confused (1) and (2):
[...]
>> 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.
Unfortunately, the threading on the ietf@xxxxxxxx archive had got all
screwed up, and you were not replying to the message you thought you were
replying to. Indeed the message you were replying to is listed in the
archive as [no subject] and has no headers. So I have recovered it and
quoted it in full below so that I may answer it. I have copied the
References header from your last message, so this should now get threaded
somewhere in the right place, but since none of the MUAs available to me
allow manual tinkering with References (and, worse, the ietf archives
don't show Message-ID headers at all), I am constructing this message by
hand and will have to send it using sendmail -t :-( .
Anyway, here goes.
Sometime on Mar 19th, (archived as [no subject])
Frank Ellerman <nobody at xyzzy.claranet.de> said:
> Charles Lindsey wrote:
>> 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.
I might not have had any problem with message/global if it had only been
intended to be seen inside the "global sandbox". But, unfortunately it is
expected to be passed around _outside_ that sandbox, on the presently
deployed network and, in spite of some wishful thinking on the EAI WG,
that just will not work (as I showed).
>
>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 read that thread, and it is clear that Ned would take a very dim
view of disobeying that "EXPRESSLY FORBIDDEN", especially any attempt to
do so on the existing network. It may, with hindsight, have been the wrong
decision, but it is there and that is what lots of agents have
implemented. Moreover, as I showed at the start of this thread, even RFC
2046 does not permit what EAI is trying to do (yes, there is a sentence
about treating unknown stuff as application/octet-stream, but the very
next sentence following that makes it clear that does not extend to using
Q-P or Base64 as a CTE).
>
>> 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@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@the message header.
Folks should note this is where Frank confused (1) and (2). I have
annotated his remarks with what he meant to say, inside [..].
>
>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[2]), and I don't have
>it with (2[1]). 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[2]). And for you issue (= my 2[1]) it
>might be precisely the purpose of an "IETF experiment" to see
>if it works out in practice.
It doesn't need any experiment. It is already known that 3 widely used
MTAs will not cope with it, and I am only aware of one (not so widely
used) that will. As I said above, no problem if (1) happens inside the
global sandbox, but it is explicitly intended to work outside it.
>
>I could say the same about (1[2]), but I'd hate it if (1[2]) turns
>out to be critical and kills the EAI effort, because (1[2]) is
>not really necessary to experiment with "Email Address I18N".
But EAI is trying to do far more than fix "Email Address I18N".
>
>Arguably (2[1]) 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[1]) is necessary. Somehow those DSNs to
>an EAI sender with 7bit hops on the return path must make it.
>
There are two ways to fix (1). Either an application/message, or else
insist the message/global is downgraded before letting it loose on the
current network (in which case you might as well continue to call it (an
extended) message/rfc822.
>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.
>
It may well be rare, but the IETF places great store on not breaking
existing implementations, however ancient. You and I might agree that is
an unnecessary straightjacket, but there it is :-( .
>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.
But that is NOT what the utf8headers draft says.
>
>> 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@7)
the
>time when 204[56] were published (1996, twelve years ago).
No, you didn't resolve it. What I think we really need is for Ned to join
this discussion and to read my objection. I believe he will uphold my
position but, if not, then I might be prepared to shut up. Cc to Ned.
>
> Frank
>
>
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl@xxxxxxxxxxxxxxxx Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf