<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.
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.
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.
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.
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 ?
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.
Sorry, I have really no clue what you are talking about
wrt email-arch, is one of its five MUST or three SHOULD
critical ? As far as I can see it they all only reflect
existing MUSTard, they don't introduce really new rules.
[experimental MIME update in EAI]
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".
Great, the one time I really want you to write "shut up"
you don't.
[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.
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.
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.
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.
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. Intentionally violating a SHOULD is bad enough,
getting it wrong would be FUBAR. If there's anything above
IETF politics in 1996 that I don't see I'd really like to
know it. An application/message hack would be clumsy, but
better than breaking the "email architecture" or something.
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.
Frank