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
- Re: a plea for syntactic cleanliness Cyrus Daboo
- Re: a plea for syntactic cleanliness Lawrence Greenfield
- Re: a plea for syntactic cleanliness Mark Crispin
- Re: a plea for syntactic cleanliness Mark Crispin
- Re: a plea for syntactic cleanliness Cyrus Daboo
- a plea for syntactic cleanliness Lawrence Greenfield