<ned+ietf-smtp(_at_)mrochek(_dot_)com> 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,
And that goes too far. To paraphrase and agree with Dave: This document
describes what is, not what might or will be.
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.
On the contrary, it is pretty likely that 2822upd long before EAI has
deployment even as an experiment sufficient to warrant mention here. 2822upd is
therefore a much better bet.
Not mentioning EAI at all in the I18N considerations would be
odd.
No, mentioning it would be.
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.
Your proposed text is fine except the last paragraph needs to be dropped and
change "allows to use" -> "allows the use" in the next to last paragraph.
If email-arch is for email what TAObis or roadmap are for the
IETF,
Neither comparison is even close as far as I can tell.
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).
The word you're missing here is "deployed".
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).
I agree it is a little awkward, although not for the reasons you give, but
unfortunately political realities more or less demand that it be standards
track.
In any case, now is not the time to rehash the whole
our-document-categories-don't-fit-current-reality thing. If you want that take
it to the main IETF list - I think we're just about due for another round of it
there.
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".
Again, I simply don't know if 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.
I have no idea why this is supposed to be in any way relevant to
the matters at hand.
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.
Again, the answer is "I don't know". And yes, that means that EAI may have a
problem - quite possibly a big problem. Or it may not.
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.
There is no inconsistency. The message type was intended, as the name
implies, to represent messages. Given that the goal was to eliminate
any possibility of a nested encoding, it made sense at the time to
ban encoding of message parts.
What has happened subsequently is that the definition of message has been
stretched to cover some things that aren't really messages per se. And EAI is
stretching that even further. And this is what has created the "obvious
inconsistency" you refer to.
The EAI folks convinced me that their solution should be acceptabl
and that 2045 slightly exaggerated the intentions for message/*
in comparison with multipart/*.
Whatever justification floats your boat is fine with me. Just please refrain
from applying 20:20 hindsight to complex decisions with a significant political
component made well over 15 years ago.
[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.
I'm sorry, but the notion that SPF in practice, let alone an experimental RFC
that covers only part of the picture, has much if anything to do with real
world spam fighting techniques is nothing short of ludicrious.
Like it or not, EAI's success will depend on the extent to which it's adopted
and once adopted the extent to which it causes issues for the installed base of
email services, including but not limited to the major antispam vendors and a
myriad of others. You may deplore the extent to which we depend on these sorts
of factors we cannot control for successful deployment, and I might even agree
to a certain extent, but our deploring it won't change matters any.
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.
I'm sure you'll use whatever terminology you feel is appropriate.
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 ;-)
Really, I don't see why this has to be so hard. RFC 2277 defines policies for
the use of charsets in IETF protocols. This is indirectly related at best to
what's out there, so unless thre's a compelling reason to jump across
that indirection - and you haven't given one - it doesn't warrant mention
in email-arch.
Ned