a plea for syntactic cleanliness

[Lawrence Greenfield <[e-mail]>]

Ok, I was reviewing some parsing stuff in Cyrus, which has code to
support some of the ANNOTATE suggestions.

I'm getting increasingly frustrated by the extensions that are
defining strange strings. For instance, there is never any reason to
allow a quoted string but not allow a literal string. We have
LITERAL+, all servers that care about performance should implement it,
and it frees clients from having to figure out if there are any
characters that need to be quoted.

Looking at draft-ietf-imapext-annotate-05.txt, it defines some
protocol elements not in terms of base imap strings (like 'attrib' or
'entry') but rolls its own.

In doing so, it does weird things:

   entry             = DQUOTE 1*atom-slash *("/" 1*atom-slash) DQUOTE
   atom-slash        = any utf8-char except "/"
   utf8-char         =  %x01-FF
                       ; any character, excluding NUL

Ok, so an entry could be

"\001\002////""/"\045"

is this really what's intended?

Instead, 'entry = string', where string is well defined in the IMAP
base spec, would suffice. It is a semantic constraint that should
prevent a leading slash, NOT a syntactic one. Let's not try to force
things into the ABNF that are really about the semantics.

Now, looking at draft-crispin-imapv-20, 'quoted' isn't allowed to
contain UTF-8 characters, meaning that literals are going to be used
more heavily. That really isn't a big deal.

ACL2 makes the same mistake. Please, use "string" or "nstring" in
extensions. Don't roll your own. Don't make us have to rewrite lexers
to deal with strange semantic constraints.

Larry