Received: by ns.secondary.com (8.9.3/8.9.3) id RAA19994 for ietf-imapext-bks; Mon, 27 Mar 2000 17:09:10 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19990 for ; Mon, 27 Mar 2000 17:09:09 -0800 (PST) Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V6.0-24 #9441) with ESMTPS id <01JNJ9XBYRP29KMVJF@INNOSOFT.COM> for ietf-imapext@imc.org; Mon, 27 Mar 2000 17:10:27 -0800 (PST) Received: from CONVERSION-DAEMON.elvira.innosoft.com by elvira.innosoft.com (PMDF V6.0-23 #43970) id <0FS300L01XWK22@elvira.innosoft.com> for ietf-imapext@imc.org; Mon, 27 Mar 2000 17:09:56 -0800 (PST) Received: from dhcp-192-33.ietf.connect.com.au (dhcp-192-33.ietf.connect.com.au [169.208.192.33]) by elvira.innosoft.com (PMDF V6.0-23 #43970) with ESMTPA id <0FS30020EXWGVR@elvira.innosoft.com> for ietf-imapext@imc.org; Mon, 27 Mar 2000 17:09:56 -0800 (PST) Date: Tue, 28 Mar 2000 10:39:15 +0930 From: Chris Newman Subject: re: RegExp Search Extension In-reply-to: To: ietf-imapext@imc.org Message-id: <567618.3163228755@dhcp-192-33.ietf.connect.com.au> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0b12 (MacOS) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Thursday, March 9, 2000 20:34 -0800 Mark Crispin 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 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18669 for ietf-imapext-bks; Fri, 17 Mar 2000 09:54:54 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18664 for ; Fri, 17 Mar 2000 09:54:50 -0800 (PST) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA15227; Fri, 17 Mar 2000 12:55:16 -0500 (EST) Date: Fri, 17 Mar 2000 12:55:57 -0500 From: Cyrus Daboo To: Simon Josefsson , Randall Gellens cc: ietf-imapext@imc.org Subject: Re: Annotate Draft Message-ID: <842682.3162286557@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.0.0b12 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, March 17, 2000 6:23 PM +0100 Simon Josefsson 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 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18657 for ietf-imapext-bks; Fri, 17 Mar 2000 09:54:44 -0800 (PST) Received: from demo.esys.ca ([207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18653 for ; Fri, 17 Mar 2000 09:54:42 -0800 (PST) Received: from messagingdirect.com (dhcp198-53.esys.ca [198.161.92.53]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id KAA13720; Fri, 17 Mar 2000 10:53:50 -0700 Message-ID: <38D2717D.48F4978E@messagingdirect.com> Date: Fri, 17 Mar 2000 10:55:09 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Josefsson CC: Randall Gellens , ietf-imapext@imc.org Subject: Re: Annotate Draft References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson wrote: > > Randall Gellens 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 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17926 for ietf-imapext-bks; Fri, 17 Mar 2000 09:21:54 -0800 (PST) Received: from badis.pdc.kth.se (badis.pdc.kth.se [130.237.221.45]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17921 for ; Fri, 17 Mar 2000 09:21:52 -0800 (PST) Received: (from jas@localhost) by badis.pdc.kth.se (8.10.0/8.10.0) id e2HHN7l03655; Fri, 17 Mar 2000 18:23:07 +0100 To: Randall Gellens Cc: ietf-imapext@imc.org Subject: Re: Annotate Draft References: In-Reply-To: Randall Gellens's message of "Thu, 9 Mar 2000 21:32:56 -0800" From: Simon Josefsson Date: 17 Mar 2000 18:23:06 +0100 Message-ID: Lines: 12 User-Agent: Gnus/5.0804 (Gnus v5.8.4) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Randall Gellens 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.) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA04080 for ietf-imapext-bks; Thu, 16 Mar 2000 19:21:07 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA04063 for ; Thu, 16 Mar 2000 19:20:56 -0800 (PST) Received: from gruel133.ppp.andrew.cmu.edu (GRUEL133.PPP.ANDREW.CMU.EDU [128.2.60.133]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id WAA13051 for ; Thu, 16 Mar 2000 22:21:31 -0500 (EST) Date: Thu, 16 Mar 2000 22:22:17 -0500 From: Cyrus Daboo To: IMAP Extensions WG Subject: I-D ACTION:draft-daboo-imapext-view-02.txt (fwd) Message-ID: <58651.3162234137@gruel133.ppp.andrew.cmu.edu> X-Mailer: Mulberry/2.0.0b12 (MacOS) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========00075517==========" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==========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: Internet-Drafts@ietf.org 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 - 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 and being non-zero. - Corrected examples which had and 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==========-- Received: by ns.secondary.com (8.9.3/8.9.3) id OAA19032 for ietf-imapext-bks; Tue, 14 Mar 2000 14:53:23 -0800 (PST) Received: from assw1s01.axtel.com.mx (assw1s01.axtel.com.mx [148.244.73.3]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA19027 for ; Tue, 14 Mar 2000 14:53:21 -0800 (PST) From: mtrevino@axtel.com.mx Received: from GWOAMYCONT01 by assw1s01.axtel.com.mx via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 14 Mar 2000 22:56:11 UT Subject: Question To: mtrevino@axtel.com.mx X-Mailer: Lotus Notes Release 5.0.2a (Intl) 23 November 1999 Message-ID: Date: Tue, 14 Mar 2000 16:38:56 -0600 X-MIMETrack: Serialize by Router on GWOAMYCONT01/TELINOR(Release 5.0.2a (Intl)|23 November 1999) at 03/14/2000 04:49:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA19029 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA15395 for ietf-imapext-bks; Tue, 14 Mar 2000 11:35:53 -0800 (PST) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15377; Tue, 14 Mar 2000 11:35:49 -0800 (PST) Message-Id: <4.3.2.20000314113200.00a792d0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 14 Mar 2000 11:33:35 -0800 To: imap@u.washington.edu, ietf-imapext@imc.org From: Paul Hoffman / IMC Subject: Announcement of MailConnect 6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 . 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 Received: by ns.secondary.com (8.9.3/8.9.3) id XAA03280 for ietf-imapext-bks; Sun, 12 Mar 2000 23:14:59 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (senf@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA03274 for ; Sun, 12 Mar 2000 23:14:58 -0800 (PST) Date: Sun, 12 Mar 2000 23:07:19 -0800 (PST) From: Mark Crispin Subject: re: multi-append To: Lawrence Greenfield cc: ietf-imapext@imc.org In-Reply-To: <200003130655.BAA10820@smtp1.andrew.cmu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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. Received: by ns.secondary.com (8.9.3/8.9.3) id WAA03027 for ietf-imapext-bks; Sun, 12 Mar 2000 22:54:42 -0800 (PST) Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA03023 for ; Sun, 12 Mar 2000 22:54:41 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp1.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id BAA10820; Mon, 13 Mar 2000 01:55:41 -0500 (EST) Date: Mon, 13 Mar 2000 01:55:41 -0500 (EST) Message-Id: <200003130655.BAA10820@smtp1.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: ietf-imapext@imc.org Subject: multi-append Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA13112 for ietf-imapext-bks; Fri, 10 Mar 2000 21:37:13 -0800 (PST) Received: from demo.esys.ca ([207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA13107 for ; Fri, 10 Mar 2000 21:37:12 -0800 (PST) Received: from messagingdirect.com (2-103-edm.dial.worldgate.ca [207.167.2.103]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id WAA03047; Fri, 10 Mar 2000 22:36:41 -0700 Message-ID: <38C9DBAE.1BB7BED@messagingdirect.com> Date: Fri, 10 Mar 2000 22:37:50 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Greenfield CC: ietf-imapext@imc.org Subject: Re: Annotate Draft (Corrected URL) References: <000a01bf8afc$91704930$f3fd3b9d@redmond.corp.microsoft.com> <200003110251.VAA02267@smtp3.andrew.cmu.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 > 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 /) > > 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 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA05568 for ietf-imapext-bks; Fri, 10 Mar 2000 18:50:31 -0800 (PST) Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA05562 for ; Fri, 10 Mar 2000 18:50:29 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id VAA02267; Fri, 10 Mar 2000 21:51:10 -0500 (EST) Date: Fri, 10 Mar 2000 21:51:10 -0500 (EST) Message-Id: <200003110251.VAA02267@smtp3.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: ietf-imapext@imc.org In-reply-to: <000a01bf8afc$91704930$f3fd3b9d@redmond.corp.microsoft.com> Subject: Re: Annotate Draft (Corrected URL) References: <000a01bf8afc$91704930$f3fd3b9d@redmond.corp.microsoft.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Mike Gahrns 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//flags/seen /body//flags/answered /body//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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA01244 for ietf-imapext-bks; Fri, 10 Mar 2000 17:52:40 -0800 (PST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA01240 for ; Fri, 10 Mar 2000 17:52:39 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 Mar 2000 17:50:36 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Mar 2000 17:50:36 -0800 Message-ID: <000a01bf8afc$91704930$f3fd3b9d@redmond.corp.microsoft.com> From: Mike Gahrns To: Cc: ietf-imapext@imc.org Subject: Re: Annotate Draft (Corrected URL) Date: Fri, 10 Mar 2000 17:53:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8AFC.317D8BAA" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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" Re: Annotate Draft (Corrected URL)

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-- Received: by ns.secondary.com (8.9.3/8.9.3) id NAA27137 for ietf-imapext-bks; Fri, 10 Mar 2000 13:06:51 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (pell@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27132; Fri, 10 Mar 2000 13:06:49 -0800 (PST) Date: Fri, 10 Mar 2000 12:55:30 -0800 (PST) From: Mark Crispin Subject: re: RegExp Search Extension To: Paul Hoffman / IMC cc: ietf-imapext@imc.org In-Reply-To: <4.3.2.20000310120034.00bd4b90@mail.imc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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. Received: by ns.secondary.com (8.9.3/8.9.3) id MAA26318 for ietf-imapext-bks; Fri, 10 Mar 2000 12:01:06 -0800 (PST) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26314 for ; Fri, 10 Mar 2000 12:01:04 -0800 (PST) Message-Id: <4.3.2.20000310120034.00bd4b90@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 10 Mar 2000 12:02:08 -0800 To: ietf-imapext@imc.org From: Paul Hoffman / IMC Subject: re: RegExp Search Extension In-Reply-To: References: <729188.3161683253@socrates.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA26102 for ietf-imapext-bks; Fri, 10 Mar 2000 11:45:50 -0800 (PST) Received: from odd.qualcomm.com (odd.qualcomm.com [129.46.2.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26098 for ; Fri, 10 Mar 2000 11:45:48 -0800 (PST) Received: from 129.46.86.92 (primemover-client27.qualcomm.com [129.46.86.92]) by odd.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id LAA21698; Fri, 10 Mar 2000 11:46:33 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <38C94F40.E33B5F87@messagingdirect.com> References: <873334.3161685650@socrates.cyrusoft.com> <38C94F40.E33B5F87@messagingdirect.com> X-Mailer: QUALCOMM Eudora Pro v4.2 for Macintosh Date: Fri, 10 Mar 2000 11:45:22 -0800 To: Alexey Melnikov , Cyrus Daboo From: Randall Gellens Subject: Re: Annotate Draft (Corrected URL) Cc: Randall Gellens , ietf-imapext@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: v1.0b12 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 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. > >Should probably be "vendor.." 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 > >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//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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA25910 for ietf-imapext-bks; Fri, 10 Mar 2000 11:33:50 -0800 (PST) Received: from demo.esys.ca ([207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25906 for ; Fri, 10 Mar 2000 11:33:49 -0800 (PST) Received: from messagingdirect.com (dhcp198-53.esys.ca [198.161.92.53]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id MAA02284; Fri, 10 Mar 2000 12:32:57 -0700 Message-ID: <38C94F40.E33B5F87@messagingdirect.com> Date: Fri, 10 Mar 2000 12:38:40 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cyrus Daboo CC: Randall Gellens , ietf-imapext@imc.org Subject: Re: Annotate Draft (Corrected URL) References: <873334.3161685650@socrates.cyrusoft.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 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. Should probably be "vendor.." >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 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//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 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA25676 for ietf-imapext-bks; Fri, 10 Mar 2000 11:14:13 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (dak@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25671; Fri, 10 Mar 2000 11:14:12 -0800 (PST) Date: Fri, 10 Mar 2000 10:52:28 -0800 (PST) From: Mark Crispin Subject: re: RegExp Search Extension To: Cyrus Daboo cc: Paul Hoffman / IMC , Randall Gellens , ietf-imapext@imc.org In-Reply-To: <729188.3161683253@socrates.cyrusoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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. Received: by ns.secondary.com (8.9.3/8.9.3) id KAA24955 for ietf-imapext-bks; Fri, 10 Mar 2000 10:20:09 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24950; Fri, 10 Mar 2000 10:20:07 -0800 (PST) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA01216; Fri, 10 Mar 2000 13:20:14 -0500 (EST) Date: Fri, 10 Mar 2000 13:20:53 -0500 From: Cyrus Daboo To: Mark Crispin , "Paul Hoffman / IMC" cc: Randall Gellens , ietf-imapext@imc.org Subject: re: RegExp Search Extension Message-ID: <729188.3161683253@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.0.0b11 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Thursday, March 9, 2000 8:34 PM -0800 Mark Crispin 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 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA24309 for ietf-imapext-bks; Fri, 10 Mar 2000 09:34:12 -0800 (PST) Received: from jittlov.qualcomm.com (jittlov.qualcomm.com [129.46.50.79]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24305 for ; Fri, 10 Mar 2000 09:34:11 -0800 (PST) Received: from 129.46.86.92 (primemover-client27.qualcomm.com [129.46.86.92]) by jittlov.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id JAA19493 for ; Fri, 10 Mar 2000 09:34:59 -0800 (PST) Mime-Version: 1.0 Message-Id: X-Mailer: QUALCOMM Eudora Pro v4.2 for Macintosh Date: Fri, 10 Mar 2000 09:34:17 -0800 To: ietf-imapext@imc.org From: Randall Gellens Subject: Annotate Draft (Corrected URL) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: v1.0b12 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [[[ 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 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA25591 for ietf-imapext-bks; Thu, 9 Mar 2000 21:38:37 -0800 (PST) Received: from mail1.qualcomm.com (mail1.qualcomm.com [129.46.2.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25586; Thu, 9 Mar 2000 21:38:36 -0800 (PST) Received: from 129.46.86.67 (primemover-client02.qualcomm.com [129.46.86.67]) by mail1.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id VAA00315; Thu, 9 Mar 2000 21:39:17 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: QUALCOMM Eudora Pro v4.2 for Macintosh Date: Thu, 9 Mar 2000 21:37:06 -0800 To: Mark Crispin , Paul Hoffman / IMC From: Randall Gellens Subject: re: RegExp Search Extension Cc: Randall Gellens , ietf-imapext@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: v1.0b12 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA25581 for ietf-imapext-bks; Thu, 9 Mar 2000 21:38:26 -0800 (PST) Received: from mail1.qualcomm.com (mail1.qualcomm.com [129.46.2.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25577 for ; Thu, 9 Mar 2000 21:38:25 -0800 (PST) Received: from 129.46.86.67 (primemover-client02.qualcomm.com [129.46.86.67]) by mail1.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id VAA00310 for ; Thu, 9 Mar 2000 21:39:14 -0800 (PST) Mime-Version: 1.0 Message-Id: X-Mailer: QUALCOMM Eudora Pro v4.2 for Macintosh Date: Thu, 9 Mar 2000 21:32:56 -0800 To: ietf-imapext@imc.org From: Randall Gellens Subject: Annotate Draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: v1.0b12 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 -- 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 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA22745 for ietf-imapext-bks; Thu, 9 Mar 2000 20:35:46 -0800 (PST) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22740; Thu, 9 Mar 2000 20:35:45 -0800 (PST) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id UAA28037; Thu, 9 Mar 2000 20:36:34 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (grid@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id UAA25509; Thu, 9 Mar 2000 20:36:34 -0800 Date: Thu, 9 Mar 2000 20:34:43 -0800 (PST) From: Mark Crispin Subject: re: RegExp Search Extension To: Paul Hoffman / IMC cc: Randall Gellens , ietf-imapext@imc.org In-Reply-To: <4.3.2.20000309203146.00e20180@mail.imc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 . 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? Received: by ns.secondary.com (8.9.3/8.9.3) id UAA22620 for ietf-imapext-bks; Thu, 9 Mar 2000 20:32:43 -0800 (PST) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22616; Thu, 9 Mar 2000 20:32:40 -0800 (PST) Message-Id: <4.3.2.20000309203146.00e20180@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 09 Mar 2000 20:33:30 -0800 To: Mark Crispin , Randall Gellens From: Paul Hoffman / IMC Subject: re: RegExp Search Extension Cc: ietf-imapext@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 . It is well on its way to making it into a future version of the Unicode Standard. --Paul Hoffman, Director --Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id UAA21102 for ietf-imapext-bks; Thu, 9 Mar 2000 20:07:52 -0800 (PST) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA21096 for ; Thu, 9 Mar 2000 20:07:51 -0800 (PST) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id UAA26868; Thu, 9 Mar 2000 20:08:39 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (btik@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id UAA26301; Thu, 9 Mar 2000 20:08:39 -0800 Date: Thu, 9 Mar 2000 20:04:20 -0800 (PST) From: Mark Crispin Subject: re: RegExp Search Extension To: Randall Gellens cc: ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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... Received: by ns.secondary.com (8.9.3/8.9.3) id TAA20453 for ietf-imapext-bks; Thu, 9 Mar 2000 19:56:36 -0800 (PST) Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA20448 for ; Thu, 9 Mar 2000 19:56:34 -0800 (PST) Received: from 129.46.242.106 (randy-mac.qualcomm.com [129.46.242.106]) by illyana.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id TAA15518 for ; Thu, 9 Mar 2000 19:57:19 -0800 (PST) Mime-Version: 1.0 Message-Id: X-Mailer: QUALCOMM Eudora Pro v4.3.1 for Macintosh Date: Thu, 9 Mar 2000 19:49:34 -0800 To: ietf-imapext@imc.org From: Randall Gellens Subject: RegExp Search Extension Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: v1.0b12 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 . 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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA03667 for ietf-imapext-bks; Sun, 5 Mar 2000 11:23:20 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03654 for ; Sun, 5 Mar 2000 11:23:09 -0800 (PST) Received: from groats90.ppp.andrew.cmu.edu (GROATS90.PPP.ANDREW.CMU.EDU [128.2.61.90]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA18259; Sun, 5 Mar 2000 14:22:25 -0500 (EST) Date: Sun, 05 Mar 2000 14:12:32 -0500 From: Cyrus Daboo To: Mark Crispin , IMAP Interest List , IMAP Extensions WG Subject: Formal Syntax in draft-crispin-imapv-09.txt Message-ID: <924000.3161254352@localhost> In-Reply-To: X-Mailer: Mulberry/2.0.0b11 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA19994 for ietf-imapext-bks; Mon, 27 Mar 2000 17:09:10 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19990 for ; Mon, 27 Mar 2000 17:09:09 -0800 (PST) Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V6.0-24 #9441) with ESMTPS id <01JNJ9XBYRP29KMVJF@INNOSOFT.COM> for ietf-imapext@imc.org; Mon, 27 Mar 2000 17:10:27 -0800 (PST) Received: from CONVERSION-DAEMON.elvira.innosoft.com by elvira.innosoft.com (PMDF V6.0-23 #43970) id <0FS300L01XWK22@elvira.innosoft.com> for ietf-imapext@imc.org; Mon, 27 Mar 2000 17:09:56 -0800 (PST) Received: from dhcp-192-33.ietf.connect.com.au (dhcp-192-33.ietf.connect.com.au [169.208.192.33]) by elvira.innosoft.com (PMDF V6.0-23 #43970) with ESMTPA id <0FS30020EXWGVR@elvira.innosoft.com> for ietf-imapext@imc.org; Mon, 27 Mar 2000 17:09:56 -0800 (PST) Date: Tue, 28 Mar 2000 10:39:15 +0930 From: Chris Newman Subject: re: RegExp Search Extension In-reply-to: To: ietf-imapext@imc.org Message-id: <567618.3163228755@dhcp-192-33.ietf.connect.com.au> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0b12 (MacOS) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Thursday, March 9, 2000 20:34 -0800 Mark Crispin 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 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18669 for ietf-imapext-bks; Fri, 17 Mar 2000 09:54:54 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18664 for ; Fri, 17 Mar 2000 09:54:50 -0800 (PST) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA15227; Fri, 17 Mar 2000 12:55:16 -0500 (EST) Date: Fri, 17 Mar 2000 12:55:57 -0500 From: Cyrus Daboo To: Simon Josefsson , Randall Gellens cc: ietf-imapext@imc.org Subject: Re: Annotate Draft Message-ID: <842682.3162286557@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.0.0b12 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, March 17, 2000 6:23 PM +0100 Simon Josefsson 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 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18657 for ietf-imapext-bks; Fri, 17 Mar 2000 09:54:44 -0800 (PST) Received: from demo.esys.ca ([207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18653 for ; Fri, 17 Mar 2000 09:54:42 -0800 (PST) Received: from messagingdirect.com (dhcp198-53.esys.ca [198.161.92.53]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id KAA13720; Fri, 17 Mar 2000 10:53:50 -0700 Message-ID: <38D2717D.48F4978E@messagingdirect.com> Date: Fri, 17 Mar 2000 10:55:09 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Josefsson CC: Randall Gellens , ietf-imapext@imc.org Subject: Re: Annotate Draft References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon Josefsson wrote: > > Randall Gellens 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 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17926 for ietf-imapext-bks; Fri, 17 Mar 2000 09:21:54 -0800 (PST) Received: from badis.pdc.kth.se (badis.pdc.kth.se [130.237.221.45]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17921 for ; Fri, 17 Mar 2000 09:21:52 -0800 (PST) Received: (from jas@localhost) by badis.pdc.kth.se (8.10.0/8.10.0) id e2HHN7l03655; Fri, 17 Mar 2000 18:23:07 +0100 To: Randall Gellens Cc: ietf-imapext@imc.org Subject: Re: Annotate Draft References: In-Reply-To: Randall Gellens's message of "Thu, 9 Mar 2000 21:32:56 -0800" From: Simon Josefsson Date: 17 Mar 2000 18:23:06 +0100 Message-ID: Lines: 12 User-Agent: Gnus/5.0804 (Gnus v5.8.4) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Randall Gellens 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.) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA04080 for ietf-imapext-bks; Thu, 16 Mar 2000 19:21:07 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA04063 for ; Thu, 16 Mar 2000 19:20:56 -0800 (PST) Received: from gruel133.ppp.andrew.cmu.edu (GRUEL133.PPP.ANDREW.CMU.EDU [128.2.60.133]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id WAA13051 for ; Thu, 16 Mar 2000 22:21:31 -0500 (EST) Date: Thu, 16 Mar 2000 22:22:17 -0500 From: Cyrus Daboo To: IMAP Extensions WG Subject: I-D ACTION:draft-daboo-imapext-view-02.txt (fwd) Message-ID: <58651.3162234137@gruel133.ppp.andrew.cmu.edu> X-Mailer: Mulberry/2.0.0b12 (MacOS) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========00075517==========" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==========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: Internet-Drafts@ietf.org 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 - 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 and being non-zero. - Corrected examples which had and 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==========-- Received: by ns.secondary.com (8.9.3/8.9.3) id OAA19032 for ietf-imapext-bks; Tue, 14 Mar 2000 14:53:23 -0800 (PST) Received: from assw1s01.axtel.com.mx (assw1s01.axtel.com.mx [148.244.73.3]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA19027 for ; Tue, 14 Mar 2000 14:53:21 -0800 (PST) From: mtrevino@axtel.com.mx Received: from GWOAMYCONT01 by assw1s01.axtel.com.mx via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 14 Mar 2000 22:56:11 UT Subject: Question To: mtrevino@axtel.com.mx X-Mailer: Lotus Notes Release 5.0.2a (Intl) 23 November 1999 Message-ID: Date: Tue, 14 Mar 2000 16:38:56 -0600 X-MIMETrack: Serialize by Router on GWOAMYCONT01/TELINOR(Release 5.0.2a (Intl)|23 November 1999) at 03/14/2000 04:49:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA19029 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA15395 for ietf-imapext-bks; Tue, 14 Mar 2000 11:35:53 -0800 (PST) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15377; Tue, 14 Mar 2000 11:35:49 -0800 (PST) Message-Id: <4.3.2.20000314113200.00a792d0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 14 Mar 2000 11:33:35 -0800 To: imap@u.washington.edu, ietf-imapext@imc.org From: Paul Hoffman / IMC Subject: Announcement of MailConnect 6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 . 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 Received: by ns.secondary.com (8.9.3/8.9.3) id XAA03280 for ietf-imapext-bks; Sun, 12 Mar 2000 23:14:59 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (senf@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA03274 for ; Sun, 12 Mar 2000 23:14:58 -0800 (PST) Date: Sun, 12 Mar 2000 23:07:19 -0800 (PST) From: Mark Crispin Subject: re: multi-append To: Lawrence Greenfield cc: ietf-imapext@imc.org In-Reply-To: <200003130655.BAA10820@smtp1.andrew.cmu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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. Received: by ns.secondary.com (8.9.3/8.9.3) id WAA03027 for ietf-imapext-bks; Sun, 12 Mar 2000 22:54:42 -0800 (PST) Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA03023 for ; Sun, 12 Mar 2000 22:54:41 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp1.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id BAA10820; Mon, 13 Mar 2000 01:55:41 -0500 (EST) Date: Mon, 13 Mar 2000 01:55:41 -0500 (EST) Message-Id: <200003130655.BAA10820@smtp1.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: ietf-imapext@imc.org Subject: multi-append Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA13112 for ietf-imapext-bks; Fri, 10 Mar 2000 21:37:13 -0800 (PST) Received: from demo.esys.ca ([207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA13107 for ; Fri, 10 Mar 2000 21:37:12 -0800 (PST) Received: from messagingdirect.com (2-103-edm.dial.worldgate.ca [207.167.2.103]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id WAA03047; Fri, 10 Mar 2000 22:36:41 -0700 Message-ID: <38C9DBAE.1BB7BED@messagingdirect.com> Date: Fri, 10 Mar 2000 22:37:50 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Greenfield CC: ietf-imapext@imc.org Subject: Re: Annotate Draft (Corrected URL) References: <000a01bf8afc$91704930$f3fd3b9d@redmond.corp.microsoft.com> <200003110251.VAA02267@smtp3.andrew.cmu.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 > 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 /) > > 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 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA05568 for ietf-imapext-bks; Fri, 10 Mar 2000 18:50:31 -0800 (PST) Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA05562 for ; Fri, 10 Mar 2000 18:50:29 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id VAA02267; Fri, 10 Mar 2000 21:51:10 -0500 (EST) Date: Fri, 10 Mar 2000 21:51:10 -0500 (EST) Message-Id: <200003110251.VAA02267@smtp3.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: ietf-imapext@imc.org In-reply-to: <000a01bf8afc$91704930$f3fd3b9d@redmond.corp.microsoft.com> Subject: Re: Annotate Draft (Corrected URL) References: <000a01bf8afc$91704930$f3fd3b9d@redmond.corp.microsoft.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Mike Gahrns 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//flags/seen /body//flags/answered /body//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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA01244 for ietf-imapext-bks; Fri, 10 Mar 2000 17:52:40 -0800 (PST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA01240 for ; Fri, 10 Mar 2000 17:52:39 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 Mar 2000 17:50:36 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Mar 2000 17:50:36 -0800 Message-ID: <000a01bf8afc$91704930$f3fd3b9d@redmond.corp.microsoft.com> From: Mike Gahrns To: Cc: ietf-imapext@imc.org Subject: Re: Annotate Draft (Corrected URL) Date: Fri, 10 Mar 2000 17:53:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8AFC.317D8BAA" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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" Re: Annotate Draft (Corrected URL)

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-- Received: by ns.secondary.com (8.9.3/8.9.3) id NAA27137 for ietf-imapext-bks; Fri, 10 Mar 2000 13:06:51 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (pell@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27132; Fri, 10 Mar 2000 13:06:49 -0800 (PST) Date: Fri, 10 Mar 2000 12:55:30 -0800 (PST) From: Mark Crispin Subject: re: RegExp Search Extension To: Paul Hoffman / IMC cc: ietf-imapext@imc.org In-Reply-To: <4.3.2.20000310120034.00bd4b90@mail.imc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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. Received: by ns.secondary.com (8.9.3/8.9.3) id MAA26318 for ietf-imapext-bks; Fri, 10 Mar 2000 12:01:06 -0800 (PST) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26314 for ; Fri, 10 Mar 2000 12:01:04 -0800 (PST) Message-Id: <4.3.2.20000310120034.00bd4b90@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 10 Mar 2000 12:02:08 -0800 To: ietf-imapext@imc.org From: Paul Hoffman / IMC Subject: re: RegExp Search Extension In-Reply-To: References: <729188.3161683253@socrates.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA26102 for ietf-imapext-bks; Fri, 10 Mar 2000 11:45:50 -0800 (PST) Received: from odd.qualcomm.com (odd.qualcomm.com [129.46.2.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26098 for ; Fri, 10 Mar 2000 11:45:48 -0800 (PST) Received: from 129.46.86.92 (primemover-client27.qualcomm.com [129.46.86.92]) by odd.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id LAA21698; Fri, 10 Mar 2000 11:46:33 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <38C94F40.E33B5F87@messagingdirect.com> References: <873334.3161685650@socrates.cyrusoft.com> <38C94F40.E33B5F87@messagingdirect.com> X-Mailer: QUALCOMM Eudora Pro v4.2 for Macintosh Date: Fri, 10 Mar 2000 11:45:22 -0800 To: Alexey Melnikov , Cyrus Daboo From: Randall Gellens Subject: Re: Annotate Draft (Corrected URL) Cc: Randall Gellens , ietf-imapext@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: v1.0b12 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 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. > >Should probably be "vendor.." 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 > >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//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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA25910 for ietf-imapext-bks; Fri, 10 Mar 2000 11:33:50 -0800 (PST) Received: from demo.esys.ca ([207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25906 for ; Fri, 10 Mar 2000 11:33:49 -0800 (PST) Received: from messagingdirect.com (dhcp198-53.esys.ca [198.161.92.53]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id MAA02284; Fri, 10 Mar 2000 12:32:57 -0700 Message-ID: <38C94F40.E33B5F87@messagingdirect.com> Date: Fri, 10 Mar 2000 12:38:40 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cyrus Daboo CC: Randall Gellens , ietf-imapext@imc.org Subject: Re: Annotate Draft (Corrected URL) References: <873334.3161685650@socrates.cyrusoft.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 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. Should probably be "vendor.." >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 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//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 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA25676 for ietf-imapext-bks; Fri, 10 Mar 2000 11:14:13 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (dak@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25671; Fri, 10 Mar 2000 11:14:12 -0800 (PST) Date: Fri, 10 Mar 2000 10:52:28 -0800 (PST) From: Mark Crispin Subject: re: RegExp Search Extension To: Cyrus Daboo cc: Paul Hoffman / IMC , Randall Gellens , ietf-imapext@imc.org In-Reply-To: <729188.3161683253@socrates.cyrusoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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. Received: by ns.secondary.com (8.9.3/8.9.3) id KAA24955 for ietf-imapext-bks; Fri, 10 Mar 2000 10:20:09 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24950; Fri, 10 Mar 2000 10:20:07 -0800 (PST) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA01216; Fri, 10 Mar 2000 13:20:14 -0500 (EST) Date: Fri, 10 Mar 2000 13:20:53 -0500 From: Cyrus Daboo To: Mark Crispin , "Paul Hoffman / IMC" cc: Randall Gellens , ietf-imapext@imc.org Subject: re: RegExp Search Extension Message-ID: <729188.3161683253@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.0.0b11 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Thursday, March 9, 2000 8:34 PM -0800 Mark Crispin 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 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA24309 for ietf-imapext-bks; Fri, 10 Mar 2000 09:34:12 -0800 (PST) Received: from jittlov.qualcomm.com (jittlov.qualcomm.com [129.46.50.79]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24305 for ; Fri, 10 Mar 2000 09:34:11 -0800 (PST) Received: from 129.46.86.92 (primemover-client27.qualcomm.com [129.46.86.92]) by jittlov.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id JAA19493 for ; Fri, 10 Mar 2000 09:34:59 -0800 (PST) Mime-Version: 1.0 Message-Id: X-Mailer: QUALCOMM Eudora Pro v4.2 for Macintosh Date: Fri, 10 Mar 2000 09:34:17 -0800 To: ietf-imapext@imc.org From: Randall Gellens Subject: Annotate Draft (Corrected URL) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: v1.0b12 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [[[ 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 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA25591 for ietf-imapext-bks; Thu, 9 Mar 2000 21:38:37 -0800 (PST) Received: from mail1.qualcomm.com (mail1.qualcomm.com [129.46.2.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25586; Thu, 9 Mar 2000 21:38:36 -0800 (PST) Received: from 129.46.86.67 (primemover-client02.qualcomm.com [129.46.86.67]) by mail1.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id VAA00315; Thu, 9 Mar 2000 21:39:17 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: QUALCOMM Eudora Pro v4.2 for Macintosh Date: Thu, 9 Mar 2000 21:37:06 -0800 To: Mark Crispin , Paul Hoffman / IMC From: Randall Gellens Subject: re: RegExp Search Extension Cc: Randall Gellens , ietf-imapext@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: v1.0b12 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA25581 for ietf-imapext-bks; Thu, 9 Mar 2000 21:38:26 -0800 (PST) Received: from mail1.qualcomm.com (mail1.qualcomm.com [129.46.2.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25577 for ; Thu, 9 Mar 2000 21:38:25 -0800 (PST) Received: from 129.46.86.67 (primemover-client02.qualcomm.com [129.46.86.67]) by mail1.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id VAA00310 for ; Thu, 9 Mar 2000 21:39:14 -0800 (PST) Mime-Version: 1.0 Message-Id: X-Mailer: QUALCOMM Eudora Pro v4.2 for Macintosh Date: Thu, 9 Mar 2000 21:32:56 -0800 To: ietf-imapext@imc.org From: Randall Gellens Subject: Annotate Draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: v1.0b12 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 -- 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 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA22745 for ietf-imapext-bks; Thu, 9 Mar 2000 20:35:46 -0800 (PST) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22740; Thu, 9 Mar 2000 20:35:45 -0800 (PST) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id UAA28037; Thu, 9 Mar 2000 20:36:34 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (grid@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id UAA25509; Thu, 9 Mar 2000 20:36:34 -0800 Date: Thu, 9 Mar 2000 20:34:43 -0800 (PST) From: Mark Crispin Subject: re: RegExp Search Extension To: Paul Hoffman / IMC cc: Randall Gellens , ietf-imapext@imc.org In-Reply-To: <4.3.2.20000309203146.00e20180@mail.imc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 . 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? Received: by ns.secondary.com (8.9.3/8.9.3) id UAA22620 for ietf-imapext-bks; Thu, 9 Mar 2000 20:32:43 -0800 (PST) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22616; Thu, 9 Mar 2000 20:32:40 -0800 (PST) Message-Id: <4.3.2.20000309203146.00e20180@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 09 Mar 2000 20:33:30 -0800 To: Mark Crispin , Randall Gellens From: Paul Hoffman / IMC Subject: re: RegExp Search Extension Cc: ietf-imapext@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 . It is well on its way to making it into a future version of the Unicode Standard. --Paul Hoffman, Director --Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id UAA21102 for ietf-imapext-bks; Thu, 9 Mar 2000 20:07:52 -0800 (PST) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA21096 for ; Thu, 9 Mar 2000 20:07:51 -0800 (PST) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id UAA26868; Thu, 9 Mar 2000 20:08:39 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (btik@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id UAA26301; Thu, 9 Mar 2000 20:08:39 -0800 Date: Thu, 9 Mar 2000 20:04:20 -0800 (PST) From: Mark Crispin Subject: re: RegExp Search Extension To: Randall Gellens cc: ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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... Received: by ns.secondary.com (8.9.3/8.9.3) id TAA20453 for ietf-imapext-bks; Thu, 9 Mar 2000 19:56:36 -0800 (PST) Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA20448 for ; Thu, 9 Mar 2000 19:56:34 -0800 (PST) Received: from 129.46.242.106 (randy-mac.qualcomm.com [129.46.242.106]) by illyana.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id TAA15518 for ; Thu, 9 Mar 2000 19:57:19 -0800 (PST) Mime-Version: 1.0 Message-Id: X-Mailer: QUALCOMM Eudora Pro v4.3.1 for Macintosh Date: Thu, 9 Mar 2000 19:49:34 -0800 To: ietf-imapext@imc.org From: Randall Gellens Subject: RegExp Search Extension Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: v1.0b12 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 . 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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA03667 for ietf-imapext-bks; Sun, 5 Mar 2000 11:23:20 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03654 for ; Sun, 5 Mar 2000 11:23:09 -0800 (PST) Received: from groats90.ppp.andrew.cmu.edu (GROATS90.PPP.ANDREW.CMU.EDU [128.2.61.90]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA18259; Sun, 5 Mar 2000 14:22:25 -0500 (EST) Date: Sun, 05 Mar 2000 14:12:32 -0500 From: Cyrus Daboo To: Mark Crispin , IMAP Interest List , IMAP Extensions WG Subject: Formal Syntax in draft-crispin-imapv-09.txt Message-ID: <924000.3161254352@localhost> In-Reply-To: X-Mailer: Mulberry/2.0.0b11 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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