<ned+ietf-smtp(_at_)mrochek(_dot_)com> wrote:
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.
If 2821bis, 2822upd, and email-arch end up out of sync
with contradictions we have definitely dropped the ball.
Sure.
But I dare not yet bet on 2822upd while John wants it to
solve the FWS-in-quoted-string problem (after I thought
that 2822upd is in essence ready for Last Call), that is
not as easy as shifting cruft to obs-*, or beautifying
the ABNF where it is forced to preserve the 822 #-rule.
This is again wandering off topic, but IMO these attempts to tie up every last
detail are fundamentally misguided. We're letting the best be the enemy of the
plenty good enough.
But even so I cannot imagine how the resolution of a FWS issue could have an
impact on the overall email architecture.
Not mentioning EAI at all in the I18N considerations
would be odd.
No, mentioning it would be.
Let's agree to disagree here, I certainly don't "insist"
on mentioning RFC 4952.
OK.
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.
For a long terminology discussion on the SPF list I tried
to convice the protagonists that *redefining* terms in
email-arch would be a seriously bad idea, it is how I see
email-arch. Maybe RFC 4949 is a better comparison.
Not really. That's a glossary, and hence focused on invidual terms. Since
there's no overarching architectural context this tends to emphasize small
inconsistencies in ways an architectuure document does not.
In any case, I think RFC 4949 is basically OK. My main problem with it is not
that it redefines terms oddly, but rather that it defines tons of terms that
are rarely if ever used.
unfortunately political realities more or less demand
that it be standards track.
No idea why - is that a procedural side-effect of not
having a proper WG for 2821bis + 2822upd + email-arch ?
I really don't want to get into this here so this is going to be my final note
on this subtopic. The issue is that documents like this have status beyond that
of a random informational specification so informational isn't appropriate,
they aren't an experiment, they don't really define a set of practices so BCP
isn't the right fit, and they don't define a protocol or something that has
obvios interoperability criteria so standards track advancement is problematic.
In short, none of our document statuses are a perfect or even good fit, and the
closest fit seems to be standards track.
Another document with similar issues was the ABNF specification. And then
there's the issue of how to deal with what used to be the ION document series
that's being discussed now on the IETF list.
[old 2231 debate]
I have no idea why this is supposed to be in any way
relevant to the matters at hand.
RFC 2231 was a MIME update without changing the version
number, EAI allows UTF-8 without changing the version
number, both changes could be considered as not strictly
1.0 backwards compatible. Only in theory for the former,
for the latter it's hard to judge.
It was widely agreed long ago that we botched the versioning in MIME and
therefore the version would almost certainly never change. RFC 2231 was
carefully designed so it is syntactically backwards compatible with non-2231
systems. And in any case, the issues with RFC 2231 in practice have nothing to
do with having broken backwards compatibility.
EAI's change is going to be more... interesting.
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.
Sure. It makes less sense if an UTF8SMTP sender somehow
manages that the reverse path requires 7bit for a DSN,
my application/message idea to get over 7bit hops was
in essence the same as nested B64, nobody on the public
EAI list liked it.
application/message (sometimes with different names) has been proposed at
least half a dozen times over the years. I personally don't have a major
problem with it, but regardless of my position tThe idea has never gotten any
traction and I don't see that changing now.
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.
My impression for message subtypes in RFC 2046 was that
message/unknown is actually opaque, to be handled like
an application/octet-stream, where B64 is allowed, while
multipart is multipart, where only 7bit / 8bit / binary
counts, other CTEs only within the multipart.
Not reallly. It was a complex situation, but basically what happened was that
there was really never intention of there ever being any additional message
subtypes other than rfc822 and partial. I actually proposed message/x400-p2 at
one point as a tunnelling mechanism and got roasted for it.
From there I arrived at the conclusion that the RFC 2045
"expressly forbidden" means MUST for any multipart/* and
"only" SHOULD for message/unknown, with explicit MUSTard
for message/rfc822 etc. A subtle difference, an erratum
could explain it - likely pointless, nobody on the MIME
types list bothered to question why message/global wants
or needs unusual CTE rules.
Operational experience is going to be the determining factor here.
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.
If there were other _technical_ reasons for the message/*
and multipart/* difference in RFC 2046 I'm curious what
they were.
There are no _technical_ reasons behind any of these restrictions. I proved
that during the Atlanta IETF by building and demonstrating in one evening an
efficient nonrecursive MIME decoder capapable of handling nested encodings with
ease.
No, nested encodings were banned because there was a strong consensus that they
were too complex, that implementors wouldn't handle them correctly, that they
would be used profligately and that the result would be messages bloated by
many encoding layers, and no doubt a bunch of other concerns I no longer
recall. This consensus carried the day.
In fact you could argue that a big reason this came about was due to meeting
scheduling. The PEM WG was in full swing at the time, but since it was in the
security area, it's meetings consistently conflicted with those of the IETF-822
WG so that's where all the security types were. The result was that folks like
Jim Galvin, Steve Crocker, and several others who could have pointed out the
consequences of forbidding nested encodings on security enclosures weren't
there to make the arugment. I tried to make this arugment myself but it was
very difficult to do this as a document author and not as a security geek.
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.
I can't say that I "like" or "dislike" EAI, or that I would
be "happy" if EAI is a success. It could disappoint folks
considering US-ASCII as gibberish if it fails, that would be
sad. It would be also sad for the folks who worked hard on
EAI - that is why I'm worried about introducing the "nice to
have" detail UTF-8 in MIME part headers, if its side-effects
could contribute to a failure.
Yep, that's a very valid point. Doing the minimal necessary is arguably best in
such cases. But this isn't the EAI group, and unfortunately I simply haven't
had the cycles to participate actively in EAI.
Ned