On Fri July 22 2005 22:27, Frank Ellermann wrote:
Bruce Lilly wrote:
Last time I checked, "word" wasn't an abbreviation.
Line 719 in 2822:
word = atom / quoted-string
It's still not an abbreviation.
Using your idea: "Read <word> as <atom> or <quoted-string>".
I never said that.
for 2822bis we better stick to the 2822 idea, no MIME.
I guess that's a matter for community discussion and
consensus. Ignoring MIME doesn't seem rational
IBTD, it's a known way to limit the problem space, it worked
for 2822.
No, as mentioned, there are issues related to phrase that affect
encoded-words.
there needs to be some sort of reconciliation between MIME
[...]
and 2822
Sure, we also need a 2231bis etc.
it really needs to be examined carefully.
Yes, starting with the 2822bis part would allow this. If it
turns out to be "not interesting enough" maybe add MIME later.
The problem is that the 2822 definitions of phrase, unstructured, and
comment have to be consistent with what 2047 uses.
E.g. check <cew>, AFAIK you can't have "?=" in an encoded word:
(=?us-ascii?Q?example?=?=) Something's odd there.
See RFC 2047 section 5, paragraphs labeled "(2)" (and referring to
the errata for 2047). Of course a literal '?' can't appear in the
encoded-text (2047 sect. 4.2 "(3)"). However, B and Q encodings
differ, and there may be private-use or future encodings will still
other characteristics; while '=' cannot appear in a Q-encoded
encoded-text sequence, it is not only legal but necessary for padding
in some B-encoded sequences. The sequence in your example is a
valid atom, but is not an encoded-word because it does not contain
exactly 4 '?' characters (RFC 2047 sections 1 & 2). While the ABNF
could be tweaked somewhat, there is a limit to what can be achieved
with ABNF while allowing enough flexibility to accommodate future and
private-use encodings.