On Tue, 2005-02-15 at 16:22 -0800, Philip Guenther wrote:
http://sendmail.org/draft-ietf-sieve-3028bis-00.txt
Changes from RFC 3028
1. Split references into normative and informative
2. Update references to current versions of DSN, IMAP, MDN, and UTF-8 RFCs
3. Replace "e-mail" with "email"
I think this is the wrong way around, no one pronounces "e-mail" in a
manner consistent with the spelling "email" ;-). however, using _both_
spellings as in 3028 certainly isn't ideal.
4. Incorporate RFC 3028 errata
5. The "reject" action cancels the implicit keep
6. Replace references to ACAP with references to the i18n-comparator draft.
Further work is needed to completely sync with that draft.
7. Start to update grammar to only permit legal UTF-8 (incomplete)
and correct various other errors and typos
too bad RFC 3629 didn't include a syntax class for UTF-8 sans control
codes, I'm sure this will be needed elsewhere, too. if you are
pedantic, 0x80..0x9F are also code points used for control codes. so,
don't use UTF8-2, but define your own
UTF8-2-NO-CTL = %xC2 %xA0-BF / %C3-DF UTF8-tail ; excludes U+0080..U
+009F
I think defining
UTF8-NO-CTL = UTF8-1-NO-CTL / UTF8-2-NO-CTL / UTF8-3 / UTF8-4
UTF8-1-NO-CTL = %x20-7F
will make the rest of your grammar more readable.
I have some additional fixes for the grammar already queued up for
the -01 rev, so you can probably hold off on picking nits there for
now. The only open issue I need feedback on there is where bare
CR and LF characters should be allowed. In comments? In strings?
In multiline literals?
do we gain anything by supporting bare CR or LF? I think we should
disallow control characters altogether (except CRLF and HTAB, of
course). is this too big a change? I note that 3028 only accepts NUL
inside /**/ comments (gotcha!), so arbitrary binary data isn't supported
currently.
if we keep control characters, solitary CR or LF should be accepted just
as any other odd control character.
you are aware that quoted-string is hopelessly broken, I'm sure.
wrt bracket-comment, I don't think you need to complicate it much more:
bracket-comment = "/*" (*(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) / "*")
"*/"
The other open issues on my list are:
1) removal of the "Tests MUST NOT have side effects" restriction.
We must permit the behavior of the 'variables' extension; do we
still want to discourage side-effects in general or should the
last two paragraphs of section 2.5 simply be dropped?
2) some other clarifications that Cyrus forwarded to me that I
haven't rolled in yet. (sorry)
a clarification about ":matches" would be useful: the pattern must match
the entire string.
thanks,
--
Kjetil T.