<[EMAIL PROTECTED]> wrote: > 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 why can't they play with say javascript instead of email ? > EAI's change is going to be more... interesting. +1 >> 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 > in EAI. It was a kind of fig-leaf WG, relevant folks hiding out in their private design-team. <shrug /> Frank
