Bruce Lilly wrote:
word = atom / quoted-string
It's still not an abbreviation.
In syntax it is, <word> is an "abbreviation" for
<atom> or <quoted-string>. Otherwise - only if
you're in hardcore nitpicking mode - let's state
that CFWS is an acronym.
That's pretty irrelevant for the syntax, a few
days ago you proposed <blurf> or <usenet-from>.
Maybe it's "bruce lilly's ugly restricted from",
but it won't change the syntax of this <blurf>.
Similar the syntax of CFWS isn't affected by
any "C or FWS" or rather "C and/or FWS", it is:
CFWS = *([FWS] comment) (([FWS] comment) / FWS)
The name of a rule is only a courtesy for the
reader, we could replace all <CFWS> by <blurf>
without effect for the message format.
It can have effects for the semantics, because
it's not obvious what a <blurf> should be, but
<CFWS> is also not obvious, it has a paragraph
in prose with explanations and a motivation.
Maybe a name like <sugar>, <noise>, or <invis>
instead of <CFWS> would be also fine. It would
at least spare us this discussion, where you
claimed that every FWS is a CFWS, and therefore
rules for CFWS also affect FWS outside of CFWS.
Good names like <host> or <id-domain> instead of
<blurf> or <id-right> are very important, but
they have no effect for the syntax.
your idea: "Read <word> as <atom> or <quoted-string>".
I never said that.
<200507212140(_dot_)37793(_at_)mail(_dot_)blilly(_dot_)com>
| If you read CFWS as "comments and/or folding
| whitespace" there's no problem.
[revised grammar]
as mentioned, there are issues related to phrase that
affect encoded-words.
Sorry, you lost me there, is this about <specials> vs.
<tspecials> and similar nits ? Or in other words, is
is possible to fix it in a 2231bis / 2047bis based on
2822, or is it something that has to be done together
with 2822bis ? Do you have an example ?
It's the most important feature of MIME that you can
completely ignore it whenever it pleases you, without
affecting the message format or transport (modulo some
8bit issues). Have you found any bug where that won't
work ?
The problem is that the 2822 definitions of phrase,
unstructured, and comment have to be consistent with
what 2047 uses.
Yes, they have to be consistent, e.g. if I know CFWS
and treat it as "semantically invisible" I'd want the
same result with or without knowing 2047 / 2231.
For <unstructured> I've no idea how that could be ever
a "problem", as you said. But since you insisted on
allowing the obs-phrase dots in USEFOR I fear that it
could bite "us" (= USEFOR). And if it does it's also
a problem in 2822 or 2047.
(=?us-ascii?Q?example?=?=) Something's odd there.
See RFC 2047 section 5, paragraphs labeled "(2)" (and
referring to the errata for 2047).
Okay, no "(", ")", "\", and separated by LWSP from ctext
or any other encoded-word.
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
Yes, but no "?" is a _general_ rule for <encoded-text> in
chapter 2, it does not depend on the encoding. And your
cchar allows "?" (%d63):
cchar = %d33-39 / ; Printable US-ASCII
%d42-91 / ; characters not including "(",
%d93-126 ; ")", or "\"
While the ABNF could be tweaked somewhat, there is a limit
to what can be achieved with ABNF
Just exclude "?" in addition to "(", ")", "\". Bye, Frank