headers
Cyrus Daboo | 5 Mar 2000 20:12

Formal Syntax in draft-crispin-imapv-09.txt

Hi Mark,
Is it possible to change the formal sytnax ever so slightly in this draft 
to make it easier for extensions to add new search keys? Right now you have:

   search-key      = "ALL" / "ANSWERED" / "BCC" SP astring /
                     "BEFORE" SP date / "BODY" SP astring /
                     "CC" SP astring / "DELETED" / "FLAGGED" /
                     "FROM" SP astring / "KEYWORD" SP flag-keyword / "NEW" /
                     "OLD" / "ON" SP date / "RECENT" / "SEEN" /
                     "SINCE" SP date / "SUBJECT" SP astring /
                     "TEXT" SP astring / "TO" SP astring /
                     "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
                     "UNKEYWORD" SP flag-keyword / "UNSEEN" /
                       ; Above this line were in [IMAP2]
                     "DRAFT" / "HEADER" SP header-fld-name SP astring /
                     "LARGER" SP number / "NOT" SP search-key /
                     "OR" SP search-key SP search-key /
                     "SENTBEFORE" SP date / "SENTON" SP date /
                     "SENTSINCE" SP date / "SMALLER" SP number /
                     "UID" SP set / "UNDRAFT" / set /
                     "(" search-key *(SP search-key) ")"

The presence of the 'search-key' inside of the search-key definition makes 
it a little awkward for extensions to add new search keys. What I propose 
is:

   search-keys     = search-key / "(" search-key *(SP search-key) ")"
   search-key      = "ALL" / "ANSWERED" / "BCC" SP astring /
                     "BEFORE" SP date / "BODY" SP astring /
                     "CC" SP astring / "DELETED" / "FLAGGED" /
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall Gellens | 10 Mar 2000 04:49

RegExp Search Extension

While working on the Annotations draft, it seemed clear that a 
separate draft for regular expressions in search criteria would be 
very useful (instead of making regular expressions part of ANNOTATE 
only).  I've submitted a draft for this.  If you want to see it 
before it shows up in the I-D directories, you can get it from 
<ftp://ftp.pensive.org/Public/Randy/draft-ietf-imapext-regex-00.txt>.

Does anyone object to making this part of the IMAP EXT wg?
--

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Whenever you find that you are on the side of the majority, 
it is time to reform.                         --Mark Twain
Permalink | Reply | 9 comments |
headers
Mark Crispin | 10 Mar 2000 05:04

re: RegExp Search Extension

We considered regular expressions years ago, and punted.  Regular expressions
are ASCII-centric.  Try to come up with a definition that's Unicode-savvy and
you'll rapidly find yourself up to your posterior in alligators and wondering
why you ever entered that swamp...
Permalink | Reply | 0 comments |
headers
Paul Hoffman / IMC | 10 Mar 2000 05:33
Picon

re: RegExp Search Extension

At 08:04 PM 3/9/00 -0800, Mark Crispin wrote:
>We considered regular expressions years ago, and punted.  Regular expressions
>are ASCII-centric.  Try to come up with a definition that's Unicode-savvy and
>you'll rapidly find yourself up to your posterior in alligators and wondering
>why you ever entered that swamp...

Well, that's why we let the folks in the Unicode Consortium go into that 
swamp first. :-) They've already done a great deal of this work in their 
Technical Report #18 <http://www.unicode.org/unicode/reports/tr18/>. It is 
well on its way to making it into a future version of the Unicode Standard.

--Paul Hoffman, Director
--Internet Mail Consortium
Permalink | Reply | 7 comments |
headers
Mark Crispin | 10 Mar 2000 05:34

re: RegExp Search Extension

On Thu, 09 Mar 2000 20:33:30 -0800, Paul Hoffman / IMC wrote:
> Well, that's why we let the folks in the Unicode Consortium go into that
> swamp first. :-) They've already done a great deal of this work in their
> Technical Report #18 <http://www.unicode.org/unicode/reports/tr18/>. It is
> well on its way to making it into a future version of the Unicode Standard.

Which, in turn, strongly indicates that no IMAP specification should define
regular expressions, but instead should reference another standard.

It's bad enough that there are a few dozen different and subtly incompatible
definitions and implementations of the things going around as it is.

