Subject: re: RegExp Search Extension
From: Chris Newman <[email-masked]>
To: [email-masked]
Date: Tue, 28 Mar 2000 10:39:15 +0930
List-Id: <ietf-imapext.imc.org>

--On Thursday, March 9, 2000 20:34 -0800 Mark Crispin 
<[email-masked]> 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?

It's interesting to see how these work in the news space.  Some 
propellerhead creates a good "spam killing" regular expression and sends it 
out to a mailing list.  Typical users can copy and paste the regular 
expressions into the "regular expression" box without knowing what it 
means.  It works a lot like URLs do.

		- Chris

Date: Fri, 17 Mar 2000 12:55:57 -0500
From: Cyrus Daboo <[email-masked]>
To: Simon Josefsson <[email-masked]>, Randall Gellens <[email-masked]>
cc: [email-masked]
Subject: Re: Annotate Draft
Sender: [email-masked]

--On Friday, March 17, 2000 6:23 PM +0100 Simon Josefsson <[email-masked]> 
wrote:

> Perhaps a silly question, but, are there any intentions on extending
> this to make it possible to have annotations on mailboxes (as opposed
> to articles)?  NNTP provide a text description of groups, and people
> have asked me if IMAP could support something similar.
>
> (The usefulness of this probably only become clear when there are
> thousands of shared mailboxes. Otherwise, just choose a good
> descriptive mailbox name.)

This has been discussed in imap-ext before (probably at one of the 
meetings). I believe there was a general consensus to do mailbox 
annotations, but there was a feeling that this may need to be tied into 
changes to the LIST command (or a replacement for LIST) that some people 
felt was required. I think the best thing to do is see how message 
annotations fair, and once we've progressed to the point where people agree 
on the behaviour of that, then we can look at mailbox annotations again.

I also proposed server annotations as well, but this was less well 
received! I still think they could serve a useful purpose (they would 
likely be read-only annotations for everyone except the server admin but 
that does bring up issues with the interaction between ACLs and annotations 
- something we may have to address in message annotations too).

-- 
Cyrus

Date: Fri, 17 Mar 2000 10:55:09 -0700
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Randall Gellens <[email-masked]>, [email-masked]
Subject: Re: Annotate Draft
Sender: [email-masked]

Simon Josefsson wrote:
> 
> Randall Gellens <[email-masked]> writes:
> 
> > I've sent in the Annotate draft.
> 
> Perhaps a silly question, but, are there any intentions on extending
> this to make it possible to have annotations on mailboxes (as opposed
> to articles)?  NNTP provide a text description of groups, and people
> have asked me if IMAP could support something similar.
> 
> (The usefulness of this probably only become clear when there are
> thousands of shared mailboxes. Otherwise, just choose a good
> descriptive mailbox name.)

The consensus was to write separate draft.

Alexey

To: Randall Gellens <[email-masked]>
Cc: [email-masked]
Subject: Re: Annotate Draft
From: Simon Josefsson <[email-masked]>
Date: 17 Mar 2000 18:23:06 +0100
Lines: 12
Sender: [email-masked]

Randall Gellens <[email-masked]> writes:

> I've sent in the Annotate draft.

Perhaps a silly question, but, are there any intentions on extending
this to make it possible to have annotations on mailboxes (as opposed
to articles)?  NNTP provide a text description of groups, and people
have asked me if IMAP could support something similar.

(The usefulness of this probably only become clear when there are
thousands of shared mailboxes. Otherwise, just choose a good
descriptive mailbox name.)

Date: Thu, 16 Mar 2000 22:22:17 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: I-D ACTION:draft-daboo-imapext-view-02.txt (fwd)
Sender: [email-masked]

--==========00075517==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
Below is the IETF-Announce message for a new version of the VIEW extension 
draft. I've attached a copy of my 'changes' document to this message so you 
can see the detailed changes.

The new draft has been written so that VIEW implements the semi-dynamic 
updating mechanism discussed previously. There is still some debate 
(controversy) about whether VIEW should be semi-dynamic, dynamic or both. 
Some people feel we should only do one method to avoid making VIEW too 
complex, others feel that two would be better (via some kind of client 
initiated switch).

Right now the semi-dynamic model in the draft does allow 'dynamic' 
behaviour via VIEW NOOP and VIEW IDLE commands (new in this draft). The 
goal with these is to allow a client to get the additional 'dynamic' 
unsolicited responses only when these commands are used. Again there is 
some debate about whether VIEW NOOP and VIEW IDLE are appropriate here, or 
whether there should be a separate VIEW UPDATE command.

In any event, this issue of semi-dynamic vs dynamic is still an open topic, 
and I think is really the only major item that needs to be addressed in 
VIEW - others may feel differently of course!.

---------- Forwarded Message ----------
Date: Thursday, March 16, 2000 4:16 PM -0500
From: [email-masked]
To: IETF-Announce
Subject: I-D ACTION:draft-daboo-imapext-view-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	 Title		: IMAP VIEW Extension
	 Author(s)	: C. Daboo, M. Crispin, M. Pustilnik	
         Filename	: draft-daboo-imapext-view-02.txt
	 Pages		: 16
	 Date		: 15-Mar-00
	
The VIEW extension to the Internet Message Access Protocol [IMAP4]
permits a subset of messages in the mailbox to be processed
separately from the entire set of messages in the mailbox.  This
allows a client to restrict its view to only the messages appearing
in this set.  The subset of messages also need not be returned in
order of their sequence numbers, allowing clients to access messages
in a particular sort order.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-imapext-view-02.txt

---------- End Forwarded Message ----------

-- 
Cyrus
--==========00075517==========
Content-Type: text/plain; charset=iso-8859-1; name="changes.ml"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="changes.ml"; size=4202

View Draft Changes 01 -> 02

General
- Added VIEW NOOP and VIEW IDLE commands to allow client to receive dynamic =
updating of view state.

3 Introduction
- Added comment on interaction with IDLE command.
- Added NOOP and IDLE to list of sub-commands used by VIEW.
- Added comment about VIEW COPY requiring copy in sorted order.

4.1.1 VIEW SET
- Changed text on untagged VIEW response to point to new section 5.1 where =
its use is described in more detail.

4.1.2 VIEW <sub-command>
- Added description of VIEW COPY preserving view order.
- Added description of VIEW NOOP and VIEW IDLE commands.

5.1 Response Conditions
- New section to describe the response 'conditions' under which untagged =
responses may be sent. Also describes how clients effect a 'dynamic' view =
using VIEW NOOP and VIEW IDLE.

5.2.1 New message arrival
- Added references to section 5.1 response conditions

5.2.2 Messages moving in the view
- Added references to section 5.1 response conditions

5.4 EXPUNGE Untagged Response
- Added references to section 5.1 response conditions

6 Formal Syntax
- Added VIEW NOOP and VIEW IDLE as possible commands.

View Draft Changes 00 -> 01

General
- Added option to allow VIEW SET command arguments during a SELECT or =
EXAMINE command as agreed in Olso.
- Changed text to describe VIEW as a single command and a single response, =
with different variants.

3 Introduction
- (c) removed VIEW item in FETCH command as there is never any need to =
explicitly request it as its always returned when view is in effect.

4.1 VIEW SET Command
- Added clarification on valid sub-commands: only SEARCH for now but may =
allow SORT and THREAD in future.
- (c) changed to apply to ALL fetch responses not just unsolicited.
- (c) removed reference to VIEW item in FETCH command.
- Added (h) to clarify resetting a view using another VIEW SET.
- Added (i) to clarify cancellation of a view if SELECT, EXAMINE or CLOSE =
occur.

4.3 (was 4.2) VIEW Command
- Added statement that VIEW command is only valid when VIEW SET in effect.

5.1.1
- Removed previous restriction on not sending VIEW response when no command =
is in effect. This contradicts the requirement that VIEW responses for new =
messages must be sent after an EXISTS.

