<[EMAIL PROTECTED]> 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