By the way, how do you explain a regular expression to someone who isn't a
UNIX propellerhead, e.g. your typical Windows or Mac user?
Permalink | Reply | 6 comments |
headers
Randall Gellens | 10 Mar 2000 06:32

Annotate Draft

I've sent in the Annotate draft.  If you want to see if before it 
hits the I-D directories, you can get a copy at 
<ftp://ftp.pensive.org/Public/Randy/draft-ietf-imapext-annotate-00.txt>

--

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Politics is the art of making the inevitable appear to be a 
matter of wise human choice.                 --Quentin Crisp
Permalink | Reply | 3 comments |
headers
Randall Gellens | 10 Mar 2000 06:37

re: RegExp Search Extension

At 8:34 PM -0800 3/9/00, Mark Crispin wrote:

>Which, in turn, strongly indicates that no IMAP specification should define
>regular expressions, but instead should reference another standard.

The RegEx draft lists this as an open issue: to define a simple 
subset in the document (as it now does) or simply reference a 
published (and more complex) spec.

>It's bad enough that there are a few dozen different and subtly incompatible
>definitions and implementations of the things going around as it is.

Yes, that is very annoying.

>By the way, how do you explain a regular expression to someone who isn't a
>UNIX propellerhead, e.g. your typical Windows or Mac user?

There are Mac and Windows programs that implement regular 
expressions.  Their use in filters in MT-NewsWatcher, for example, 
can make usenet somewhat tolerable.  MS Visual Studio and BBEdit 
allow them for searching.  (The MS version seems somewhat different 
from others.)

--

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Ninety percent of the politicians give the other ten percent a bad name.
                                                      --Henry Kissinger
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall Gellens | 10 Mar 2000 18:34

Annotate Draft (Corrected URL)

[[[ Sorry -- the URL was incorrect in the original message ]]]

I've sent in the Annotate draft.  If you want to see if before it 
hits the I-D directories, you can get a copy at 
<ftp://ftp.pensive.org/Public/Randy/ietf-imapext-annotate-00.txt>
Permalink | Reply | 0 comments |
headers
Cyrus Daboo | 10 Mar 2000 19:20

re: RegExp Search Extension

--On Thursday, March 9, 2000 8:34 PM -0800 Mark Crispin 
<MRC <at> cac.washington.edu> wrote:

> By the way, how do you explain a regular expression to someone who isn't a
> UNIX propellerhead, e.g. your typical Windows or Mac user?

You don't need to if your client has a GUI constructor for creating simple 
regular expressions. Complex regular expression probably do have to be 
entered by hand. In addition a client may create a regular expression 
search criterion without explicit input from the user, for example to 
implement sophisticated filtering rules etc.

Given that many POP clients can do searching on their local mailboxes with 
capabilities that exceed what is currently present in IMAP's SEARCH 
command, I would very much like to see some form of regular expression 
searching available in IMAP, ascii vs unicode issues not withstanding.

--

-- 
Cyrus
Permalink | Reply | 3 comments |
headers
Mark Crispin | 10 Mar 2000 19:52

re: RegExp Search Extension

I will oppose any regular expression proposal which does not have all of the
following properties:

1) It is completely and unambiguously specified, so that interoperability
   between multiple implementations is guaranteed.

2) It is fully Unicode-savvy.  This also means that there will need to be
   hooks for locale and language.

This precludes a specification that refers to, or otherwise uses, the C regex
routines.  There are multiple variants of the C regex routines, particularly
between platforms, and most are hopelessly ASCII-centric.  Since the C regex
routines present an attractive nuisance, the IMAP regex specification must be
written in a way that will preclude any possibility of some lazy programmer
using them.

Also, there will need to be significant work on performance.  Remember that
UNIX has three different variants of grep; at least in older systems they
admitted the reason why:
     Ideally there should be only one grep, but we don't know a
     single algorithm that spans a wide enough range of space-
     time tradeoffs.

Right now, IMAP searches can use fast algorithms such as Boyer-Moore.  You
have to do something completely different for regular expressions.

As far as the "but some POP clients do it" argument goes, let me point out
that they're doing it on the client, not the server.  I don't want to give the
POP camp ammunition for the "IMAP is too hairy and slow" argument by some
misguided idea of "keep up with the Jones' and damn the consequences."
(Continue reading)

Permalink | Reply | 0 comments |

Gmane