5.1.2
- Clarified restrictions on when VIEW response for moving messages can be =
sent.
- Corrected 'non-zero' to 0 in a couple of places.
- Added section on both <old> and <new> being non-zero.
- Corrected examples which had <new> and <old> values reversed.

6
- Revised to be compliant with RFC2234.
- Modified syntax to reflect VIEW as a single command and response.
- Added syntax for modified SELECT and EXAMINE commands.
- Added msg-att-dynamic for VIEW message data item in FETCH.
- Alphabetic sort of formal syntax terms.

--==========00075517==========--

From: [email-masked]
Subject: Question
To: [email-masked]
Date: Tue, 14 Mar 2000 16:38:56 -0600
Sender: [email-masked]

Hi.
I was reading about the benefits of using IMAP instead of using POP3 and
I would like to know how can I implement it using the next software.

I have a Raptor Firewall and a Lotus Notes Software installed on Windows NT
4.0 (TCP/IP)
and I have Lotus Notes 5.0.2a International Servers.

The question is:

Do you have documentation about configuring Lotus Notes clients to access
their accounts from the internet using the Raptor firewall or another?

Thanks in advance for your help.

Mario Treviño Salazar
Groupware Analyst & Email Administrator
AXTEL, SA de CV

Date: Tue, 14 Mar 2000 11:33:35 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Announcement of MailConnect 6
Sender: [email-masked]

Greetings again. IMC is pleased to announce our next testing event, 
MailConnect 6. The event will focus on IMAP4, POP3, and SMTP, and will be 
held May 31 and June 1 in San Jose, CA. Full details are available at 
<http://www.imc.org/imc-mailconnect/>.

The two days of MailConnect 6 will focus on IMAP4. IMAP4 is a 
well-established specification with new facilities promising substantial 
improvement for mobile and client/server mail environments. IMAP4 
implementations have fully emerged, although the large number of new of 
IMAP extensions have not been subjected to wide inter-vendor testing. 
MailConnect 6 will provide an opportunity for intense interoperability 
testing and repair of IMAP4 implementations.

During the previous MailConnect events, it has become clear that client 
developers need to pay more attention to the disconnected mode of IMAP. 
MailConnect is an excellent place for client and server vendors to test 
interoperability in this area. Further, IMAP is a dynamic protocol, and 
many valuable extensions have been proposed in the past year. Developers 
will want to meet with other developers at MailConnect to test their early 
implementations of these extensions.

Because most IMAP vendors also have POP3 and SMTP implementations, 
MailConnect 6 will be a good place to test them as well. A new round of 
extensions to POP have come out in the past year, and client vendors have 
expressed strong interest in testing these. Also in the past year, many 
extensions to SMTP have been standardized and deployed; these new features 
will be the focus of the SMTP testing at MailConnect 6. Specifically, 
message submission, SMTP over TLS, and SMTP authorization are likely 
candidates for participant testing.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sun, 12 Mar 2000 23:07:19 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: multi-append
To: Lawrence Greenfield <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Mon, 13 Mar 2000 01:55:41 -0500 (EST), Lawrence Greenfield wrote:
> I'm thinking about implementing MULTIAPPEND for nefarious purposes of
> my own.  I'm not sure clients really want it and I'm pretty sure I
> don't care either way.

The next version of Pine will use it.  It's a BIG win.

> However, it would be more convenient for me if there was a way for the
> client to intentionally abort the append midway through.  Currently,
> that would be possible by sending an invalid date-time or some other
> piece of bad syntax, but that seems icky.

This is a bug in the MULTIAPPEND draft document.  Thanks for pointing it out.
The way to cancel an APPEND cleanly is by giving APPEND a zero-length literal
as a message text argument.

I've fixed this bug in the document, but the ID cutoff has happened so it'll
have to wait until after IETF.

Date: Mon, 13 Mar 2000 01:55:41 -0500 (EST)
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: multi-append
Sender: [email-masked]

I'm thinking about implementing MULTIAPPEND for nefarious purposes of
my own.  I'm not sure clients really want it and I'm pretty sure I
don't care either way.

However, it would be more convenient for me if there was a way for the
client to intentionally abort the append midway through.  Currently,
that would be possible by sending an invalid date-time or some other
piece of bad syntax, but that seems icky.

I don't really need this to interoperate, but figured I might as well
bring it up.  Any good ideas of how to implement "whoops, i didn't
really want to do this append"?

Thanks,
Larry

Date: Fri, 10 Mar 2000 22:37:50 -0700
From: Alexey Melnikov <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
CC: [email-masked]
Subject: Re: Annotate Draft (Corrected URL)
Sender: [email-masked]

Lawrence's letter reminded me of another issue.
We should define interaction of ANNOTATE and ACL.
Should we use "w" right as for changing flags, or maybe another right
should be defined for annotations.

Lawrence Greenfield wrote:
> 
>    From: Mike Gahrns <[email-masked]>
>    Date: Fri, 10 Mar 2000 17:53:16 -0800
> 
>    I think the flexibility provided by not having this attribute opaque is
>    worth the extra complexity it adds.  I suspect it will be a very common
>    action for end users to request things like show me all the comments that
>    were added since a particular date. Having this opaque does not allow for
>    this.
> 
> I agree.  Can we just make this a la the ACAP attribute "modtime"?

That is what I was thinking about.

> The use of the attribute name "value" is confusing, since all
> attributes have values.  (The "acl" attribute value might be something
> like "username rw" or whatever.)  That is, entries in the ACAP model
> are made up of a set of attribute-value pairs, and it's a little
> confusing overloaded the term "value".
> 
> With that in mind, the entry "/message/comment" is currently defined
> as having:
> 
> attribute                       value
> "acl"                           ?
> "value"                         some blob of data
> "content-type"                  MIME content-type
> "modifiedsince"                 another blob of data
> 
> The "content-type" is mentioned in 4.2.2.  Is it required?  Must
> clients set it?  Must the "value" be a valid MIME type?

I think it should be optional and it must be valid MIME type (at least
something in the form <x>/<y>)

> 
> I think something like
> 
> attribute                       value
> "acl"                           beats me? "r" and/or "w"?
> "modtime"                       modtime a la ACAP (server maintained)
> "mime.version"                  MIME version
> "mime.content-type"             MIME content-type
> "value"                         body, must be 8-bit MIME
> "size"                          value size (server maintained)
> 
> "mime.version", "mime.content-type" should be required, and either
> client must set them or they should default to some sort of UTF-8
> text.

Why do you need mime.version? It is always "1.0" ;-)

> There's a problem that value could be quite large---larger
> than I want to download over a modem.  A "size" attribute could help
> with that, though it doesn't allow partial downloads.

Read-only size attribute would be useful for clients.

Alexey

Date: Fri, 10 Mar 2000 21:51:10 -0500 (EST)
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: Re: Annotate Draft (Corrected URL)
Sender: [email-masked]

   From: Mike Gahrns <[email-masked]>
   Date: Fri, 10 Mar 2000 17:53:16 -0800

   I think the flexibility provided by not having this attribute opaque is
   worth the extra complexity it adds.  I suspect it will be a very common
   action for end users to request things like show me all the comments that
   were added since a particular date. Having this opaque does not allow for
   this.

I agree.  Can we just make this a la the ACAP attribute "modtime"?

The use of the attribute name "value" is confusing, since all
attributes have values.  (The "acl" attribute value might be something
like "username rw" or whatever.)  That is, entries in the ACAP model
are made up of a set of attribute-value pairs, and it's a little
confusing overloaded the term "value".

With that in mind, the entry "/message/comment" is currently defined
as having:

attribute			value
"acl"				?
"value"				some blob of data
"content-type"			MIME content-type
"modifiedsince"			another blob of data

The "content-type" is mentioned in 4.2.2.  Is it required?  Must
clients set it?  Must the "value" be a valid MIME type?

