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.
For a topic "Internet, email, the IETF, and all the rest"
we are close enough, and you proposed to bet on 2822upd. :-)
The last time I did this was before IETF 70 proposing to put
2821bis + 2822upd + email-arch into a proper WG to make sure
that they are in sync.
John's point about FWS-in-quoted-string was no nonsense, and
at the moment 2821bis and 2822upd disagree about it. For
the "F" part it might be "good enough", somebody trying to
use CrLf within a quoted-string of the envelope will learn
very fast that it won't fly. For HTAB it's less clear, and
it would be nice to arrive at "anything matching FWS means
a single SP if used in SMTP" (or similar, all details for
quoted-pairs TBD, I have proposed text some weeks ago here).
I've no idea what 2822upd will do. But it's important, some
folks think it is a good idea to introduce the quoted-pair
also in EAI for UTF8-non-ascii only because RFC 2822 has it
for any ASCII. With IMO ugly effects for mailto-eai, apart
from being completely unnecessary to start with.
I cannot imagine how the resolution of a FWS issue could
have an impact on the overall email architecture.
IFF we want normative references to 2822upd in 2821bis and
email-arch the impact is "blocked until 2822upd is ready".
[... procedural subtopic skipped, reply in mail ...]
It was widely agreed long ago that we botched the
versioning in MIME and therefore the version would almost
certainly never change.
Yes, and it was also almost certain that nobody would dare
touch US-ASCII in MIME part headers. Unfortunately EAI did
it anyway while not updating the version, claiming that all
uses are strictly limited to the message/global "sandbox".
I don't believe in this assumption, if folks want sandboxes
EAI's change is going to be more... interesting.
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.
And external-body - for obscure reasons the IETF announce
list still desperately tries to use it, causing my old MUA
to crash when somebody forwarded an announcement "as is".
I never found out what exactly the problem is. But when a
MIME access type can be erroneously registered as subtype
for about 15 years I guess that folks don't care about it.
I actually proposed message/x400-p2 at one point as a
tunnelling mechanism and got roasted for it.
Meanwhile there are a few more message/*, some in need of
updated references (1894 => 3464, 2298 => 3798), apparently
the authors forgot this. Can I simply suggest this on the
MIME types list, and submit it to IANA after a timeout ?
I simply haven't had the cycles to participate actively
It was a kind of fig-leaf WG, relevant folks hiding out in
their private design-team. <shrug />