Re: a plea for syntactic cleanliness

Cyrus Daboo <daboo@cyrusoft.com> Mon, 02 December 2002 23:02 UTC

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB2N2DM24214 for ietf-imapext-bks; Mon, 2 Dec 2002 15:02:13 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2N26g24210 for <ietf-imapext@imc.org>; Mon, 2 Dec 2002 15:02:07 -0800 (PST)
Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA29009; Mon, 2 Dec 2002 17:58:07 -0500 (EST)
Date: Mon, 02 Dec 2002 18:01:15 -0500
From: Cyrus Daboo <daboo@cyrusoft.com>
To: Lawrence Greenfield <leg+@andrew.cmu.edu>, ietf-imapext@imc.org
Subject: Re: a plea for syntactic cleanliness
Message-ID: <2147483647.1038852075@[63.163.82.24]>
In-Reply-To: <200212022213.gB2MD6Q9014762@smtp6.andrew.cmu.edu>
References: <200212022213.gB2MD6Q9014762@smtp6.andrew.cmu.edu>
X-Mailer: Mulberry/3.0.0 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Lawrence,

--On Monday, December 2, 2002 5:13 PM -0500 Lawrence Greenfield 
<leg+@andrew.cmu.edu> wrote:

| 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.

Lets define a string type that allows quoted utf8 data and have those 
extensions that want to use utf8 data (such as annotate/acl2 etc) be able 
to use that. That way you only need to add one new 'type' to your parser 
for all those types of extensions. There is no reason not to have utf8 
quoted strings in new extensions even if the base spec protocol elements 
still have to use literals for those.

The reason for the 'entry' item in annotate being the way it is is to try 
and express the hierarchical nature of the entry namespace in ABNF (i.e. 
the fact that '/' is a hierarchy separator). If I remember correctly it was 
modelled on the ABNF used in ACAP. This could be simplified to 'entry = 
string' with a comment about th hierarchical naming - i.e. '/' is a special 
character - but shouldn't that fact be explicitly laid out in ABNF rather 
than relying on the description in the draft text?

I think Chris also mentioned to me that we actually need to reference the 
utf8 spec explicitly to get the proper ABNF for sequences of utf8 
characters. ACAP had a full definition of utf8 character sequences defined 
in ABNF.

-- 
Cyrus Daboo