I think something like

attribute			value
"acl"				beats me? "r" and/or "w"?
"modtime"			modtime a la ACAP (server maintained)
"mime.version"			MIME version
"mime.content-type"		MIME content-type
"value"				body, must be 8-bit MIME
"size"				value size (server maintained)

"mime.version", "mime.content-type" should be required, and either
client must set them or they should default to some sort of UTF-8
text.

There's a problem that value could be quite large---larger
than I want to download over a modem.  A "size" attribute could help
with that, though it doesn't allow partial downloads.

Is it though that clients will completely replace the value whenever
an annotation is added?  Can "/message/comment" have subentries?
(There's one example of this, used in passing.)

If so, how can the client discover subentries, except by doing a
"/message/comment/%" search?

   Also it would probably be worth while adding some guidance to what can be
   put in the "value" attribute.  The grammar defines this as nstring, and I
   can see people using this without putting any thought into
   internationalizaton issues.  Perhaps a requirement that all text annotations
   be in UTF8?

Attribute names are already defined as UTF-8, though I'm not sure the
ABNF reflects this.

Also:

    /message/flags/redirected
    /message/flags/forwarded
    /message/flags/queued

    /body/<part-specifier>/flags/seen
    /body/<part-specifier>/flags/answered
    /body/<part-specifier>/flags/flagged

can have values of "1", "0", or NIL.  Should NIL be treated as
identical to "0", or should an annotation aware client set these to 0
as soon as it sees a message?

In fact, why are these seperate entries?  Why aren't they attributes
of the "/message/flags" entry?

Larry

From: Mike Gahrns <[email-masked]>
To: 
Cc: [email-masked]
Subject: Re: Annotate Draft (Corrected URL)
Date: Fri, 10 Mar 2000 17:53:16 -0800
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF8AFC.317D8BAA
Content-Type: text/plain;
	charset="iso-8859-1"

Re: Annotate Draft (Corrected URL)Randall Gellens writes:
>>How clients/servers are supposed to compare modifiedsince without
>>knowing its structure?
>>If I am right, then ABNF for modifiedsince (from ACAP) should be >>added.
>Clients aren't supposed to look inside the value, but only to save it
>for use in a "modifiedsince" in the next connection, so it is opaque
>to the client.
I think the flexibility provided by not having this attribute opaque is
worth the extra complexity it adds.  I suspect it will be a very common
action for end users to request things like show me all the comments that
were added since a particular date. Having this opaque does not allow for
this.

Also it would probably be worth while adding some guidance to what can be
put in the "value" attribute.  The grammar defines this as nstring, and I
can see people using this without putting any thought into
internationalizaton issues.  Perhaps a requirement that all text annotations
be in UTF8?

------_=_NextPart_001_01BF8AFC.317D8BAA
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>Re: Annotate Draft (Corrected URL)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Re: Annotate Draft (Corrected URL)Randall Gellens writes:</FONT>
<BR><FONT SIZE=2>&gt;&gt;How clients/servers are supposed to compare modifiedsince without</FONT>
<BR><FONT SIZE=2>&gt;&gt;knowing its structure?</FONT>
<BR><FONT SIZE=2>&gt;&gt;If I am right, then ABNF for modifiedsince (from ACAP) should be &gt;&gt;added.</FONT>
<BR><FONT SIZE=2>&gt;Clients aren't supposed to look inside the value, but only to save it</FONT>
<BR><FONT SIZE=2>&gt;for use in a &quot;modifiedsince&quot; in the next connection, so it is opaque</FONT>
<BR><FONT SIZE=2>&gt;to the client.</FONT>
<BR><FONT SIZE=2>I think the flexibility provided by not having this attribute opaque is</FONT>
<BR><FONT SIZE=2>worth the extra complexity it adds.&nbsp; I suspect it will be a very common</FONT>
<BR><FONT SIZE=2>action for end users to request things like show me all the comments that</FONT>
<BR><FONT SIZE=2>were added since a particular date. Having this opaque does not allow for</FONT>
<BR><FONT SIZE=2>this.</FONT>
</P>

<P><FONT SIZE=2>Also it would probably be worth while adding some guidance to what can be</FONT>
<BR><FONT SIZE=2>put in the &quot;value&quot; attribute.&nbsp; The grammar defines this as nstring, and I</FONT>
<BR><FONT SIZE=2>can see people using this without putting any thought into</FONT>
<BR><FONT SIZE=2>internationalizaton issues.&nbsp; Perhaps a requirement that all text annotations</FONT>
<BR><FONT SIZE=2>be in UTF8?</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BF8AFC.317D8BAA--

Date: Fri, 10 Mar 2000 12:55:30 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: RegExp Search Extension
To: Paul Hoffman / IMC <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 10 Mar 2000 12:02:08 -0800, Paul Hoffman / IMC wrote:
> >2) It is fully Unicode-savvy.  This also means that there will need to be
> >    hooks for locale and language.
> Locale and language are independent of Unicode. If you want those, make it
> a third bullet item.

Although you are technically correct; it's a difference that does not make a
difference, because regular expressions tie these all together.

I don't see how you can avoid having to address locale/language from the start
with regular expressions.  SORT isn't going to get away with it for much
longer.

Date: Fri, 10 Mar 2000 12:02:08 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: re: RegExp Search Extension
Sender: [email-masked]

At 10:52 AM 3/10/00 -0800, Mark Crispin wrote:
>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.

Locale and language are independent of Unicode. If you want those, make it 
a third bullet item.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 10 Mar 2000 11:45:22 -0800
To: Alexey Melnikov <[email-masked]>, Cyrus Daboo <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Annotate Draft (Corrected URL)
Cc: Randall Gellens <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:38 PM -0700 3/10/00, Alexey Melnikov wrote:

>Some comments below.
>
>>4.1 Overview
>>   
>>     The data model used in ANNOTATE is one of a uniquely named entry
>>     with a set of uniquely named attributes, each of which has a value.
>
>The sentence is correct, but it is very difficult to understand. It is
>better to split it: first describe entries and attributes.
>Than clarify that they are uniquely named.

Thanks, I'll try and make it more clear.

>
>I think that "of a uniquely named entry" should be "of a uniquely named
>entries".
>
>Also, I don't think that "data model is ... one of entries" is
>mathematically correct. This doesn't help to clarify anything. I suggest
>to remove "data model" from the sentence.
>
>>     /message/flags
>>         Defines the top-level of entries for client-use flags associated
>>         with an entire message.  All sub-entries are maintained entirely
>>         by the client.  There is no implicit change to any flag by the
>>         server.
>
>What is the relationship between /message/flags and user defined
>keywords?
>Will the later be deprecated by this extension?

Flags are more general and more useful, allowing for both standard 
interoperable names and vendor-specific ones.

>
>>4.2.2 Attribute Names
>>   
>...
>>     modifiedsince
>>         An opaque value set by the server when this entry is modified.
>>         It can be used by the client to request notification of which
>>         entries have changed since a particular point in time and is
>>         useful for disconnected/synchronisation operations. (The value
>>         is intended to be used only for comparisons within a server, not
>>         as an accurate timestamp.)
>
>acl is not described, and its format is not defined in ABNF.
>
>modifiedsince can't be "opaque", because in 5.4 you say:
>
>>     A special case exists when the "modifiedsince" attribute is used as
>>     the <attribute-name> parameter in the ANNOTATION search criterion.
>>     In this case the server matches messages when the corresponding
>  >    "modifiedsince" value is greater than the value supplied in the
>>     ANNOTATION criterion.  This allows a client, for example, to find
>>     out which messages contain annotations that have changed since the
>>     last time it updated its disconnected cache.
>
>How clients/servers are supposed to compare modifiedsince without
>knowing its structure?
>If I am right, then ABNF for modifiedsince (from ACAP) should be added.

