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
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 ;-)