Clients aren't supposed to look inside the value, but only to save it 
for use in a "modifiedsince" in the next connection, so it is opaque 
to the client.

>
>>     vendor.<vendor-token>
>
>Should probably be "vendor.<vendor-token>.<attribute-name>"

Yes, thank you.

>
>>5.1 ANNOTATION message data item in FETCH Command
>>   
>>     This extension adds an ANNOTATION message data item to the FETCH
>>     command.  This allows clients to retrieve annotations for a range of
>>     messages in the currently selected mailbox.
>>   
>>     ANNOTATION <entry-specifier> <attribute-specifier>
>
>Parenthesizes are missing (even if it is informal description).

Thanks.

>
>>  5.3:
>...
>>     Example:
>>         C: a STORE 1 ANNOTATION ("/message/comment" ("value" "My 
>>new comment")
>>                                  "/message/version" ("value" "1.1"))
>>     S: a OK Store complete
>>   
>>             In the above example, the entries "/message/comment" and
>>             "/message/version" are created (if not already present) and
>>             the attribute "value" is created for each entry if not
>>             already present, or replaced if they previously exist.
>
>I don't think it is a good idea to use "/message/version" that is not
>defined anywere.
>IMHO, it is better to use "/message/vendor/<vendor-token>/version"

I had planned on removing all names from examples that are not 
defined in the spec, but ran out of time.  This will be done for the 
next version.

>
>>6 Formal Syntax
>...
>>    entry-match-atom  = 1*(list-wildcards / atom-slash)
>>                        *(list-wildcards / atom-slash)
>
>Is it supposed to be just
>entry-match-atom  = 1*(list-wildcards / atom-slash)
>?
>
>Alexey

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Police Begin Campaign to Run Down Jaywalkers
--Newspaper headline

Date: Fri, 10 Mar 2000 12:38:40 -0700
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Randall Gellens <[email-masked]>, [email-masked]
Subject: Re: Annotate Draft (Corrected URL)
Sender: [email-masked]

Some comments below.

>4.1 Overview
>    
>    The data model used in ANNOTATE is one of a uniquely named entry
>    with a set of uniquely named attributes, each of which has a value.

The sentence is correct, but it is very difficult to understand. It is
better to split it: first describe entries and attributes.
Than clarify that they are uniquely named.

I think that "of a uniquely named entry" should be "of a uniquely named
entries".

Also, I don't think that "data model is ... one of entries" is
mathematically correct. This doesn't help to clarify anything. I suggest
to remove "data model" from the sentence.

>    /message/flags
>        Defines the top-level of entries for client-use flags associated
>        with an entire message.  All sub-entries are maintained entirely
>        by the client.  There is no implicit change to any flag by the
>        server.

What is the relationship between /message/flags and user defined
keywords?
Will the later be deprecated by this extension?

>4.2.2 Attribute Names
>    
...
>    modifiedsince
>        An opaque value set by the server when this entry is modified.
>        It can be used by the client to request notification of which
>        entries have changed since a particular point in time and is
>        useful for disconnected/synchronisation operations. (The value
>        is intended to be used only for comparisons within a server, not
>        as an accurate timestamp.)

acl is not described, and its format is not defined in ABNF.

modifiedsince can't be "opaque", because in 5.4 you say:

>    A special case exists when the "modifiedsince" attribute is used as
>    the <attribute-name> parameter in the ANNOTATION search criterion.
>    In this case the server matches messages when the corresponding
>    "modifiedsince" value is greater than the value supplied in the
>    ANNOTATION criterion.  This allows a client, for example, to find
>    out which messages contain annotations that have changed since the
>    last time it updated its disconnected cache.

How clients/servers are supposed to compare modifiedsince without
knowing its structure?
If I am right, then ABNF for modifiedsince (from ACAP) should be added.

>    vendor.<vendor-token>

Should probably be "vendor.<vendor-token>.<attribute-name>"

>5.1 ANNOTATION message data item in FETCH Command
>    
>    This extension adds an ANNOTATION message data item to the FETCH
>    command.  This allows clients to retrieve annotations for a range of
>    messages in the currently selected mailbox.
>    
>    ANNOTATION <entry-specifier> <attribute-specifier>

Parenthesizes are missing (even if it is informal description).

> 5.3:
...
>    Example:
>        C: a STORE 1 ANNOTATION ("/message/comment" ("value" "My new comment")
>                                 "/message/version" ("value" "1.1"))
>    S: a OK Store complete
>    
>            In the above example, the entries "/message/comment" and
>            "/message/version" are created (if not already present) and
>            the attribute "value" is created for each entry if not
>            already present, or replaced if they previously exist.

I don't think it is a good idea to use "/message/version" that is not
defined anywere.
IMHO, it is better to use "/message/vendor/<vendor-token>/version"

>6 Formal Syntax
...
>   entry-match-atom  = 1*(list-wildcards / atom-slash)
>                       *(list-wildcards / atom-slash)

Is it supposed to be just 
entry-match-atom  = 1*(list-wildcards / atom-slash)
?

Alexey

Date: Fri, 10 Mar 2000 10:52:28 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: RegExp Search Extension
To: Cyrus Daboo <[email-masked]>
cc: Paul Hoffman / IMC <[email-masked]>, Randall Gellens <[email-masked]>, [email-masked]
Sender: [email-masked]

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

The potential cost of regular expression search in IMAP is enormous.  That
cost must be kept under control.  The benefits must also justify the cost.

Date: Fri, 10 Mar 2000 13:20:53 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>
cc: Randall Gellens <[email-masked]>, [email-masked]
Subject: re: RegExp Search Extension
Sender: [email-masked]

--On Thursday, March 9, 2000 8:34 PM -0800 Mark Crispin 
<[email-masked]> 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

Date: Fri, 10 Mar 2000 09:34:17 -0800
To: [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Annotate Draft (Corrected URL)
Sender: [email-masked]

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

Date: Thu, 9 Mar 2000 21:37:06 -0800
To: Mark Crispin <[email-masked]>, Paul Hoffman / IMC <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: re: RegExp Search Extension
Cc: Randall Gellens <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Date: Thu, 9 Mar 2000 21:32:56 -0800
To: [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Annotate Draft
Sender: [email-masked]

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

Date: Thu, 9 Mar 2000 20:34:43 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: RegExp Search Extension
To: Paul Hoffman / IMC <[email-masked]>
cc: Randall Gellens <[email-masked]>, [email-masked]
Sender: [email-masked]

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?

Date: Thu, 09 Mar 2000 20:33:30 -0800
To: Mark Crispin <[email-masked]>, Randall Gellens <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: re: RegExp Search Extension
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 9 Mar 2000 20:04:20 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: RegExp Search Extension
To: Randall Gellens <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 9 Mar 2000 19:49:34 -0800
To: [email-masked]
From: Randall Gellens <[email-masked]>
Subject: RegExp Search Extension
Sender: [email-masked]

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

Date: Sun, 05 Mar 2000 14:12:32 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Formal Syntax in draft-crispin-imapv-09.txt
Sender: [email-masked]

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" /
                     "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-keys /
                     "OR" SP search-keys SP search-keys /
                     "SENTBEFORE" SP date / "SENTON" SP date /
                     "SENTSINCE" SP date / "SMALLER" SP number /
                     "UID" SP set / "UNDRAFT" / set

This requires search-keys be used in place of search-key in the search item.

Making this change allows an extension to use the following syntax to 
extend the search command:

   search-key   = imap4-search-key / my-search-key
                  ; modifies imap4 search-key (which may itself
                  ; contain search keys from other extensions)
   my-serach-key = "FOOBAR"

Specifying an extension syntax is a little harder to do without the change 
I'm suggesting.

Note that the sort extension syntax is in a convenient form for adding 
extensions. Also fetch-att makes it easy to add addition fetch items. store 
works too, though the term 'store-att-flags' could be generalised to 
'store-att'.

-- 
Cyrus

Date: Tue, 28 Mar 2000 10:39:15 +0930
From: Chris Newman <[email-masked]>
Subject: re: RegExp Search Extension
To: [email-masked]
Sender: [email-masked]

--On Thursday, March 9, 2000 20:34 -0800 Mark Crispin 
<[email-masked]> 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?

It's interesting to see how these work in the news space.  Some 
propellerhead creates a good "spam killing" regular expression and sends it 
out to a mailing list.  Typical users can copy and paste the regular 
expressions into the "regular expression" box without knowing what it 
means.  It works a lot like URLs do.

		- Chris

Date: Fri, 17 Mar 2000 12:55:57 -0500
From: Cyrus Daboo <[email-masked]>
To: Simon Josefsson <[email-masked]>, Randall Gellens <[email-masked]>
cc: [email-masked]
Subject: Re: Annotate Draft
Sender: [email-masked]

--On Friday, March 17, 2000 6:23 PM +0100 Simon Josefsson <[email-masked]> 
wrote:

> Perhaps a silly question, but, are there any intentions on extending
> this to make it possible to have annotations on mailboxes (as opposed
> to articles)?  NNTP provide a text description of groups, and people
> have asked me if IMAP could support something similar.
>
> (The usefulness of this probably only become clear when there are
> thousands of shared mailboxes. Otherwise, just choose a good
> descriptive mailbox name.)

This has been discussed in imap-ext before (probably at one of the 
meetings). I believe there was a general consensus to do mailbox 
annotations, but there was a feeling that this may need to be tied into 
changes to the LIST command (or a replacement for LIST) that some people 
felt was required. I think the best thing to do is see how message 
annotations fair, and once we've progressed to the point where people agree 
on the behaviour of that, then we can look at mailbox annotations again.

I also proposed server annotations as well, but this was less well 
received! I still think they could serve a useful purpose (they would 
likely be read-only annotations for everyone except the server admin but 
that does bring up issues with the interaction between ACLs and annotations 
- something we may have to address in message annotations too).

-- 
Cyrus

Date: Fri, 17 Mar 2000 10:55:09 -0700
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Randall Gellens <[email-masked]>, [email-masked]
Subject: Re: Annotate Draft
Sender: [email-masked]

Simon Josefsson wrote:
> 
> Randall Gellens <[email-masked]> writes:
> 
> > I've sent in the Annotate draft.
> 
> Perhaps a silly question, but, are there any intentions on extending
> this to make it possible to have annotations on mailboxes (as opposed
> to articles)?  NNTP provide a text description of groups, and people
> have asked me if IMAP could support something similar.
> 
> (The usefulness of this probably only become clear when there are
> thousands of shared mailboxes. Otherwise, just choose a good
> descriptive mailbox name.)

The consensus was to write separate draft.

Alexey

To: Randall Gellens <[email-masked]>
Cc: [email-masked]
Subject: Re: Annotate Draft
From: Simon Josefsson <[email-masked]>
Date: 17 Mar 2000 18:23:06 +0100
Lines: 12
Sender: [email-masked]

Randall Gellens <[email-masked]> writes:

> I've sent in the Annotate draft.

Perhaps a silly question, but, are there any intentions on extending
this to make it possible to have annotations on mailboxes (as opposed
to articles)?  NNTP provide a text description of groups, and people
have asked me if IMAP could support something similar.

(The usefulness of this probably only become clear when there are
thousands of shared mailboxes. Otherwise, just choose a good
descriptive mailbox name.)

Date: Thu, 16 Mar 2000 22:22:17 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: I-D ACTION:draft-daboo-imapext-view-02.txt (fwd)
Sender: [email-masked]

--==========00075517==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
Below is the IETF-Announce message for a new version of the VIEW extension 
draft. I've attached a copy of my 'changes' document to this message so you 
can see the detailed changes.

The new draft has been written so that VIEW implements the semi-dynamic 
updating mechanism discussed previously. There is still some debate 
(controversy) about whether VIEW should be semi-dynamic, dynamic or both. 
Some people feel we should only do one method to avoid making VIEW too 
complex, others feel that two would be better (via some kind of client 
initiated switch).

Right now the semi-dynamic model in the draft does allow 'dynamic' 
behaviour via VIEW NOOP and VIEW IDLE commands (new in this draft). The 
goal with these is to allow a client to get the additional 'dynamic' 
unsolicited responses only when these commands are used. Again there is 
some debate about whether VIEW NOOP and VIEW IDLE are appropriate here, or 
whether there should be a separate VIEW UPDATE command.

In any event, this issue of semi-dynamic vs dynamic is still an open topic, 
and I think is really the only major item that needs to be addressed in 
VIEW - others may feel differently of course!.

---------- Forwarded Message ----------
Date: Thursday, March 16, 2000 4:16 PM -0500
From: [email-masked]
To: IETF-Announce
Subject: I-D ACTION:draft-daboo-imapext-view-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	 Title		: IMAP VIEW Extension
	 Author(s)	: C. Daboo, M. Crispin, M. Pustilnik	
         Filename	: draft-daboo-imapext-view-02.txt
	 Pages		: 16
	 Date		: 15-Mar-00
	
The VIEW extension to the Internet Message Access Protocol [IMAP4]
permits a subset of messages in the mailbox to be processed
separately from the entire set of messages in the mailbox.  This
allows a client to restrict its view to only the messages appearing
in this set.  The subset of messages also need not be returned in
order of their sequence numbers, allowing clients to access messages
in a particular sort order.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-imapext-view-02.txt

---------- End Forwarded Message ----------

-- 
Cyrus
--==========00075517==========
Content-Type: text/plain; charset=iso-8859-1; name="changes.ml"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="changes.ml"; size=4202

View Draft Changes 01 -> 02

General
- Added VIEW NOOP and VIEW IDLE commands to allow client to receive dynamic =
updating of view state.

3 Introduction
- Added comment on interaction with IDLE command.
- Added NOOP and IDLE to list of sub-commands used by VIEW.
- Added comment about VIEW COPY requiring copy in sorted order.

4.1.1 VIEW SET
- Changed text on untagged VIEW response to point to new section 5.1 where =
its use is described in more detail.

4.1.2 VIEW <sub-command>
- Added description of VIEW COPY preserving view order.
- Added description of VIEW NOOP and VIEW IDLE commands.

5.1 Response Conditions
- New section to describe the response 'conditions' under which untagged =
responses may be sent. Also describes how clients effect a 'dynamic' view =
using VIEW NOOP and VIEW IDLE.

5.2.1 New message arrival
- Added references to section 5.1 response conditions

5.2.2 Messages moving in the view
- Added references to section 5.1 response conditions

5.4 EXPUNGE Untagged Response
- Added references to section 5.1 response conditions

6 Formal Syntax
- Added VIEW NOOP and VIEW IDLE as possible commands.

View Draft Changes 00 -> 01

General
- Added option to allow VIEW SET command arguments during a SELECT or =
EXAMINE command as agreed in Olso.
- Changed text to describe VIEW as a single command and a single response, =
with different variants.

3 Introduction
- (c) removed VIEW item in FETCH command as there is never any need to =
explicitly request it as its always returned when view is in effect.

4.1 VIEW SET Command
- Added clarification on valid sub-commands: only SEARCH for now but may =
allow SORT and THREAD in future.
- (c) changed to apply to ALL fetch responses not just unsolicited.
- (c) removed reference to VIEW item in FETCH command.
- Added (h) to clarify resetting a view using another VIEW SET.
- Added (i) to clarify cancellation of a view if SELECT, EXAMINE or CLOSE =
occur.

4.3 (was 4.2) VIEW Command
- Added statement that VIEW command is only valid when VIEW SET in effect.

5.1.1
- Removed previous restriction on not sending VIEW response when no command =
is in effect. This contradicts the requirement that VIEW responses for new =
messages must be sent after an EXISTS.

5.1.2
- Clarified restrictions on when VIEW response for moving messages can be =
sent.
- Corrected 'non-zero' to 0 in a couple of places.
- Added section on both <old> and <new> being non-zero.
- Corrected examples which had <new> and <old> values reversed.

6
- Revised to be compliant with RFC2234.
- Modified syntax to reflect VIEW as a single command and response.
- Added syntax for modified SELECT and EXAMINE commands.
- Added msg-att-dynamic for VIEW message data item in FETCH.
- Alphabetic sort of formal syntax terms.

--==========00075517==========--

From: [email-masked]
Subject: Question
To: [email-masked]
Date: Tue, 14 Mar 2000 16:38:56 -0600
Sender: [email-masked]

Hi.
I was reading about the benefits of using IMAP instead of using POP3 and
I would like to know how can I implement it using the next software.

I have a Raptor Firewall and a Lotus Notes Software installed on Windows NT
4.0 (TCP/IP)
and I have Lotus Notes 5.0.2a International Servers.

The question is:

Do you have documentation about configuring Lotus Notes clients to access
their accounts from the internet using the Raptor firewall or another?

Thanks in advance for your help.

Mario Treviño Salazar
Groupware Analyst & Email Administrator
AXTEL, SA de CV

Date: Tue, 14 Mar 2000 11:33:35 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Announcement of MailConnect 6
Sender: [email-masked]

Greetings again. IMC is pleased to announce our next testing event, 
MailConnect 6. The event will focus on IMAP4, POP3, and SMTP, and will be 
held May 31 and June 1 in San Jose, CA. Full details are available at 
<http://www.imc.org/imc-mailconnect/>.

The two days of MailConnect 6 will focus on IMAP4. IMAP4 is a 
well-established specification with new facilities promising substantial 
improvement for mobile and client/server mail environments. IMAP4 
implementations have fully emerged, although the large number of new of 
IMAP extensions have not been subjected to wide inter-vendor testing. 
MailConnect 6 will provide an opportunity for intense interoperability 
testing and repair of IMAP4 implementations.

During the previous MailConnect events, it has become clear that client 
developers need to pay more attention to the disconnected mode of IMAP. 
MailConnect is an excellent place for client and server vendors to test 
interoperability in this area. Further, IMAP is a dynamic protocol, and 
many valuable extensions have been proposed in the past year. Developers 
will want to meet with other developers at MailConnect to test their early 
implementations of these extensions.

Because most IMAP vendors also have POP3 and SMTP implementations, 
MailConnect 6 will be a good place to test them as well. A new round of 
extensions to POP have come out in the past year, and client vendors have 
expressed strong interest in testing these. Also in the past year, many 
extensions to SMTP have been standardized and deployed; these new features 
will be the focus of the SMTP testing at MailConnect 6. Specifically, 
message submission, SMTP over TLS, and SMTP authorization are likely 
candidates for participant testing.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sun, 12 Mar 2000 23:07:19 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: multi-append
To: Lawrence Greenfield <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Mon, 13 Mar 2000 01:55:41 -0500 (EST), Lawrence Greenfield wrote:
> I'm thinking about implementing MULTIAPPEND for nefarious purposes of
> my own.  I'm not sure clients really want it and I'm pretty sure I
> don't care either way.

The next version of Pine will use it.  It's a BIG win.

> However, it would be more convenient for me if there was a way for the
> client to intentionally abort the append midway through.  Currently,
> that would be possible by sending an invalid date-time or some other
> piece of bad syntax, but that seems icky.

This is a bug in the MULTIAPPEND draft document.  Thanks for pointing it out.
The way to cancel an APPEND cleanly is by giving APPEND a zero-length literal
as a message text argument.

I've fixed this bug in the document, but the ID cutoff has happened so it'll
have to wait until after IETF.

Date: Mon, 13 Mar 2000 01:55:41 -0500 (EST)
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: multi-append
Sender: [email-masked]

I'm thinking about implementing MULTIAPPEND for nefarious purposes of
my own.  I'm not sure clients really want it and I'm pretty sure I
don't care either way.

However, it would be more convenient for me if there was a way for the
client to intentionally abort the append midway through.  Currently,
that would be possible by sending an invalid date-time or some other
piece of bad syntax, but that seems icky.

I don't really need this to interoperate, but figured I might as well
bring it up.  Any good ideas of how to implement "whoops, i didn't
really want to do this append"?

Thanks,
Larry

Date: Fri, 10 Mar 2000 22:37:50 -0700
From: Alexey Melnikov <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
CC: [email-masked]
Subject: Re: Annotate Draft (Corrected URL)
Sender: [email-masked]

Lawrence's letter reminded me of another issue.
We should define interaction of ANNOTATE and ACL.
Should we use "w" right as for changing flags, or maybe another right
should be defined for annotations.

Lawrence Greenfield wrote:
> 
>    From: Mike Gahrns <[email-masked]>
>    Date: Fri, 10 Mar 2000 17:53:16 -0800
> 
>    I think the flexibility provided by not having this attribute opaque is
>    worth the extra complexity it adds.  I suspect it will be a very common
>    action for end users to request things like show me all the comments that
>    were added since a particular date. Having this opaque does not allow for
>    this.
> 
> I agree.  Can we just make this a la the ACAP attribute "modtime"?

That is what I was thinking about.

> The use of the attribute name "value" is confusing, since all
> attributes have values.  (The "acl" attribute value might be something
> like "username rw" or whatever.)  That is, entries in the ACAP model
> are made up of a set of attribute-value pairs, and it's a little
> confusing overloaded the term "value".
> 
> With that in mind, the entry "/message/comment" is currently defined
> as having:
> 
> attribute                       value
> "acl"                           ?
> "value"                         some blob of data
> "content-type"                  MIME content-type
> "modifiedsince"                 another blob of data
> 
> The "content-type" is mentioned in 4.2.2.  Is it required?  Must
> clients set it?  Must the "value" be a valid MIME type?

I think it should be optional and it must be valid MIME type (at least
something in the form <x>/<y>)

> 
> I think something like
> 
> attribute                       value
> "acl"                           beats me? "r" and/or "w"?
> "modtime"                       modtime a la ACAP (server maintained)
> "mime.version"                  MIME version
> "mime.content-type"             MIME content-type
> "value"                         body, must be 8-bit MIME
> "size"                          value size (server maintained)
> 
> "mime.version", "mime.content-type" should be required, and either
> client must set them or they should default to some sort of UTF-8
> text.

Why do you need mime.version? It is always "1.0" ;-)

> There's a problem that value could be quite large---larger
> than I want to download over a modem.  A "size" attribute could help
> with that, though it doesn't allow partial downloads.

Read-only size attribute would be useful for clients.

Alexey

Date: Fri, 10 Mar 2000 21:51:10 -0500 (EST)
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: Re: Annotate Draft (Corrected URL)
Sender: [email-masked]

   From: Mike Gahrns <[email-masked]>
   Date: Fri, 10 Mar 2000 17:53:16 -0800

   I think the flexibility provided by not having this attribute opaque is
   worth the extra complexity it adds.  I suspect it will be a very common
   action for end users to request things like show me all the comments that
   were added since a particular date. Having this opaque does not allow for
   this.

I agree.  Can we just make this a la the ACAP attribute "modtime"?

The use of the attribute name "value" is confusing, since all
attributes have values.  (The "acl" attribute value might be something
like "username rw" or whatever.)  That is, entries in the ACAP model
are made up of a set of attribute-value pairs, and it's a little
confusing overloaded the term "value".

With that in mind, the entry "/message/comment" is currently defined
as having:

attribute			value
"acl"				?
"value"				some blob of data
"content-type"			MIME content-type
"modifiedsince"			another blob of data

The "content-type" is mentioned in 4.2.2.  Is it required?  Must
clients set it?  Must the "value" be a valid MIME type?

I think something like

attribute			value
"acl"				beats me? "r" and/or "w"?
"modtime"			modtime a la ACAP (server maintained)
"mime.version"			MIME version
"mime.content-type"		MIME content-type
"value"				body, must be 8-bit MIME
"size"				value size (server maintained)

"mime.version", "mime.content-type" should be required, and either
client must set them or they should default to some sort of UTF-8
text.

There's a problem that value could be quite large---larger
than I want to download over a modem.  A "size" attribute could help
with that, though it doesn't allow partial downloads.

Is it though that clients will completely replace the value whenever
an annotation is added?  Can "/message/comment" have subentries?
(There's one example of this, used in passing.)

If so, how can the client discover subentries, except by doing a
"/message/comment/%" search?

   Also it would probably be worth while adding some guidance to what can be
   put in the "value" attribute.  The grammar defines this as nstring, and I
   can see people using this without putting any thought into
   internationalizaton issues.  Perhaps a requirement that all text annotations
   be in UTF8?

Attribute names are already defined as UTF-8, though I'm not sure the
ABNF reflects this.

Also:

    /message/flags/redirected
    /message/flags/forwarded
    /message/flags/queued

    /body/<part-specifier>/flags/seen
    /body/<part-specifier>/flags/answered
    /body/<part-specifier>/flags/flagged

can have values of "1", "0", or NIL.  Should NIL be treated as
identical to "0", or should an annotation aware client set these to 0
as soon as it sees a message?

In fact, why are these seperate entries?  Why aren't they attributes
of the "/message/flags" entry?

Larry

From: Mike Gahrns <[email-masked]>
To: 
Cc: [email-masked]
Subject: Re: Annotate Draft (Corrected URL)
Date: Fri, 10 Mar 2000 17:53:16 -0800
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF8AFC.317D8BAA
Content-Type: text/plain;
	charset="iso-8859-1"

Re: Annotate Draft (Corrected URL)Randall Gellens writes:
>>How clients/servers are supposed to compare modifiedsince without
>>knowing its structure?
>>If I am right, then ABNF for modifiedsince (from ACAP) should be >>added.
>Clients aren't supposed to look inside the value, but only to save it
>for use in a "modifiedsince" in the next connection, so it is opaque
>to the client.
I think the flexibility provided by not having this attribute opaque is
worth the extra complexity it adds.  I suspect it will be a very common
action for end users to request things like show me all the comments that
were added since a particular date. Having this opaque does not allow for
this.

Also it would probably be worth while adding some guidance to what can be
put in the "value" attribute.  The grammar defines this as nstring, and I
can see people using this without putting any thought into
internationalizaton issues.  Perhaps a requirement that all text annotations
be in UTF8?

------_=_NextPart_001_01BF8AFC.317D8BAA
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>Re: Annotate Draft (Corrected URL)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Re: Annotate Draft (Corrected URL)Randall Gellens writes:</FONT>
<BR><FONT SIZE=2>&gt;&gt;How clients/servers are supposed to compare modifiedsince without</FONT>
<BR><FONT SIZE=2>&gt;&gt;knowing its structure?</FONT>
<BR><FONT SIZE=2>&gt;&gt;If I am right, then ABNF for modifiedsince (from ACAP) should be &gt;&gt;added.</FONT>
<BR><FONT SIZE=2>&gt;Clients aren't supposed to look inside the value, but only to save it</FONT>
<BR><FONT SIZE=2>&gt;for use in a &quot;modifiedsince&quot; in the next connection, so it is opaque</FONT>
<BR><FONT SIZE=2>&gt;to the client.</FONT>
<BR><FONT SIZE=2>I think the flexibility provided by not having this attribute opaque is</FONT>
<BR><FONT SIZE=2>worth the extra complexity it adds.&nbsp; I suspect it will be a very common</FONT>
<BR><FONT SIZE=2>action for end users to request things like show me all the comments that</FONT>
<BR><FONT SIZE=2>were added since a particular date. Having this opaque does not allow for</FONT>
<BR><FONT SIZE=2>this.</FONT>
</P>

<P><FONT SIZE=2>Also it would probably be worth while adding some guidance to what can be</FONT>
<BR><FONT SIZE=2>put in the &quot;value&quot; attribute.&nbsp; The grammar defines this as nstring, and I</FONT>
<BR><FONT SIZE=2>can see people using this without putting any thought into</FONT>
<BR><FONT SIZE=2>internationalizaton issues.&nbsp; Perhaps a requirement that all text annotations</FONT>
<BR><FONT SIZE=2>be in UTF8?</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BF8AFC.317D8BAA--

Date: Fri, 10 Mar 2000 12:55:30 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: RegExp Search Extension
To: Paul Hoffman / IMC <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 10 Mar 2000 12:02:08 -0800, Paul Hoffman / IMC wrote:
> >2) It is fully Unicode-savvy.  This also means that there will need to be
> >    hooks for locale and language.
> Locale and language are independent of Unicode. If you want those, make it
> a third bullet item.

Although you are technically correct; it's a difference that does not make a
difference, because regular expressions tie these all together.

I don't see how you can avoid having to address locale/language from the start
with regular expressions.  SORT isn't going to get away with it for much
longer.

Date: Fri, 10 Mar 2000 12:02:08 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: re: RegExp Search Extension
Sender: [email-masked]

At 10:52 AM 3/10/00 -0800, Mark Crispin wrote:
>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.

Locale and language are independent of Unicode. If you want those, make it 
a third bullet item.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 10 Mar 2000 11:45:22 -0800
To: Alexey Melnikov <[email-masked]>, Cyrus Daboo <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Annotate Draft (Corrected URL)
Cc: Randall Gellens <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:38 PM -0700 3/10/00, Alexey Melnikov wrote:

>Some comments below.
>
>>4.1 Overview
>>   
>>     The data model used in ANNOTATE is one of a uniquely named entry
>>     with a set of uniquely named attributes, each of which has a value.
>
>The sentence is correct, but it is very difficult to understand. It is
>better to split it: first describe entries and attributes.
>Than clarify that they are uniquely named.

Thanks, I'll try and make it more clear.

>
>I think that "of a uniquely named entry" should be "of a uniquely named
>entries".
>
>Also, I don't think that "data model is ... one of entries" is
>mathematically correct. This doesn't help to clarify anything. I suggest
>to remove "data model" from the sentence.
>
>>     /message/flags
>>         Defines the top-level of entries for client-use flags associated
>>         with an entire message.  All sub-entries are maintained entirely
>>         by the client.  There is no implicit change to any flag by the
>>         server.
>
>What is the relationship between /message/flags and user defined
>keywords?
>Will the later be deprecated by this extension?

Flags are more general and more useful, allowing for both standard 
interoperable names and vendor-specific ones.

>
>>4.2.2 Attribute Names
>>   
>...
>>     modifiedsince
>>         An opaque value set by the server when this entry is modified.
>>         It can be used by the client to request notification of which
>>         entries have changed since a particular point in time and is
>>         useful for disconnected/synchronisation operations. (The value
>>         is intended to be used only for comparisons within a server, not
>>         as an accurate timestamp.)
>
>acl is not described, and its format is not defined in ABNF.
>
>modifiedsince can't be "opaque", because in 5.4 you say:
>
>>     A special case exists when the "modifiedsince" attribute is used as
>>     the <attribute-name> parameter in the ANNOTATION search criterion.
>>     In this case the server matches messages when the corresponding
>  >    "modifiedsince" value is greater than the value supplied in the
>>     ANNOTATION criterion.  This allows a client, for example, to find
>>     out which messages contain annotations that have changed since the
>>     last time it updated its disconnected cache.
>
>How clients/servers are supposed to compare modifiedsince without
>knowing its structure?
>If I am right, then ABNF for modifiedsince (from ACAP) should be added.

Clients aren't supposed to look inside the value, but only to save it 
for use in a "modifiedsince" in the next connection, so it is opaque 
to the client.

>
>>     vendor.<vendor-token>
>
>Should probably be "vendor.<vendor-token>.<attribute-name>"

Yes, thank you.

>
>>5.1 ANNOTATION message data item in FETCH Command
>>   
>>     This extension adds an ANNOTATION message data item to the FETCH
>>     command.  This allows clients to retrieve annotations for a range of
>>     messages in the currently selected mailbox.
>>   
>>     ANNOTATION <entry-specifier> <attribute-specifier>
>
>Parenthesizes are missing (even if it is informal description).

Thanks.

>
>>  5.3:
>...
>>     Example:
>>         C: a STORE 1 ANNOTATION ("/message/comment" ("value" "My 
>>new comment")
>>                                  "/message/version" ("value" "1.1"))
>>     S: a OK Store complete
>>   
>>             In the above example, the entries "/message/comment" and
>>             "/message/version" are created (if not already present) and
>>             the attribute "value" is created for each entry if not
>>             already present, or replaced if they previously exist.
>
>I don't think it is a good idea to use "/message/version" that is not
>defined anywere.
>IMHO, it is better to use "/message/vendor/<vendor-token>/version"

I had planned on removing all names from examples that are not 
defined in the spec, but ran out of time.  This will be done for the 
next version.

>
>>6 Formal Syntax
>...
>>    entry-match-atom  = 1*(list-wildcards / atom-slash)
>>                        *(list-wildcards / atom-slash)
>
>Is it supposed to be just
>entry-match-atom  = 1*(list-wildcards / atom-slash)
>?
>
>Alexey

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Police Begin Campaign to Run Down Jaywalkers
--Newspaper headline

Date: Fri, 10 Mar 2000 12:38:40 -0700
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Randall Gellens <[email-masked]>, [email-masked]
Subject: Re: Annotate Draft (Corrected URL)
Sender: [email-masked]

Some comments below.

>4.1 Overview
>    
>    The data model used in ANNOTATE is one of a uniquely named entry
>    with a set of uniquely named attributes, each of which has a value.

The sentence is correct, but it is very difficult to understand. It is
better to split it: first describe entries and attributes.
Than clarify that they are uniquely named.

I think that "of a uniquely named entry" should be "of a uniquely named
entries".

Also, I don't think that "data model is ... one of entries" is
mathematically correct. This doesn't help to clarify anything. I suggest
to remove "data model" from the sentence.

>    /message/flags
>        Defines the top-level of entries for client-use flags associated
>        with an entire message.  All sub-entries are maintained entirely
>        by the client.  There is no implicit change to any flag by the
>        server.

What is the relationship between /message/flags and user defined
keywords?
Will the later be deprecated by this extension?

>4.2.2 Attribute Names
>    
...
>    modifiedsince
>        An opaque value set by the server when this entry is modified.
>        It can be used by the client to request notification of which
>        entries have changed since a particular point in time and is
>        useful for disconnected/synchronisation operations. (The value
>        is intended to be used only for comparisons within a server, not
>        as an accurate timestamp.)

acl is not described, and its format is not defined in ABNF.

modifiedsince can't be "opaque", because in 5.4 you say:

>    A special case exists when the "modifiedsince" attribute is used as
>    the <attribute-name> parameter in the ANNOTATION search criterion.
>    In this case the server matches messages when the corresponding
>    "modifiedsince" value is greater than the value supplied in the
>    ANNOTATION criterion.  This allows a client, for example, to find
>    out which messages contain annotations that have changed since the
>    last time it updated its disconnected cache.

How clients/servers are supposed to compare modifiedsince without
knowing its structure?
If I am right, then ABNF for modifiedsince (from ACAP) should be added.

>    vendor.<vendor-token>

Should probably be "vendor.<vendor-token>.<attribute-name>"

>5.1 ANNOTATION message data item in FETCH Command
>    
>    This extension adds an ANNOTATION message data item to the FETCH
>    command.  This allows clients to retrieve annotations for a range of
>    messages in the currently selected mailbox.
>    
>    ANNOTATION <entry-specifier> <attribute-specifier>

Parenthesizes are missing (even if it is informal description).

> 5.3:
...
>    Example:
>        C: a STORE 1 ANNOTATION ("/message/comment" ("value" "My new comment")
>                                 "/message/version" ("value" "1.1"))
>    S: a OK Store complete
>    
>            In the above example, the entries "/message/comment" and
>            "/message/version" are created (if not already present) and
>            the attribute "value" is created for each entry if not
>            already present, or replaced if they previously exist.

I don't think it is a good idea to use "/message/version" that is not
defined anywere.
IMHO, it is better to use "/message/vendor/<vendor-token>/version"

>6 Formal Syntax
...
>   entry-match-atom  = 1*(list-wildcards / atom-slash)
>                       *(list-wildcards / atom-slash)

Is it supposed to be just 
entry-match-atom  = 1*(list-wildcards / atom-slash)
?

Alexey

Date: Fri, 10 Mar 2000 10:52:28 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: RegExp Search Extension
To: Cyrus Daboo <[email-masked]>
cc: Paul Hoffman / IMC <[email-masked]>, Randall Gellens <[email-masked]>, [email-masked]
Sender: [email-masked]

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

The potential cost of regular expression search in IMAP is enormous.  That
cost must be kept under control.  The benefits must also justify the cost.

Date: Fri, 10 Mar 2000 13:20:53 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>
cc: Randall Gellens <[email-masked]>, [email-masked]
Subject: re: RegExp Search Extension
Sender: [email-masked]

--On Thursday, March 9, 2000 8:34 PM -0800 Mark Crispin 
<[email-masked]> 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

Date: Fri, 10 Mar 2000 09:34:17 -0800
To: [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Annotate Draft (Corrected URL)
Sender: [email-masked]

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

Date: Thu, 9 Mar 2000 21:37:06 -0800
To: Mark Crispin <[email-masked]>, Paul Hoffman / IMC <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: re: RegExp Search Extension
Cc: Randall Gellens <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Date: Thu, 9 Mar 2000 21:32:56 -0800
To: [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Annotate Draft
Sender: [email-masked]

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

Date: Thu, 9 Mar 2000 20:34:43 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: RegExp Search Extension
To: Paul Hoffman / IMC <[email-masked]>
cc: Randall Gellens <[email-masked]>, [email-masked]
Sender: [email-masked]

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?

Date: Thu, 09 Mar 2000 20:33:30 -0800
To: Mark Crispin <[email-masked]>, Randall Gellens <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: re: RegExp Search Extension
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 9 Mar 2000 20:04:20 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: RegExp Search Extension
To: Randall Gellens <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 9 Mar 2000 19:49:34 -0800
To: [email-masked]
From: Randall Gellens <[email-masked]>
Subject: RegExp Search Extension
Sender: [email-masked]

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

Date: Sun, 05 Mar 2000 14:12:32 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Formal Syntax in draft-crispin-imapv-09.txt
Sender: [email-masked]

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" /
                     "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-keys /
                     "OR" SP search-keys SP search-keys /
                     "SENTBEFORE" SP date / "SENTON" SP date /
                     "SENTSINCE" SP date / "SMALLER" SP number /
                     "UID" SP set / "UNDRAFT" / set

This requires search-keys be used in place of search-key in the search item.

Making this change allows an extension to use the following syntax to 
extend the search command:

   search-key   = imap4-search-key / my-search-key
                  ; modifies imap4 search-key (which may itself
                  ; contain search keys from other extensions)
   my-serach-key = "FOOBAR"

Specifying an extension syntax is a little harder to do without the change 
I'm suggesting.

Note that the sort extension syntax is in a convenient form for adding 
extensions. Also fetch-att makes it easy to add addition fetch items. store 
works too, though the term 'store-att-flags' could be generalised to 
'store-att'.

-- 
Cyrus