Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UIlt215802 for ietf-imapext-bks; Tue, 30 Apr 2002 11:47:55 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UIlra15796 for ; Tue, 30 Apr 2002 11:47:53 -0700 (PDT) Received: from PLATO (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA23767; Tue, 30 Apr 2002 14:45:14 -0400 (EDT) Date: Tue, 30 Apr 2002 14:48:30 -0400 From: Cyrus Daboo To: Mark Crispin , John Neystadt cc: ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Message-ID: <14140533.1020178110@PLATO> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; 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: Hi, --On Friday, April 26, 2002 6:30 PM -0700 Mark Crispin wrote: | I agree with Arnt Gulbrandsen that you should try to leverage SEARCH as | much as possible rather than try to extend STATUS. One thing that you | could try to do is use STATUS to identify whether a mailbox should be | subject to more detailed examination with SELECT+SEARCH. That was the | original intent behind STATUS; to enable identification of "interesting" | mailboxes without having to SELECT them. This is a good point. Here is my take on this: If the user is only likely to be interested in one or two mailboxes, then its perfectly feasible to allow EXAMINE+IDLE+SEARCH style notifications to be done by the client. If you are dealing with tens to hundreds of mailboxes then status polling is OK, provided there is not too much extra data in the status response. Mark's suggestion of having a simple indicator to go look at the mailbox in more detail is reasonable for this application. If you need to do more than that then look to do it outside of IMAP - I thought SNAP was supposed to provide a way to get the same information as you are proposing adding to STATUS. Why duplicate SNAP inside of IMAP? Just let clients interested in that info use SNAP instead. -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UIE4H15117 for ietf-imapext-bks; Tue, 30 Apr 2002 11:14:04 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UIE3a15113 for ; Tue, 30 Apr 2002 11:14:03 -0700 (PDT) Received: from dialup-63.208.166.248.dial1.washington2.level3.net ([63.208.166.248] helo=eburger) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 172c8V-0001Vw-00; Tue, 30 Apr 2002 11:14:00 -0700 Reply-To: From: "Eric Burger" To: "Mark Crispin" Cc: , Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Date: Tue, 30 Apr 2002 14:13:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have to agree with Mark's sentiment expressed below. The whole point of using IMAP for Pink Lemonade is there is a large existing base of servers and developers. If we set out to build "VPIM-IMAP", we might as well call it son/daughter of IMAP and be done with it. -----Original Message----- From: owner-vpim@lists.neystadt.org [mailto:owner-vpim@lists.neystadt.org]On Behalf Of Mark Crispin Sent: Friday, April 26, 2002 9:31 PM To: John Neystadt Cc: ietf-imapext@imc.org; vpim@lists.neystadt.org Subject: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt [snip] The more that you leverage existing tools, as opposed to requiring the creation of new tools, the better able you'll be able to deploy. Ideally, given 100% leverage, you'll be able to run your VPIM client software with any IMAP server; you may desire to have a special IMAP server that is optimized for VPIM, but there is an attraction to being able to plug in with any server. What concerns me is the possibility of making VPIM clients excessively and unnecessarily dependent upon a VPIM-extended server. This doesn't mean "thou shalt not extend IMAP for VPIM under any circumstances"!! It does, however, suggest that you should leverage aggressively and extend IMAP only if there's no way to leverage. Also, the more minimal a VPIM extension to IMAP is, the more likely it is that you'll get it generally implemented. For example, if a VPIM extension requires only about 15 minutes of programming work, I'm likely to do it in my server, just to preclude having to answer an email require to do it. If, on the other hand, an extension requires many hours of work, it's much less likely to happen without specific value to us. Received: by above.proper.com (8.11.6/8.11.3) id g3TC2Hq24570 for ietf-imapext-bks; Mon, 29 Apr 2002 05:02:17 -0700 (PDT) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TC2Ga24566 for ; Mon, 29 Apr 2002 05:02:16 -0700 (PDT) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g3TC3Hm01669; Mon, 29 Apr 2002 14:03:17 +0200 Date: Mon, 29 Apr 2002 14:03:17 +0200 From: Arnt Gulbrandsen To: "Neystadt, John" Cc: ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Message-ID: <20020429140317.F1589@melkebalanse.gulbrandsen.priv.no> References: <767720C6032ED511AE8C00508BE3518E06548918@ismailweb.icomverse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <767720C6032ED511AE8C00508BE3518E06548918@ismailweb.icomverse.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Neystadt, John" > This is today handled on clients and is used to display counters either in > folders tree or on some general summary screen. > There are two main benefits of moving this logic to server: > > - in order to build them you must screen all message headers in the mailbox, > this is very slow and traffic intensive if done on client That sounds as if you're using FETCH HEADER.FIELDS() or something today. If that's true, I can certaing agree that a change is desirable ;) However, a SEARCH should avoid network traffic almost completely, cut down on the amount of the client must do, and be at least as good for the server. (I'm assuming that on a server, searching for flags will be at least as fast as downloading all messages - usually quite a bit faster.) > - server can store the counters and then incrementally update the counters > when new messages are delivered (in MTA) or expunged and server do different > clients. This saves much of processing power for servers. Well, maybe. OTOH, most server authors might not want to write code to speed unusual special cases, and then the VPIM client has to the slow code anyway. If you need an extension, better try to design it so that a lot of clients will benefit from it and the incentive to implement it is correspondingly strong. --Arnt Received: by above.proper.com (8.11.6/8.11.3) id g3TBpbH24339 for ietf-imapext-bks; Mon, 29 Apr 2002 04:51:37 -0700 (PDT) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TBpYa24335 for ; Mon, 29 Apr 2002 04:51:34 -0700 (PDT) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g3TBpfa01662; Mon, 29 Apr 2002 13:51:41 +0200 Date: Mon, 29 Apr 2002 13:51:41 +0200 From: Arnt Gulbrandsen To: "Vaudreuil, Greg M (Greg)" Cc: Mark Crispin , John Neystadt , ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt Message-ID: <20020429135141.E1589@melkebalanse.gulbrandsen.priv.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Vaudreuil, Greg M (Greg)" > Is there any objection to a new flag with explicit semantics of importance? > The meaning of \flagged is private between a client and it's store. The > importance is a sender-indicated message attribute, not a recipient > indication of a particular level of interest or importance they may wish to > recall between sessions. We need a flag that is standardized by convention > between a message deposit process that can set this flag and the many > different clients that would expect the flag to be there if a message is > tagged as important. This assumes that current-day clients use \flagged in different ways. Is that indeed so? Every client I've seen seems to either ignore it or treat it as a "must look at this message" flag. --Arnt Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3T4Nrx11874 for ietf-imapext-bks; Sun, 28 Apr 2002 21:23:53 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (jms@ikkoku-kan.panda.com [206.124.149.114]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3T4Nqa11870 for ; Sun, 28 Apr 2002 21:23:52 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id VAA22473; Sun, 28 Apr 2002 21:23:34 -0700 (PDT) Date: Sun, 28 Apr 2002 21:19:05 -0700 (PDT) From: Mark Crispin Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt To: "Vaudreuil, Greg M (Greg)" cc: John Neystadt , ietf-imapext@imc.org, vpim@lists.neystadt.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: On Sun, 28 Apr 2002 20:54:15 -0600, Vaudreuil, Greg M (Greg) wrote: > Is there any objection to a new flag with explicit semantics of importance? I think that you will find a very strong lack of enthusiasm for adding a flag which duplicates the existing functionality of \Flagged and/or SEARCH HEADER. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3T2sKt10326 for ietf-imapext-bks; Sun, 28 Apr 2002 19:54:20 -0700 (PDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3T2sIa10319 for ; Sun, 28 Apr 2002 19:54:18 -0700 (PDT) Received: from co7010exch003u.wins.lucent.com (h135-39-1-23.lucent.com [135.39.1.23]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3T2sHA00075 for ; Sun, 28 Apr 2002 22:54:17 -0400 (EDT) Received: by co7010exch003u.milehi.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sun, 28 Apr 2002 20:54:16 -0600 Message-ID: From: "Vaudreuil, Greg M (Greg)" To: Mark Crispin , John Neystadt Cc: ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt Date: Sun, 28 Apr 2002 20:54:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there any objection to a new flag with explicit semantics of importance? The meaning of \flagged is private between a client and it's store. The importance is a sender-indicated message attribute, not a recipient indication of a particular level of interest or importance they may wish to recall between sessions. We need a flag that is standardized by convention between a message deposit process that can set this flag and the many different clients that would expect the flag to be there if a message is tagged as important. I think use of a new flag makes plenty of sense for \important. I don't think a flag per message context makes much sense tho. Greg V. -----Original Message----- From: Mark Crispin [mailto:MRC@CAC.Washington.EDU] Sent: Friday, April 26, 2002 8:31 PM To: John Neystadt Cc: ietf-imapext@imc.org; vpim@lists.neystadt.org Subject: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt On Fri, 26 Apr 2002, John Neystadt wrote: > BTW is \Flagged semantics is really "importance". If I > make my server (by Sieve or other mechanism) turn \Flagged on all messages > with "Importance: High" header, would that be ok. What are other uses for it > today? What \Flagged does is client-dependent, but the basic idea is to mark some kind of "importance" emphasis on the message. In the original MM program on the DEC-20, flagged messages were always announced with every new mail announcement. In more modern message-browser type programs, flagged messages are drawn with a box around them or in a bold font or with some sort of highlighting color to call attention to it. Since VPIM is essentially a client application, it is perfectly within its rights to decide that \Flagged means "Important" in the VPIM context, and to decide that the MDA should turn on \Flagged on all messages which have "Importance: High" in the header. In fact, I could see some non-VPIM users wanting to do that in the MDA. I agree with Arnt Gulbrandsen that you should try to leverage SEARCH as much as possible rather than try to extend STATUS. One thing that you could try to do is use STATUS to identify whether a mailbox should be subject to more detailed examination with SELECT+SEARCH. That was the original intent behind STATUS; to enable identification of "interesting" mailboxes without having to SELECT them. The more that you leverage existing tools, as opposed to requiring the creation of new tools, the better able you'll be able to deploy. Ideally, given 100% leverage, you'll be able to run your VPIM client software with any IMAP server; you may desire to have a special IMAP server that is optimized for VPIM, but there is an attraction to being able to plug in with any server. What concerns me is the possibility of making VPIM clients excessively and unnecessarily dependent upon a VPIM-extended server. This doesn't mean "thou shalt not extend IMAP for VPIM under any circumstances"!! It does, however, suggest that you should leverage aggressively and extend IMAP only if there's no way to leverage. Also, the more minimal a VPIM extension to IMAP is, the more likely it is that you'll get it generally implemented. For example, if a VPIM extension requires only about 15 minutes of programming work, I'm likely to do it in my server, just to preclude having to answer an email require to do it. If, on the other hand, an extension requires many hours of work, it's much less likely to happen without specific value to us. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. "A single glass of champagne imparts a feeling of exhiliaration. The nerves are braced; the imagination is agreeably strirred; the wits become more nimble. A bottle produces a contrary effect. Excess causes a comatose insensibility. So it is with war; and the quality of both is best discovered by sipping." -- Winston Churchill ---------------------------------------------------------- This message was sent to you, since you are subscribed to vpim@lists.neystadt.org. You can manage your subscription at http://www.neystadt.org/cgi-bin/majordomo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3S7SEG28302 for ietf-imapext-bks; Sun, 28 Apr 2002 00:28:14 -0700 (PDT) Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3S7SCa28293 for ; Sun, 28 Apr 2002 00:28:12 -0700 (PDT) Received: from il-tlv-mbdg2.icomverse.com (il-tlv-mbdg2.icomverse.com [10.115.244.42]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id g3S7KZX04913; Sun, 28 Apr 2002 10:20:37 +0300 Received: by il-tlv-mbdg2.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Sun, 28 Apr 2002 10:27:40 +0300 Message-ID: <767720C6032ED511AE8C00508BE3518E06548918@ismailweb.icomverse.com> From: "Neystadt, John" To: Arnt Gulbrandsen Cc: ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: RE: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Date: Sun, 28 Apr 2002 10:27:39 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EE86.2D40BBD0" 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_01C1EE86.2D40BBD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > In draft-1, could you the non-ascii junk? I see various =FC and =C6 > characters. I was told already, I've used winword template that produced this junk = :( I'll clean it up. > It seems unjustified. You mention one application for it, and=20 > it sounds as > if the code belongs in that IMAP client. If you think that code = really > belongs in IMAP servers, I suggest showing more uses in the draft. This is today handled on clients and is used to display counters either = in folders tree or on some general summary screen.=20 There are two main benefits of moving this logic to server: - in order to build them you must screen all message headers in the = mailbox, this is very slow and traffic intensive if done on client - server can store the counters and then incrementally update the = counters when new messages are delivered (in MTA) or expunged and server do = different clients. This saves much of processing power for servers. John Neystadt john@neystadt.org http://www.neystadt.org/john/ ------_=_NextPart_001_01C1EE86.2D40BBD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D = ACTION:draft-neystadt-imap-status-counters-00.txt

> In draft-1, could you the non-ascii junk? I see = various =FC and =C6
> characters.

I was told already, I've used winword template that = produced this junk :( I'll clean it up.

> It seems unjustified. You mention one = application for it, and
> it sounds as
> if the code belongs in that IMAP client. If you = think that code really
> belongs in IMAP servers, I suggest showing more = uses in the draft.

This is today handled on clients and is used to = display counters either in folders tree or on some general summary = screen.

There are two main benefits of moving this logic to = server:

- in order to build them you must screen all message = headers in the mailbox, this is very slow and traffic intensive if done = on client

- server can store the counters and then = incrementally update the counters when new messages are delivered (in = MTA) or expunged and server do different clients. This saves much of = processing power for servers.

John Neystadt
john@neystadt.org
http://www.neystadt.org/john/

------_=_NextPart_001_01C1EE86.2D40BBD0-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3R1Uxa23072 for ietf-imapext-bks; Fri, 26 Apr 2002 18:30:59 -0700 (PDT) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3R1Uwa23068 for ; Fri, 26 Apr 2002 18:30:58 -0700 (PDT) Received: from mailscan-out3.cac.washington.edu (mailscan-out3.cac.washington.edu [140.142.32.18]) by mxout3.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g3R1V28J006381 for ; Fri, 26 Apr 2002 18:31:02 -0700 Received: FROM smtp.washington.edu BY mailscan-out3.cac.washington.edu ; Fri Apr 26 18:31:01 2002 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g3R1V0jv023572 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 26 Apr 2002 18:31:01 -0700 Date: Fri, 26 Apr 2002 18:30:59 -0700 (Pacific Daylight Time) From: Mark Crispin To: John Neystadt cc: ietf-imapext@imc.org, Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt In-Reply-To: <000e01c1ecff$d3a4c0d0$92d97ed4@icomverse.com> Message-ID: Organization: Networks & Distributed Computing 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, 26 Apr 2002, John Neystadt wrote: > BTW is \Flagged semantics is really "importance". If I > make my server (by Sieve or other mechanism) turn \Flagged on all messages > with "Importance: High" header, would that be ok. What are other uses for it > today? What \Flagged does is client-dependent, but the basic idea is to mark some kind of "importance" emphasis on the message. In the original MM program on the DEC-20, flagged messages were always announced with every new mail announcement. In more modern message-browser type programs, flagged messages are drawn with a box around them or in a bold font or with some sort of highlighting color to call attention to it. Since VPIM is essentially a client application, it is perfectly within its rights to decide that \Flagged means "Important" in the VPIM context, and to decide that the MDA should turn on \Flagged on all messages which have "Importance: High" in the header. In fact, I could see some non-VPIM users wanting to do that in the MDA. I agree with Arnt Gulbrandsen that you should try to leverage SEARCH as much as possible rather than try to extend STATUS. One thing that you could try to do is use STATUS to identify whether a mailbox should be subject to more detailed examination with SELECT+SEARCH. That was the original intent behind STATUS; to enable identification of "interesting" mailboxes without having to SELECT them. The more that you leverage existing tools, as opposed to requiring the creation of new tools, the better able you'll be able to deploy. Ideally, given 100% leverage, you'll be able to run your VPIM client software with any IMAP server; you may desire to have a special IMAP server that is optimized for VPIM, but there is an attraction to being able to plug in with any server. What concerns me is the possibility of making VPIM clients excessively and unnecessarily dependent upon a VPIM-extended server. This doesn't mean "thou shalt not extend IMAP for VPIM under any circumstances"!! It does, however, suggest that you should leverage aggressively and extend IMAP only if there's no way to leverage. Also, the more minimal a VPIM extension to IMAP is, the more likely it is that you'll get it generally implemented. For example, if a VPIM extension requires only about 15 minutes of programming work, I'm likely to do it in my server, just to preclude having to answer an email require to do it. If, on the other hand, an extension requires many hours of work, it's much less likely to happen without specific value to us. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. "A single glass of champagne imparts a feeling of exhiliaration. The nerves are braced; the imagination is agreeably strirred; the wits become more nimble. A bottle produces a contrary effect. Excess causes a comatose insensibility. So it is with war; and the quality of both is best discovered by sipping." -- Winston Churchill Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3Q9IAW18850 for ietf-imapext-bks; Fri, 26 Apr 2002 02:18:10 -0700 (PDT) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q9I9a18846 for ; Fri, 26 Apr 2002 02:18:09 -0700 (PDT) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g3Q9ICp01297; Fri, 26 Apr 2002 11:18:12 +0200 Date: Fri, 26 Apr 2002 11:18:12 +0200 From: Arnt Gulbrandsen To: John Neystadt Cc: Mark Crispin , ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Message-ID: <20020426111812.D1249@melkebalanse.gulbrandsen.priv.no> References: <000e01c1ecff$d3a4c0d0$92d97ed4@icomverse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000e01c1ecff$d3a4c0d0$92d97ed4@icomverse.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John Neystadt > C: STATUS abc COUNTERS[(\Seen AND $Fax-Message) (\Seen AND \Flagged AND > $Fax-Message) ...] > > This is long and somewhat cumbersome. That sounds like a few SEARCH commands joined together and renamed to STATUS. Perhaps using SEARCH (and maybe ANNOTATE) is enough? SEARCH may not scale as well as STATUS-COUNTERS would, but in this case I don't think that's a problem: "You have 1042300533 messages, 32765355 new and 42523145 important" is a nightmare no matter of efficiently it's implemented ;) --Arnt Received: by above.proper.com (8.11.6/8.11.3) id g3Q8pbM15952 for ietf-imapext-bks; Fri, 26 Apr 2002 01:51:37 -0700 (PDT) Received: from mxout1.netvision.net.il (mxout1.netvision.net.il [194.90.9.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q8pZa15943 for ; Fri, 26 Apr 2002 01:51:36 -0700 (PDT) Received: from johnnb ([212.126.217.146]) by mxout1.netvision.net.il (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GV600LC239D55@mxout1.netvision.net.il> for ietf-imapext@imc.org; Fri, 26 Apr 2002 11:51:18 +0300 (IDT) Date: Fri, 26 Apr 2002 10:53:19 +0200 From: John Neystadt Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt To: Mark Crispin Cc: ietf-imapext@imc.org, vpim@lists.neystadt.org Message-id: <000e01c1ecff$d3a4c0d0$92d97ed4@icomverse.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, > It certainly does seem to be very much specialized for VPIM, and doesn't seem > to make adequate attempt to leverage existing mechanisms. For example, why > not use IMAP keyword flags in association with delivery mechanisms that set > those flags, and then just extend STATUS to count other flags besides \Recent > and (not) \Seen. I think your proposal is very good for Unseen and may be Important (new flag or reuse \Flagged). BTW is \Flagged semantics is really "importance". If I make my server (by Sieve or other mechanism) turn \Flagged on all messages with "Importance: High" header, would that be ok. What are other uses for it today? Now there is a problem with Message-Context - since it is an extensible list of values (new ones can be added ad-hoc) then message flags will have to be added per each of them each time new values are added. In my proposal server sends response per all detected Message-Contexts. In your way we will have to introduce some mechanism for MUA to enumerate them. In additoin flags are not "typed" so MUA can't distinuigh between say $MDNSent and $Fax-Message which is confusing. Another issue is that \Seen changes dynamically. So in order to query for counter of \Seen fax messgase we will have to pass a boolean expression of flags to this new STATUS extension. For example: C: STATUS abc COUNTERS[(\Seen AND $Fax-Message) (\Seen AND \Flagged AND $Fax-Message) ...] This is long and somewhat cumbersome. > > In draft-1, could you the non-ascii junk? I see various | and F > > characters. > > I have to echo this comment; I don't know what produced that junk but it is > there and it is annoying. I apologize again. John Neystadt john@neystadt.org http://www.neystadt.org/john/ Received: by above.proper.com (8.11.6/8.11.3) id g3PKHqc07589 for ietf-imapext-bks; Thu, 25 Apr 2002 13:17:52 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (dhack@ikkoku-kan.panda.com [206.124.149.114]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PKHoa07584 for ; Thu, 25 Apr 2002 13:17:50 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id NAA17901; Thu, 25 Apr 2002 13:17:14 -0700 (PDT) Date: Thu, 25 Apr 2002 13:05:51 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt To: Arnt Gulbrandsen cc: "Neystadt, John" , ietf-imapext@imc.org, vpim@lists.neystadt.org In-Reply-To: <20020425151801.G906@melkebalanse.gulbrandsen.priv.no> 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, 25 Apr 2002 15:18:01 +0200, Arnt Gulbrandsen wrote: > "Neystadt, John" > > Until now I did not get a comments regarding matter of the draft. > > > > Does it makes sense? What do you think about it? > > It seems unjustified. You mention one application for it, and it sounds as > if the code belongs in that IMAP client. If you think that code really > belongs in IMAP servers, I suggest showing more uses in the draft. It certainly does seem to be very much specialized for VPIM, and doesn't seem to make adequate attempt to leverage existing mechanisms. For example, why not use IMAP keyword flags in association with delivery mechanisms that set those flags, and then just extend STATUS to count other flags besides \Recent and (not) \Seen. Regardless of whether this extension is intended for general implementation, or only for implementation in special VPIM boxes, I think that greater leveraging of existing IMAP mechanisms is desirable. In the general implementation case, it is to create a reason for it to be implemented; in the VPIM-only cases, it is because there's no harm in doing so. On the other hand, the intended implementation audience may make a difference on, for example, whether or not \Flagged can be used to implement "Important". But that's a minor issue in the overall scope of things. To summarize: you may have a good case to expand STATUS to return other data; but you have not (yet) made a good case to create new classes of data since it is conjectured that the desired information can be represented with existing data. In particular, please give strong consideration to using keyword flags. > In draft-1, could you the non-ascii junk? I see various | and F > characters. I have to echo this comment; I don't know what produced that junk but it is there and it is annoying. Received: by above.proper.com (8.11.6/8.11.3) id g3PDHjp23092 for ietf-imapext-bks; Thu, 25 Apr 2002 06:17:45 -0700 (PDT) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PDHia23087 for ; Thu, 25 Apr 2002 06:17:44 -0700 (PDT) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g3PDI1k01112; Thu, 25 Apr 2002 15:18:01 +0200 Date: Thu, 25 Apr 2002 15:18:01 +0200 From: Arnt Gulbrandsen To: "Neystadt, John" Cc: ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Message-ID: <20020425151801.G906@melkebalanse.gulbrandsen.priv.no> References: <767720C6032ED511AE8C00508BE3518E0654883E@ismailweb.icomverse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <767720C6032ED511AE8C00508BE3518E0654883E@ismailweb.icomverse.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Neystadt, John" > Until now I did not get a comments regarding matter of the draft. > > Does it makes sense? What do you think about it? It seems unjustified. You mention one application for it, and it sounds as if the code belongs in that IMAP client. If you think that code really belongs in IMAP servers, I suggest showing more uses in the draft. In draft-1, could you the non-ascii junk? I see various ü and Æ characters. --Arnt Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PClmH21288 for ietf-imapext-bks; Thu, 25 Apr 2002 05:47:48 -0700 (PDT) Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PClja21284 for ; Thu, 25 Apr 2002 05:47:45 -0700 (PDT) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.icomverse.com [10.116.200.32]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id g3PCfLX28741; Thu, 25 Apr 2002 15:41:21 +0300 Received: by il-tlv-mbdg1.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Thu, 25 Apr 2002 15:47:40 +0300 Message-ID: <767720C6032ED511AE8C00508BE3518E0654883E@ismailweb.icomverse.com> From: "Neystadt, John" To: ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: RE: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Date: Thu, 25 Apr 2002 15:47:28 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EC57.5B5372F0" 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_01C1EC57.5B5372F0 Content-Type: text/plain; charset="koi8-r" Hi! Until now I did not get a comments regarding matter of the draft. Does it makes sense? What do you think about it? Regards, John Neystadt john@neystadt.org http://www.neystadt.org/john/ > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, April 23, 2002 1:14 PM > Cc: um@snowshore.com; ietf-imapext@imc.org; vpim@lists.neystadt.org > Subject: I-D ACTION:draft-neystadt-imap-status-counters-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : IMAP4 rev1 u STATUS-COUNTERS Extension > Author(s) : J. Neystadt > Filename : draft-neystadt-imap-status-counters-00.txt > Pages : 7 > Date : 22-Apr-02 > > This document describes STATUS-COUNTERS extension to IMAP4rev1 > protocol. This extension enables Mail User Agents to retrieve > messages counters grouped by message context. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/ > draft-neystadt-imap-status-counters-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-neystadt-imap-status-counters-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-neystadt-imap-status-counters-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ------_=_NextPart_001_01C1EC57.5B5372F0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable RE: I-D = ACTION:draft-neystadt-imap-status-counters-00.txt

Hi!

Until now I did not get a comments regarding matter = of the draft.

Does it makes sense? What do you think about = it?

Regards,

John Neystadt
john@neystadt.org
http://www.neystadt.org/john/


> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
> Sent: Tuesday, April 23, 2002 1:14 PM
> Cc: um@snowshore.com; ietf-imapext@imc.org; = vpim@lists.neystadt.org
> Subject: I-D = ACTION:draft-neystadt-imap-status-counters-00.txt
>
>
> A New Internet-Draft is available from the = on-line
> Internet-Drafts directories.
>
>
>       = Title           : IMAP4 = rev1 u STATUS-COUNTERS Extension
>       = Author(s)       : J. Neystadt
>       = Filename        : = draft-neystadt-imap-status-counters-00.txt
>       = Pages           : 7
>       = Date            : = 22-Apr-02
>      
> This document describes STATUS-COUNTERS = extension to IMAP4rev1
> protocol. This extension enables Mail User = Agents to retrieve
> messages counters grouped by message = context.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/
>       = draft-neystadt-imap-status-counters-00.txt
>
> To remove yourself from the IETF Announcement = list, send a message to
> ietf-announce-request with the word unsubscribe = in the body
> of the message.
>
> Internet-Drafts are also available by anonymous = FTP. Login
> with the username
> "anonymous" and a password of your = e-mail address. After logging in,
> type "cd internet-drafts" and = then
>       "get = draft-neystadt-imap-status-counters-00.txt".
>
> A list of Internet-Drafts directories can be = found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by = e-mail.
>
> Send a message to:
>       = mailserv@ietf.org.
> In the body type:
>       "FILE =
> = /internet-drafts/draft-neystadt-imap-status-counters-00.txt".
>      
> NOTE: The mail server at ietf.org can return = the document in
>       MIME-encoded = form by using the "mpack" utility.  To use this
>       feature, insert = the command "ENCODING mime" before the = "FILE"
>       command.  = To decode the response(s), you will need "munpack" or
>       a MIME-compliant = mail reader.  Different MIME-compliant
> mail readers
>       exhibit = different behavior, especially when dealing with
>       = "multipart" MIME messages (i.e. documents which have been = split
>       up into multiple = messages), so check your local documentation on
>       how to = manipulate these messages.
>       =        
>       =        
> Below is the data which will enable a MIME = compliant mail reader
> implementation to automatically retrieve the = ASCII version of the
> Internet-Draft.
>

------_=_NextPart_001_01C1EC57.5B5372F0-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3NBECN04905 for ietf-imapext-bks; Tue, 23 Apr 2002 04:14:12 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3NBEBa04901 for ; Tue, 23 Apr 2002 04:14:11 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11902; Tue, 23 Apr 2002 07:14:07 -0400 (EDT) Message-Id: <200204231114.HAA11902@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: um@snowshore.com, ietf-imapext@imc.org, vpim@lists.neystadt.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Date: Tue, 23 Apr 2002 07:14:07 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IMAP4 rev1 û STATUS-COUNTERS Extension Author(s) : J. Neystadt Filename : draft-neystadt-imap-status-counters-00.txt Pages : 7 Date : 22-Apr-02 This document describes STATUS-COUNTERS extension to IMAP4rev1 protocol. This extension enables Mail User Agents to retrieve messages counters grouped by message context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-neystadt-imap-status-counters-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-neystadt-imap-status-counters-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-neystadt-imap-status-counters-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020422135313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-neystadt-imap-status-counters-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-neystadt-imap-status-counters-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020422135313.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id g3GJHhE17669 for ietf-imapext-bks; Tue, 16 Apr 2002 12:17:43 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GJHfm17659 for ; Tue, 16 Apr 2002 12:17:41 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id g3GJHWua032208; Tue, 16 Apr 2002 15:17:32 -0400 Date: Tue, 16 Apr 2002 15:17:32 -0400 Message-Id: <200204161917.g3GJHWua032208@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Mark Crispin , Alexey Melnikov Cc: IMAP Extensions WG , iesg@ietf.org In-reply-to: <3CBC08E0.F94B4D14@messagingdirect.com> Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION to Proposed Standard References: <3CBC08E0.F94B4D14@messagingdirect.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: Date: Tue, 16 Apr 2002 05:20:00 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect Mark Crispin wrote: > I believe that the underlying problem is with RFC 2359 (which the > IESG has already accepted as a Proposed Standard), and not with > the MULTIAPPEND extension. The section entitled "MULTIAPPEND > Interaction with UIDPLUS Extension" in the MULTIAPPEND extension > is solely to document how MULTIAPPEND works with RFC 2359. IMHO, I think you should keep this section as there is currently no revision of RFC 2359. I agree. MULTIAPPEND is actually useless to me without UIDPLUS. I would be unhappy if the "Interactions with UIDPLUS" section was removed. [...] I will be happy if MULTIAPPEND clarifies that "m:n" is allowed in APPENDUID response. Yes, this follows from the syntax, but this might not occur to client impelementors. An example would be handy and as well as saying that "m:n" must not be sent by server if m>n. Yes, I agree with this. Making this clear is useful and doesn't hurt the specification in any way. Larry Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GBK6F14745 for ietf-imapext-bks; Tue, 16 Apr 2002 04:20:06 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GBK4m14740 for ; Tue, 16 Apr 2002 04:20:04 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g3GBK1j31506; Tue, 16 Apr 2002 05:20:01 -0600 Message-ID: <3CBC08E0.F94B4D14@messagingdirect.com> Date: Tue, 16 Apr 2002 05:20:00 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: iesg@ietf.org, IMAP Extensions WG , Lawrence Greenfield Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION to Proposed Standard 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: Mark Crispin wrote: > I have read and considered Alexey's comment. > > I believe that the underlying problem is with RFC 2359 (which the IESG has > already accepted as a Proposed Standard), and not with the MULTIAPPEND > extension. The section entitled "MULTIAPPEND Interaction with UIDPLUS > Extension" in the MULTIAPPEND extension is solely to document how MULTIAPPEND > works with RFC 2359. IMHO, I think you should keep this section as there is currently no revision of RFC 2359. > If Alexey's concerns are valid, these concerns are with RFC 2359 (as he notes > in his postscript ("The same problem exists with COPYUID response code > described in UIDPLUS extension"). If so, then the proper action is to block > further standards-track advancement of RFC 2359 until this problem is fixed in > a revision to RFC 2359. The MULTIAPPEND extension can be published by > eliminating the entire section entitled "MULTIAPPEND Interaction with UIDPLUS > Extension", and require that the revision to RFC 2359 document how UIDPLUS > should work in the MULTIAPPEND extension. > > Disclaimer: I do not implement the UIDPLUS extension, so it's of little > consequence to me if it is blocked. It is, however, of great consequence if > MULTIAPPEND is blocked since MULTIAPPEND is a major performace and > functionality boost. > > I am not convinced that Alexey's concerns are valid. > > Given his example of > a001 OK [APPENDUID 31345 10121:10117] Multiappend completed. > his possible interpretation of > #1 gets UID 10121, #2 - 10120, ..., #5 - 10117 (i.e. m, m-1,m-2,...,n) > is forbidden by RFC 2060, section 2.3.1.1: > [...] Unique identifiers are assigned in a strictly ascending > fashion in the mailbox; as each message is added to the mailbox it is > assigned a higher UID than the message(s) which were added > previously. Ok, you might be right for APPENDUID, but my example still stands for COPYUID, as there is no guaranty in which order server will perform COPY of a set of messages. Arguably MULTIAPPEND can be considered as a series of APPENDs in the order messages were specified. On the other hand MULTIAPPEND is atomic, so server can assign UIDs in any order it likes ;-). I will be happy if MULTIAPPEND clarifies that "m:n" is allowed in APPENDUID response. Yes, this follows from the syntax, but this might not occur to client impelementors. An example would be handy and as well as saying that "m:n" must not be sent by server if m>n. > This text is unchanged in draft-crispin-imapv-16.txt, the proposed update to > RFC 2060 which is currently in IESG last call. Consequently, only the > interpretation: > #1 gets UID 10117, #2 - 10118, ..., #5 - 10121 (i.e. n, n+1,n+2,...,m) > is valid. > > Furthermore, the specific example ("10121:10117") is silly and in all other > cases in IMAP is exactly equivalent to 10117:10221. > > In conclusion, I do not believe that MULTIAPPEND should be blocked for > publication by this concern; I didn't say blocked ;-). > and if this concern triggers any action it should be in the form of a revision > to RFC 2359. Nothing in the MULTIAPPEND extension can define the semantics of > UIDPLUS behavior; such definition > belongs in the UIDPLUS extension (RFC 2359 or successor). Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FIDRj00387 for ietf-imapext-bks; Mon, 15 Apr 2002 11:13:27 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (hgm@ikkoku-kan.panda.com [206.124.149.114]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FIDPm00383 for ; Mon, 15 Apr 2002 11:13:25 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA01353; Mon, 15 Apr 2002 11:12:42 -0700 (PDT) Date: Mon, 15 Apr 2002 10:55:57 -0700 (PDT) From: Mark Crispin Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION to Proposed Standard To: Alexey Melnikov cc: iesg@ietf.org, IMAP Extensions WG , Lawrence Greenfield In-Reply-To: <3CB9F5AF.167327E9@messagingdirect.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 have read and considered Alexey's comment. I believe that the underlying problem is with RFC 2359 (which the IESG has already accepted as a Proposed Standard), and not with the MULTIAPPEND extension. The section entitled "MULTIAPPEND Interaction with UIDPLUS Extension" in the MULTIAPPEND extension is solely to document how MULTIAPPEND works with RFC 2359. If Alexey's concerns are valid, these concerns are with RFC 2359 (as he notes in his postscript ("The same problem exists with COPYUID response code described in UIDPLUS extension"). If so, then the proper action is to block further standards-track advancement of RFC 2359 until this problem is fixed in a revision to RFC 2359. The MULTIAPPEND extension can be published by eliminating the entire section entitled "MULTIAPPEND Interaction with UIDPLUS Extension", and require that the revision to RFC 2359 document how UIDPLUS should work in the MULTIAPPEND extension. Disclaimer: I do not implement the UIDPLUS extension, so it's of little consequence to me if it is blocked. It is, however, of great consequence if MULTIAPPEND is blocked since MULTIAPPEND is a major performace and functionality boost. I am not convinced that Alexey's concerns are valid. Given his example of a001 OK [APPENDUID 31345 10121:10117] Multiappend completed. his possible interpretation of #1 gets UID 10121, #2 - 10120, ..., #5 - 10117 (i.e. m, m-1,m-2,...,n) is forbidden by RFC 2060, section 2.3.1.1: [...] Unique identifiers are assigned in a strictly ascending fashion in the mailbox; as each message is added to the mailbox it is assigned a higher UID than the message(s) which were added previously. This text is unchanged in draft-crispin-imapv-16.txt, the proposed update to RFC 2060 which is currently in IESG last call. Consequently, only the interpretation: #1 gets UID 10117, #2 - 10118, ..., #5 - 10121 (i.e. n, n+1,n+2,...,m) is valid. Furthermore, the specific example ("10121:10117") is silly and in all other cases in IMAP is exactly equivalent to 10117:10221. In conclusion, I do not believe that MULTIAPPEND should be blocked for publication by this concern; and if this concern triggers any action it should be in the form of a revision to RFC 2359. Nothing in the MULTIAPPEND extension can define the semantics of UIDPLUS behavior; such definition belongs in the UIDPLUS extension (RFC 2359 or successor). -- Mark -- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3F9X5b10328 for ietf-imapext-bks; Mon, 15 Apr 2002 02:33:05 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3F9X3m10323 for ; Mon, 15 Apr 2002 02:33:04 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g3F9Wuj18644; Mon, 15 Apr 2002 03:32:56 -0600 Message-ID: <3CB9F5AF.167327E9@messagingdirect.com> Date: Sun, 14 Apr 2002 15:33:35 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: iesg@ietf.org CC: Mark Crispin , IMAP Extensions WG , Lawrence Greenfield Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION to Proposed Standard References: <200203251902.OAA26608@ietf.org> 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: The IESG wrote: > The IESG has received a request to consider INTERNET MESSAGE ACCESS > PROTOCOL - MULTIAPPEND EXTENSION > as a Proposed Standard. This > has been reviewed in the IETF but is not the product of an IETF Working > Group. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by April 24, 2002. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-crispin-imap-multiappend-05.txt (I've sent this comment to Mark privately and he suggested that I post the comment on the imapext mailing list). I have a comment about MULTIAPPEND document regarding the section that defines interaction with UIDPLUS extension: >MULTIAPPEND Interaction with UIDPLUS Extension > > Servers which support both MULTIAPPEND and [UIDPLUS] will have the > "resp-code-apnd" rule modified as follows: > > resp-code-apnd = "APPENDUID" SP nz-number SP set > > That is, the APPENDUID response code returns as many UIDs as there > were messages appended in the multiple append. The UIDs returned > should be in the order the articles where appended. The message set > may not contain extraneous UIDs or the symbol "*". Unfortunately even with restrictions in the last paragraph, the ABNF for "set" still allows for ambiguous cases. Set can be a comma delimited list of numbers (e.g. "10117,10118,10119" [case 1: a,b,c]), a range construct (e.g. "10117:10119" [case 2: m:n, m < n] or "10119:10117" [case 3: "m:n", m >= n]) or a combination of those. Lets consider the following example. Client appended 4 messages and server support both MULTIAPPEND and UIDPLUS. Server can return [case 1]: a001 OK [APPENDUID 31345 10117,10118,10119,10120,10121] Multiappend completed. and this has a well understood semantics, i.e. appended message #1 gets UID 10117, #2 - 10118, ..., #5 - 10121 Some implementations (including CMU Cyrus server) will use "compressed" representation of this set to minimize amount of data sent across network [case 2]: a001 OK [APPENDUID 31345 10117:10121] Multiappend completed. and this seems to be a logical extension of the previous. Now, it is not clear what client is supposed to do if the server decides to return the following [case 3]: a001 OK [APPENDUID 31345 10121:10117] Multiappend completed. One possible interpretation: #1 gets UID 10121, #2 - 10120, ..., #5 - 10117 (i.e. m, m-1,m-2,...,n) Another possible interpretation: #1 gets UID 10117, #2 - 10118, ..., #5 - 10121 (i.e. n, n+1,n+2,...,m) I suggest that the case 3 is either explicitly prohibited or the document clarifies how the client should interpret the result. Regards, Alexey Melnikov P.S. The same problem exists with COPYUID response code described in UIDPLUS extension. __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g32JNTn12211 for ietf-imapext-bks; Tue, 2 Apr 2002 11:23:29 -0800 (PST) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g32JNSm12205 for ; Tue, 2 Apr 2002 11:23:28 -0800 (PST) Received: from mailscan-out3.cac.washington.edu (mailscan-out3.cac.washington.edu [140.142.32.18]) by mxout3.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g32JNU8J005823 for ; Tue, 2 Apr 2002 11:23:30 -0800 Received: FROM smtp.washington.edu BY mailscan-out3.cac.washington.edu ; Tue Apr 02 11:23:30 2002 -0800 Received: from Shimo-Tomobiki.Panda.COM (D-140-142-21-32.dhcp2.washington.edu [140.142.21.32]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g32JNOkx013876 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 2 Apr 2002 11:23:29 -0800 Date: Tue, 2 Apr 2002 11:23:22 -0800 (Pacific Standard Time) From: Mark Crispin To: Jutta Degener cc: ietf-imapext@imc.org Subject: Re: ACL 2: Why $ and not / ? In-Reply-To: <20020402140310.GA1371@jutta.sendmail.com> Message-ID: Organization: Networks & Distributed Computing 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 Tue, 2 Apr 2002, Jutta Degener wrote: > Why did choose "$" as a > prefix character and not "/" as in RFC 2244 (ACAP)? It was more or less selected out of the air. I originally advocated $, but I would not quarrel if it became something else. My main interest is in there being a formal and unambiguous theory of ACL identifiers (one which does not overlap the world identifier with a user named "anyone"), rather than picking a particular character. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g32IHfP08667 for ietf-imapext-bks; Tue, 2 Apr 2002 10:17:41 -0800 (PST) Received: from mx.crypto.com (mx.crypto.com [207.140.168.138]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g32IHdm08655 for ; Tue, 2 Apr 2002 10:17:39 -0800 (PST) Received: from jutta.sendmail.com (localhost [127.0.0.1]) by MultiHostMXServer (8.9.3/8.9.x4) with ESMTP id NAA31549 for ; Tue, 2 Apr 2002 13:17:40 -0500 (EST) Received: by jutta.sendmail.com (Postfix, from userid 500) id C4BD119210; Tue, 2 Apr 2002 06:03:11 -0800 (PST) Date: Tue, 2 Apr 2002 06:03:10 -0800 From: Jutta Degener To: ietf-imapext@imc.org Subject: ACL 2: Why $ and not / ? Message-ID: <20020402140310.GA1371@jutta.sendmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.24i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Why did choose "$" as a prefix character and not "/" as in RFC 2244 (ACAP)? Granted, "/" is fixed as a hierarchy separator in ACAP and not in IMAP, but isn't it still a _common_ hierarchy separator in IMAP? It's certainly more popular, and more frequently excluded from user names, than "$". Is there a user name scheme that IMAP is trying to support where identifiers do start with "/"? If not, wouldn't it be desirable to keep the number of different user name encoding schemes low and perhaps align ACL2 with ACAP? Jutta Degener Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UIlt215802 for ietf-imapext-bks; Tue, 30 Apr 2002 11:47:55 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UIlra15796 for ; Tue, 30 Apr 2002 11:47:53 -0700 (PDT) Received: from PLATO (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA23767; Tue, 30 Apr 2002 14:45:14 -0400 (EDT) Date: Tue, 30 Apr 2002 14:48:30 -0400 From: Cyrus Daboo To: Mark Crispin , John Neystadt cc: ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Message-ID: <14140533.1020178110@PLATO> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; 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: Hi, --On Friday, April 26, 2002 6:30 PM -0700 Mark Crispin wrote: | I agree with Arnt Gulbrandsen that you should try to leverage SEARCH as | much as possible rather than try to extend STATUS. One thing that you | could try to do is use STATUS to identify whether a mailbox should be | subject to more detailed examination with SELECT+SEARCH. That was the | original intent behind STATUS; to enable identification of "interesting" | mailboxes without having to SELECT them. This is a good point. Here is my take on this: If the user is only likely to be interested in one or two mailboxes, then its perfectly feasible to allow EXAMINE+IDLE+SEARCH style notifications to be done by the client. If you are dealing with tens to hundreds of mailboxes then status polling is OK, provided there is not too much extra data in the status response. Mark's suggestion of having a simple indicator to go look at the mailbox in more detail is reasonable for this application. If you need to do more than that then look to do it outside of IMAP - I thought SNAP was supposed to provide a way to get the same information as you are proposing adding to STATUS. Why duplicate SNAP inside of IMAP? Just let clients interested in that info use SNAP instead. -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UIE4H15117 for ietf-imapext-bks; Tue, 30 Apr 2002 11:14:04 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UIE3a15113 for ; Tue, 30 Apr 2002 11:14:03 -0700 (PDT) Received: from dialup-63.208.166.248.dial1.washington2.level3.net ([63.208.166.248] helo=eburger) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 172c8V-0001Vw-00; Tue, 30 Apr 2002 11:14:00 -0700 Reply-To: From: "Eric Burger" To: "Mark Crispin" Cc: , Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Date: Tue, 30 Apr 2002 14:13:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have to agree with Mark's sentiment expressed below. The whole point of using IMAP for Pink Lemonade is there is a large existing base of servers and developers. If we set out to build "VPIM-IMAP", we might as well call it son/daughter of IMAP and be done with it. -----Original Message----- From: owner-vpim@lists.neystadt.org [mailto:owner-vpim@lists.neystadt.org]On Behalf Of Mark Crispin Sent: Friday, April 26, 2002 9:31 PM To: John Neystadt Cc: ietf-imapext@imc.org; vpim@lists.neystadt.org Subject: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt [snip] The more that you leverage existing tools, as opposed to requiring the creation of new tools, the better able you'll be able to deploy. Ideally, given 100% leverage, you'll be able to run your VPIM client software with any IMAP server; you may desire to have a special IMAP server that is optimized for VPIM, but there is an attraction to being able to plug in with any server. What concerns me is the possibility of making VPIM clients excessively and unnecessarily dependent upon a VPIM-extended server. This doesn't mean "thou shalt not extend IMAP for VPIM under any circumstances"!! It does, however, suggest that you should leverage aggressively and extend IMAP only if there's no way to leverage. Also, the more minimal a VPIM extension to IMAP is, the more likely it is that you'll get it generally implemented. For example, if a VPIM extension requires only about 15 minutes of programming work, I'm likely to do it in my server, just to preclude having to answer an email require to do it. If, on the other hand, an extension requires many hours of work, it's much less likely to happen without specific value to us. Received: by above.proper.com (8.11.6/8.11.3) id g3TC2Hq24570 for ietf-imapext-bks; Mon, 29 Apr 2002 05:02:17 -0700 (PDT) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TC2Ga24566 for ; Mon, 29 Apr 2002 05:02:16 -0700 (PDT) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g3TC3Hm01669; Mon, 29 Apr 2002 14:03:17 +0200 Date: Mon, 29 Apr 2002 14:03:17 +0200 From: Arnt Gulbrandsen To: "Neystadt, John" Cc: ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Message-ID: <20020429140317.F1589@melkebalanse.gulbrandsen.priv.no> References: <767720C6032ED511AE8C00508BE3518E06548918@ismailweb.icomverse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <767720C6032ED511AE8C00508BE3518E06548918@ismailweb.icomverse.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Neystadt, John" > This is today handled on clients and is used to display counters either in > folders tree or on some general summary screen. > There are two main benefits of moving this logic to server: > > - in order to build them you must screen all message headers in the mailbox, > this is very slow and traffic intensive if done on client That sounds as if you're using FETCH HEADER.FIELDS() or something today. If that's true, I can certaing agree that a change is desirable ;) However, a SEARCH should avoid network traffic almost completely, cut down on the amount of the client must do, and be at least as good for the server. (I'm assuming that on a server, searching for flags will be at least as fast as downloading all messages - usually quite a bit faster.) > - server can store the counters and then incrementally update the counters > when new messages are delivered (in MTA) or expunged and server do different > clients. This saves much of processing power for servers. Well, maybe. OTOH, most server authors might not want to write code to speed unusual special cases, and then the VPIM client has to the slow code anyway. If you need an extension, better try to design it so that a lot of clients will benefit from it and the incentive to implement it is correspondingly strong. --Arnt Received: by above.proper.com (8.11.6/8.11.3) id g3TBpbH24339 for ietf-imapext-bks; Mon, 29 Apr 2002 04:51:37 -0700 (PDT) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TBpYa24335 for ; Mon, 29 Apr 2002 04:51:34 -0700 (PDT) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g3TBpfa01662; Mon, 29 Apr 2002 13:51:41 +0200 Date: Mon, 29 Apr 2002 13:51:41 +0200 From: Arnt Gulbrandsen To: "Vaudreuil, Greg M (Greg)" Cc: Mark Crispin , John Neystadt , ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt Message-ID: <20020429135141.E1589@melkebalanse.gulbrandsen.priv.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Vaudreuil, Greg M (Greg)" > Is there any objection to a new flag with explicit semantics of importance? > The meaning of \flagged is private between a client and it's store. The > importance is a sender-indicated message attribute, not a recipient > indication of a particular level of interest or importance they may wish to > recall between sessions. We need a flag that is standardized by convention > between a message deposit process that can set this flag and the many > different clients that would expect the flag to be there if a message is > tagged as important. This assumes that current-day clients use \flagged in different ways. Is that indeed so? Every client I've seen seems to either ignore it or treat it as a "must look at this message" flag. --Arnt Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3T4Nrx11874 for ietf-imapext-bks; Sun, 28 Apr 2002 21:23:53 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (jms@ikkoku-kan.panda.com [206.124.149.114]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3T4Nqa11870 for ; Sun, 28 Apr 2002 21:23:52 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id VAA22473; Sun, 28 Apr 2002 21:23:34 -0700 (PDT) Date: Sun, 28 Apr 2002 21:19:05 -0700 (PDT) From: Mark Crispin Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt To: "Vaudreuil, Greg M (Greg)" cc: John Neystadt , ietf-imapext@imc.org, vpim@lists.neystadt.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: On Sun, 28 Apr 2002 20:54:15 -0600, Vaudreuil, Greg M (Greg) wrote: > Is there any objection to a new flag with explicit semantics of importance? I think that you will find a very strong lack of enthusiasm for adding a flag which duplicates the existing functionality of \Flagged and/or SEARCH HEADER. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3T2sKt10326 for ietf-imapext-bks; Sun, 28 Apr 2002 19:54:20 -0700 (PDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3T2sIa10319 for ; Sun, 28 Apr 2002 19:54:18 -0700 (PDT) Received: from co7010exch003u.wins.lucent.com (h135-39-1-23.lucent.com [135.39.1.23]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3T2sHA00075 for ; Sun, 28 Apr 2002 22:54:17 -0400 (EDT) Received: by co7010exch003u.milehi.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sun, 28 Apr 2002 20:54:16 -0600 Message-ID: From: "Vaudreuil, Greg M (Greg)" To: Mark Crispin , John Neystadt Cc: ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt Date: Sun, 28 Apr 2002 20:54:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there any objection to a new flag with explicit semantics of importance? The meaning of \flagged is private between a client and it's store. The importance is a sender-indicated message attribute, not a recipient indication of a particular level of interest or importance they may wish to recall between sessions. We need a flag that is standardized by convention between a message deposit process that can set this flag and the many different clients that would expect the flag to be there if a message is tagged as important. I think use of a new flag makes plenty of sense for \important. I don't think a flag per message context makes much sense tho. Greg V. -----Original Message----- From: Mark Crispin [mailto:MRC@CAC.Washington.EDU] Sent: Friday, April 26, 2002 8:31 PM To: John Neystadt Cc: ietf-imapext@imc.org; vpim@lists.neystadt.org Subject: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt On Fri, 26 Apr 2002, John Neystadt wrote: > BTW is \Flagged semantics is really "importance". If I > make my server (by Sieve or other mechanism) turn \Flagged on all messages > with "Importance: High" header, would that be ok. What are other uses for it > today? What \Flagged does is client-dependent, but the basic idea is to mark some kind of "importance" emphasis on the message. In the original MM program on the DEC-20, flagged messages were always announced with every new mail announcement. In more modern message-browser type programs, flagged messages are drawn with a box around them or in a bold font or with some sort of highlighting color to call attention to it. Since VPIM is essentially a client application, it is perfectly within its rights to decide that \Flagged means "Important" in the VPIM context, and to decide that the MDA should turn on \Flagged on all messages which have "Importance: High" in the header. In fact, I could see some non-VPIM users wanting to do that in the MDA. I agree with Arnt Gulbrandsen that you should try to leverage SEARCH as much as possible rather than try to extend STATUS. One thing that you could try to do is use STATUS to identify whether a mailbox should be subject to more detailed examination with SELECT+SEARCH. That was the original intent behind STATUS; to enable identification of "interesting" mailboxes without having to SELECT them. The more that you leverage existing tools, as opposed to requiring the creation of new tools, the better able you'll be able to deploy. Ideally, given 100% leverage, you'll be able to run your VPIM client software with any IMAP server; you may desire to have a special IMAP server that is optimized for VPIM, but there is an attraction to being able to plug in with any server. What concerns me is the possibility of making VPIM clients excessively and unnecessarily dependent upon a VPIM-extended server. This doesn't mean "thou shalt not extend IMAP for VPIM under any circumstances"!! It does, however, suggest that you should leverage aggressively and extend IMAP only if there's no way to leverage. Also, the more minimal a VPIM extension to IMAP is, the more likely it is that you'll get it generally implemented. For example, if a VPIM extension requires only about 15 minutes of programming work, I'm likely to do it in my server, just to preclude having to answer an email require to do it. If, on the other hand, an extension requires many hours of work, it's much less likely to happen without specific value to us. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. "A single glass of champagne imparts a feeling of exhiliaration. The nerves are braced; the imagination is agreeably strirred; the wits become more nimble. A bottle produces a contrary effect. Excess causes a comatose insensibility. So it is with war; and the quality of both is best discovered by sipping." -- Winston Churchill ---------------------------------------------------------- This message was sent to you, since you are subscribed to vpim@lists.neystadt.org. You can manage your subscription at http://www.neystadt.org/cgi-bin/majordomo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3S7SEG28302 for ietf-imapext-bks; Sun, 28 Apr 2002 00:28:14 -0700 (PDT) Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3S7SCa28293 for ; Sun, 28 Apr 2002 00:28:12 -0700 (PDT) Received: from il-tlv-mbdg2.icomverse.com (il-tlv-mbdg2.icomverse.com [10.115.244.42]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id g3S7KZX04913; Sun, 28 Apr 2002 10:20:37 +0300 Received: by il-tlv-mbdg2.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Sun, 28 Apr 2002 10:27:40 +0300 Message-ID: <767720C6032ED511AE8C00508BE3518E06548918@ismailweb.icomverse.com> From: "Neystadt, John" To: Arnt Gulbrandsen Cc: ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: RE: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Date: Sun, 28 Apr 2002 10:27:39 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EE86.2D40BBD0" 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_01C1EE86.2D40BBD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > In draft-1, could you the non-ascii junk? I see various =FC and =C6 > characters. I was told already, I've used winword template that produced this junk = :( I'll clean it up. > It seems unjustified. You mention one application for it, and=20 > it sounds as > if the code belongs in that IMAP client. If you think that code = really > belongs in IMAP servers, I suggest showing more uses in the draft. This is today handled on clients and is used to display counters either = in folders tree or on some general summary screen.=20 There are two main benefits of moving this logic to server: - in order to build them you must screen all message headers in the = mailbox, this is very slow and traffic intensive if done on client - server can store the counters and then incrementally update the = counters when new messages are delivered (in MTA) or expunged and server do = different clients. This saves much of processing power for servers. John Neystadt john@neystadt.org http://www.neystadt.org/john/ ------_=_NextPart_001_01C1EE86.2D40BBD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D = ACTION:draft-neystadt-imap-status-counters-00.txt

> In draft-1, could you the non-ascii junk? I see = various =FC and =C6
> characters.

I was told already, I've used winword template that = produced this junk :( I'll clean it up.

> It seems unjustified. You mention one = application for it, and
> it sounds as
> if the code belongs in that IMAP client. If you = think that code really
> belongs in IMAP servers, I suggest showing more = uses in the draft.

This is today handled on clients and is used to = display counters either in folders tree or on some general summary = screen.

There are two main benefits of moving this logic to = server:

- in order to build them you must screen all message = headers in the mailbox, this is very slow and traffic intensive if done = on client

- server can store the counters and then = incrementally update the counters when new messages are delivered (in = MTA) or expunged and server do different clients. This saves much of = processing power for servers.

John Neystadt
john@neystadt.org
http://www.neystadt.org/john/

------_=_NextPart_001_01C1EE86.2D40BBD0-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3R1Uxa23072 for ietf-imapext-bks; Fri, 26 Apr 2002 18:30:59 -0700 (PDT) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3R1Uwa23068 for ; Fri, 26 Apr 2002 18:30:58 -0700 (PDT) Received: from mailscan-out3.cac.washington.edu (mailscan-out3.cac.washington.edu [140.142.32.18]) by mxout3.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g3R1V28J006381 for ; Fri, 26 Apr 2002 18:31:02 -0700 Received: FROM smtp.washington.edu BY mailscan-out3.cac.washington.edu ; Fri Apr 26 18:31:01 2002 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g3R1V0jv023572 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 26 Apr 2002 18:31:01 -0700 Date: Fri, 26 Apr 2002 18:30:59 -0700 (Pacific Daylight Time) From: Mark Crispin To: John Neystadt cc: ietf-imapext@imc.org, Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt In-Reply-To: <000e01c1ecff$d3a4c0d0$92d97ed4@icomverse.com> Message-ID: Organization: Networks & Distributed Computing 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, 26 Apr 2002, John Neystadt wrote: > BTW is \Flagged semantics is really "importance". If I > make my server (by Sieve or other mechanism) turn \Flagged on all messages > with "Importance: High" header, would that be ok. What are other uses for it > today? What \Flagged does is client-dependent, but the basic idea is to mark some kind of "importance" emphasis on the message. In the original MM program on the DEC-20, flagged messages were always announced with every new mail announcement. In more modern message-browser type programs, flagged messages are drawn with a box around them or in a bold font or with some sort of highlighting color to call attention to it. Since VPIM is essentially a client application, it is perfectly within its rights to decide that \Flagged means "Important" in the VPIM context, and to decide that the MDA should turn on \Flagged on all messages which have "Importance: High" in the header. In fact, I could see some non-VPIM users wanting to do that in the MDA. I agree with Arnt Gulbrandsen that you should try to leverage SEARCH as much as possible rather than try to extend STATUS. One thing that you could try to do is use STATUS to identify whether a mailbox should be subject to more detailed examination with SELECT+SEARCH. That was the original intent behind STATUS; to enable identification of "interesting" mailboxes without having to SELECT them. The more that you leverage existing tools, as opposed to requiring the creation of new tools, the better able you'll be able to deploy. Ideally, given 100% leverage, you'll be able to run your VPIM client software with any IMAP server; you may desire to have a special IMAP server that is optimized for VPIM, but there is an attraction to being able to plug in with any server. What concerns me is the possibility of making VPIM clients excessively and unnecessarily dependent upon a VPIM-extended server. This doesn't mean "thou shalt not extend IMAP for VPIM under any circumstances"!! It does, however, suggest that you should leverage aggressively and extend IMAP only if there's no way to leverage. Also, the more minimal a VPIM extension to IMAP is, the more likely it is that you'll get it generally implemented. For example, if a VPIM extension requires only about 15 minutes of programming work, I'm likely to do it in my server, just to preclude having to answer an email require to do it. If, on the other hand, an extension requires many hours of work, it's much less likely to happen without specific value to us. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. "A single glass of champagne imparts a feeling of exhiliaration. The nerves are braced; the imagination is agreeably strirred; the wits become more nimble. A bottle produces a contrary effect. Excess causes a comatose insensibility. So it is with war; and the quality of both is best discovered by sipping." -- Winston Churchill Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3Q9IAW18850 for ietf-imapext-bks; Fri, 26 Apr 2002 02:18:10 -0700 (PDT) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q9I9a18846 for ; Fri, 26 Apr 2002 02:18:09 -0700 (PDT) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g3Q9ICp01297; Fri, 26 Apr 2002 11:18:12 +0200 Date: Fri, 26 Apr 2002 11:18:12 +0200 From: Arnt Gulbrandsen To: John Neystadt Cc: Mark Crispin , ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Message-ID: <20020426111812.D1249@melkebalanse.gulbrandsen.priv.no> References: <000e01c1ecff$d3a4c0d0$92d97ed4@icomverse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000e01c1ecff$d3a4c0d0$92d97ed4@icomverse.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John Neystadt > C: STATUS abc COUNTERS[(\Seen AND $Fax-Message) (\Seen AND \Flagged AND > $Fax-Message) ...] > > This is long and somewhat cumbersome. That sounds like a few SEARCH commands joined together and renamed to STATUS. Perhaps using SEARCH (and maybe ANNOTATE) is enough? SEARCH may not scale as well as STATUS-COUNTERS would, but in this case I don't think that's a problem: "You have 1042300533 messages, 32765355 new and 42523145 important" is a nightmare no matter of efficiently it's implemented ;) --Arnt Received: by above.proper.com (8.11.6/8.11.3) id g3Q8pbM15952 for ietf-imapext-bks; Fri, 26 Apr 2002 01:51:37 -0700 (PDT) Received: from mxout1.netvision.net.il (mxout1.netvision.net.il [194.90.9.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q8pZa15943 for ; Fri, 26 Apr 2002 01:51:36 -0700 (PDT) Received: from johnnb ([212.126.217.146]) by mxout1.netvision.net.il (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GV600LC239D55@mxout1.netvision.net.il> for ietf-imapext@imc.org; Fri, 26 Apr 2002 11:51:18 +0300 (IDT) Date: Fri, 26 Apr 2002 10:53:19 +0200 From: John Neystadt Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt To: Mark Crispin Cc: ietf-imapext@imc.org, vpim@lists.neystadt.org Message-id: <000e01c1ecff$d3a4c0d0$92d97ed4@icomverse.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, > It certainly does seem to be very much specialized for VPIM, and doesn't seem > to make adequate attempt to leverage existing mechanisms. For example, why > not use IMAP keyword flags in association with delivery mechanisms that set > those flags, and then just extend STATUS to count other flags besides \Recent > and (not) \Seen. I think your proposal is very good for Unseen and may be Important (new flag or reuse \Flagged). BTW is \Flagged semantics is really "importance". If I make my server (by Sieve or other mechanism) turn \Flagged on all messages with "Importance: High" header, would that be ok. What are other uses for it today? Now there is a problem with Message-Context - since it is an extensible list of values (new ones can be added ad-hoc) then message flags will have to be added per each of them each time new values are added. In my proposal server sends response per all detected Message-Contexts. In your way we will have to introduce some mechanism for MUA to enumerate them. In additoin flags are not "typed" so MUA can't distinuigh between say $MDNSent and $Fax-Message which is confusing. Another issue is that \Seen changes dynamically. So in order to query for counter of \Seen fax messgase we will have to pass a boolean expression of flags to this new STATUS extension. For example: C: STATUS abc COUNTERS[(\Seen AND $Fax-Message) (\Seen AND \Flagged AND $Fax-Message) ...] This is long and somewhat cumbersome. > > In draft-1, could you the non-ascii junk? I see various | and F > > characters. > > I have to echo this comment; I don't know what produced that junk but it is > there and it is annoying. I apologize again. John Neystadt john@neystadt.org http://www.neystadt.org/john/ Received: by above.proper.com (8.11.6/8.11.3) id g3PKHqc07589 for ietf-imapext-bks; Thu, 25 Apr 2002 13:17:52 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (dhack@ikkoku-kan.panda.com [206.124.149.114]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PKHoa07584 for ; Thu, 25 Apr 2002 13:17:50 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id NAA17901; Thu, 25 Apr 2002 13:17:14 -0700 (PDT) Date: Thu, 25 Apr 2002 13:05:51 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt To: Arnt Gulbrandsen cc: "Neystadt, John" , ietf-imapext@imc.org, vpim@lists.neystadt.org In-Reply-To: <20020425151801.G906@melkebalanse.gulbrandsen.priv.no> 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, 25 Apr 2002 15:18:01 +0200, Arnt Gulbrandsen wrote: > "Neystadt, John" > > Until now I did not get a comments regarding matter of the draft. > > > > Does it makes sense? What do you think about it? > > It seems unjustified. You mention one application for it, and it sounds as > if the code belongs in that IMAP client. If you think that code really > belongs in IMAP servers, I suggest showing more uses in the draft. It certainly does seem to be very much specialized for VPIM, and doesn't seem to make adequate attempt to leverage existing mechanisms. For example, why not use IMAP keyword flags in association with delivery mechanisms that set those flags, and then just extend STATUS to count other flags besides \Recent and (not) \Seen. Regardless of whether this extension is intended for general implementation, or only for implementation in special VPIM boxes, I think that greater leveraging of existing IMAP mechanisms is desirable. In the general implementation case, it is to create a reason for it to be implemented; in the VPIM-only cases, it is because there's no harm in doing so. On the other hand, the intended implementation audience may make a difference on, for example, whether or not \Flagged can be used to implement "Important". But that's a minor issue in the overall scope of things. To summarize: you may have a good case to expand STATUS to return other data; but you have not (yet) made a good case to create new classes of data since it is conjectured that the desired information can be represented with existing data. In particular, please give strong consideration to using keyword flags. > In draft-1, could you the non-ascii junk? I see various | and F > characters. I have to echo this comment; I don't know what produced that junk but it is there and it is annoying. Received: by above.proper.com (8.11.6/8.11.3) id g3PDHjp23092 for ietf-imapext-bks; Thu, 25 Apr 2002 06:17:45 -0700 (PDT) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PDHia23087 for ; Thu, 25 Apr 2002 06:17:44 -0700 (PDT) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g3PDI1k01112; Thu, 25 Apr 2002 15:18:01 +0200 Date: Thu, 25 Apr 2002 15:18:01 +0200 From: Arnt Gulbrandsen To: "Neystadt, John" Cc: ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Message-ID: <20020425151801.G906@melkebalanse.gulbrandsen.priv.no> References: <767720C6032ED511AE8C00508BE3518E0654883E@ismailweb.icomverse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <767720C6032ED511AE8C00508BE3518E0654883E@ismailweb.icomverse.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Neystadt, John" > Until now I did not get a comments regarding matter of the draft. > > Does it makes sense? What do you think about it? It seems unjustified. You mention one application for it, and it sounds as if the code belongs in that IMAP client. If you think that code really belongs in IMAP servers, I suggest showing more uses in the draft. In draft-1, could you the non-ascii junk? I see various ü and Æ characters. --Arnt Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PClmH21288 for ietf-imapext-bks; Thu, 25 Apr 2002 05:47:48 -0700 (PDT) Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PClja21284 for ; Thu, 25 Apr 2002 05:47:45 -0700 (PDT) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.icomverse.com [10.116.200.32]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id g3PCfLX28741; Thu, 25 Apr 2002 15:41:21 +0300 Received: by il-tlv-mbdg1.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Thu, 25 Apr 2002 15:47:40 +0300 Message-ID: <767720C6032ED511AE8C00508BE3518E0654883E@ismailweb.icomverse.com> From: "Neystadt, John" To: ietf-imapext@imc.org, vpim@lists.neystadt.org Subject: RE: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Date: Thu, 25 Apr 2002 15:47:28 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EC57.5B5372F0" 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_01C1EC57.5B5372F0 Content-Type: text/plain; charset="koi8-r" Hi! Until now I did not get a comments regarding matter of the draft. Does it makes sense? What do you think about it? Regards, John Neystadt john@neystadt.org http://www.neystadt.org/john/ > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, April 23, 2002 1:14 PM > Cc: um@snowshore.com; ietf-imapext@imc.org; vpim@lists.neystadt.org > Subject: I-D ACTION:draft-neystadt-imap-status-counters-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : IMAP4 rev1 u STATUS-COUNTERS Extension > Author(s) : J. Neystadt > Filename : draft-neystadt-imap-status-counters-00.txt > Pages : 7 > Date : 22-Apr-02 > > This document describes STATUS-COUNTERS extension to IMAP4rev1 > protocol. This extension enables Mail User Agents to retrieve > messages counters grouped by message context. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/ > draft-neystadt-imap-status-counters-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-neystadt-imap-status-counters-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-neystadt-imap-status-counters-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ------_=_NextPart_001_01C1EC57.5B5372F0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable RE: I-D = ACTION:draft-neystadt-imap-status-counters-00.txt

Hi!

Until now I did not get a comments regarding matter = of the draft.

Does it makes sense? What do you think about = it?

Regards,

John Neystadt
john@neystadt.org
http://www.neystadt.org/john/


> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
> Sent: Tuesday, April 23, 2002 1:14 PM
> Cc: um@snowshore.com; ietf-imapext@imc.org; = vpim@lists.neystadt.org
> Subject: I-D = ACTION:draft-neystadt-imap-status-counters-00.txt
>
>
> A New Internet-Draft is available from the = on-line
> Internet-Drafts directories.
>
>
>       = Title           : IMAP4 = rev1 u STATUS-COUNTERS Extension
>       = Author(s)       : J. Neystadt
>       = Filename        : = draft-neystadt-imap-status-counters-00.txt
>       = Pages           : 7
>       = Date            : = 22-Apr-02
>      
> This document describes STATUS-COUNTERS = extension to IMAP4rev1
> protocol. This extension enables Mail User = Agents to retrieve
> messages counters grouped by message = context.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/
>       = draft-neystadt-imap-status-counters-00.txt
>
> To remove yourself from the IETF Announcement = list, send a message to
> ietf-announce-request with the word unsubscribe = in the body
> of the message.
>
> Internet-Drafts are also available by anonymous = FTP. Login
> with the username
> "anonymous" and a password of your = e-mail address. After logging in,
> type "cd internet-drafts" and = then
>       "get = draft-neystadt-imap-status-counters-00.txt".
>
> A list of Internet-Drafts directories can be = found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by = e-mail.
>
> Send a message to:
>       = mailserv@ietf.org.
> In the body type:
>       "FILE =
> = /internet-drafts/draft-neystadt-imap-status-counters-00.txt".
>      
> NOTE: The mail server at ietf.org can return = the document in
>       MIME-encoded = form by using the "mpack" utility.  To use this
>       feature, insert = the command "ENCODING mime" before the = "FILE"
>       command.  = To decode the response(s), you will need "munpack" or
>       a MIME-compliant = mail reader.  Different MIME-compliant
> mail readers
>       exhibit = different behavior, especially when dealing with
>       = "multipart" MIME messages (i.e. documents which have been = split
>       up into multiple = messages), so check your local documentation on
>       how to = manipulate these messages.
>       =        
>       =        
> Below is the data which will enable a MIME = compliant mail reader
> implementation to automatically retrieve the = ASCII version of the
> Internet-Draft.
>

------_=_NextPart_001_01C1EC57.5B5372F0-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3NBECN04905 for ietf-imapext-bks; Tue, 23 Apr 2002 04:14:12 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3NBEBa04901 for ; Tue, 23 Apr 2002 04:14:11 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11902; Tue, 23 Apr 2002 07:14:07 -0400 (EDT) Message-Id: <200204231114.HAA11902@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: um@snowshore.com, ietf-imapext@imc.org, vpim@lists.neystadt.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-neystadt-imap-status-counters-00.txt Date: Tue, 23 Apr 2002 07:14:07 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IMAP4 rev1 û STATUS-COUNTERS Extension Author(s) : J. Neystadt Filename : draft-neystadt-imap-status-counters-00.txt Pages : 7 Date : 22-Apr-02 This document describes STATUS-COUNTERS extension to IMAP4rev1 protocol. This extension enables Mail User Agents to retrieve messages counters grouped by message context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-neystadt-imap-status-counters-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-neystadt-imap-status-counters-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-neystadt-imap-status-counters-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020422135313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-neystadt-imap-status-counters-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-neystadt-imap-status-counters-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020422135313.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id g3GJHhE17669 for ietf-imapext-bks; Tue, 16 Apr 2002 12:17:43 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GJHfm17659 for ; Tue, 16 Apr 2002 12:17:41 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id g3GJHWua032208; Tue, 16 Apr 2002 15:17:32 -0400 Date: Tue, 16 Apr 2002 15:17:32 -0400 Message-Id: <200204161917.g3GJHWua032208@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Mark Crispin , Alexey Melnikov Cc: IMAP Extensions WG , iesg@ietf.org In-reply-to: <3CBC08E0.F94B4D14@messagingdirect.com> Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION to Proposed Standard References: <3CBC08E0.F94B4D14@messagingdirect.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: Date: Tue, 16 Apr 2002 05:20:00 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect Mark Crispin wrote: > I believe that the underlying problem is with RFC 2359 (which the > IESG has already accepted as a Proposed Standard), and not with > the MULTIAPPEND extension. The section entitled "MULTIAPPEND > Interaction with UIDPLUS Extension" in the MULTIAPPEND extension > is solely to document how MULTIAPPEND works with RFC 2359. IMHO, I think you should keep this section as there is currently no revision of RFC 2359. I agree. MULTIAPPEND is actually useless to me without UIDPLUS. I would be unhappy if the "Interactions with UIDPLUS" section was removed. [...] I will be happy if MULTIAPPEND clarifies that "m:n" is allowed in APPENDUID response. Yes, this follows from the syntax, but this might not occur to client impelementors. An example would be handy and as well as saying that "m:n" must not be sent by server if m>n. Yes, I agree with this. Making this clear is useful and doesn't hurt the specification in any way. Larry Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GBK6F14745 for ietf-imapext-bks; Tue, 16 Apr 2002 04:20:06 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GBK4m14740 for ; Tue, 16 Apr 2002 04:20:04 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g3GBK1j31506; Tue, 16 Apr 2002 05:20:01 -0600 Message-ID: <3CBC08E0.F94B4D14@messagingdirect.com> Date: Tue, 16 Apr 2002 05:20:00 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: iesg@ietf.org, IMAP Extensions WG , Lawrence Greenfield Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION to Proposed Standard 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: Mark Crispin wrote: > I have read and considered Alexey's comment. > > I believe that the underlying problem is with RFC 2359 (which the IESG has > already accepted as a Proposed Standard), and not with the MULTIAPPEND > extension. The section entitled "MULTIAPPEND Interaction with UIDPLUS > Extension" in the MULTIAPPEND extension is solely to document how MULTIAPPEND > works with RFC 2359. IMHO, I think you should keep this section as there is currently no revision of RFC 2359. > If Alexey's concerns are valid, these concerns are with RFC 2359 (as he notes > in his postscript ("The same problem exists with COPYUID response code > described in UIDPLUS extension"). If so, then the proper action is to block > further standards-track advancement of RFC 2359 until this problem is fixed in > a revision to RFC 2359. The MULTIAPPEND extension can be published by > eliminating the entire section entitled "MULTIAPPEND Interaction with UIDPLUS > Extension", and require that the revision to RFC 2359 document how UIDPLUS > should work in the MULTIAPPEND extension. > > Disclaimer: I do not implement the UIDPLUS extension, so it's of little > consequence to me if it is blocked. It is, however, of great consequence if > MULTIAPPEND is blocked since MULTIAPPEND is a major performace and > functionality boost. > > I am not convinced that Alexey's concerns are valid. > > Given his example of > a001 OK [APPENDUID 31345 10121:10117] Multiappend completed. > his possible interpretation of > #1 gets UID 10121, #2 - 10120, ..., #5 - 10117 (i.e. m, m-1,m-2,...,n) > is forbidden by RFC 2060, section 2.3.1.1: > [...] Unique identifiers are assigned in a strictly ascending > fashion in the mailbox; as each message is added to the mailbox it is > assigned a higher UID than the message(s) which were added > previously. Ok, you might be right for APPENDUID, but my example still stands for COPYUID, as there is no guaranty in which order server will perform COPY of a set of messages. Arguably MULTIAPPEND can be considered as a series of APPENDs in the order messages were specified. On the other hand MULTIAPPEND is atomic, so server can assign UIDs in any order it likes ;-). I will be happy if MULTIAPPEND clarifies that "m:n" is allowed in APPENDUID response. Yes, this follows from the syntax, but this might not occur to client impelementors. An example would be handy and as well as saying that "m:n" must not be sent by server if m>n. > This text is unchanged in draft-crispin-imapv-16.txt, the proposed update to > RFC 2060 which is currently in IESG last call. Consequently, only the > interpretation: > #1 gets UID 10117, #2 - 10118, ..., #5 - 10121 (i.e. n, n+1,n+2,...,m) > is valid. > > Furthermore, the specific example ("10121:10117") is silly and in all other > cases in IMAP is exactly equivalent to 10117:10221. > > In conclusion, I do not believe that MULTIAPPEND should be blocked for > publication by this concern; I didn't say blocked ;-). > and if this concern triggers any action it should be in the form of a revision > to RFC 2359. Nothing in the MULTIAPPEND extension can define the semantics of > UIDPLUS behavior; such definition > belongs in the UIDPLUS extension (RFC 2359 or successor). Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FIDRj00387 for ietf-imapext-bks; Mon, 15 Apr 2002 11:13:27 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (hgm@ikkoku-kan.panda.com [206.124.149.114]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FIDPm00383 for ; Mon, 15 Apr 2002 11:13:25 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA01353; Mon, 15 Apr 2002 11:12:42 -0700 (PDT) Date: Mon, 15 Apr 2002 10:55:57 -0700 (PDT) From: Mark Crispin Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION to Proposed Standard To: Alexey Melnikov cc: iesg@ietf.org, IMAP Extensions WG , Lawrence Greenfield In-Reply-To: <3CB9F5AF.167327E9@messagingdirect.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 have read and considered Alexey's comment. I believe that the underlying problem is with RFC 2359 (which the IESG has already accepted as a Proposed Standard), and not with the MULTIAPPEND extension. The section entitled "MULTIAPPEND Interaction with UIDPLUS Extension" in the MULTIAPPEND extension is solely to document how MULTIAPPEND works with RFC 2359. If Alexey's concerns are valid, these concerns are with RFC 2359 (as he notes in his postscript ("The same problem exists with COPYUID response code described in UIDPLUS extension"). If so, then the proper action is to block further standards-track advancement of RFC 2359 until this problem is fixed in a revision to RFC 2359. The MULTIAPPEND extension can be published by eliminating the entire section entitled "MULTIAPPEND Interaction with UIDPLUS Extension", and require that the revision to RFC 2359 document how UIDPLUS should work in the MULTIAPPEND extension. Disclaimer: I do not implement the UIDPLUS extension, so it's of little consequence to me if it is blocked. It is, however, of great consequence if MULTIAPPEND is blocked since MULTIAPPEND is a major performace and functionality boost. I am not convinced that Alexey's concerns are valid. Given his example of a001 OK [APPENDUID 31345 10121:10117] Multiappend completed. his possible interpretation of #1 gets UID 10121, #2 - 10120, ..., #5 - 10117 (i.e. m, m-1,m-2,...,n) is forbidden by RFC 2060, section 2.3.1.1: [...] Unique identifiers are assigned in a strictly ascending fashion in the mailbox; as each message is added to the mailbox it is assigned a higher UID than the message(s) which were added previously. This text is unchanged in draft-crispin-imapv-16.txt, the proposed update to RFC 2060 which is currently in IESG last call. Consequently, only the interpretation: #1 gets UID 10117, #2 - 10118, ..., #5 - 10121 (i.e. n, n+1,n+2,...,m) is valid. Furthermore, the specific example ("10121:10117") is silly and in all other cases in IMAP is exactly equivalent to 10117:10221. In conclusion, I do not believe that MULTIAPPEND should be blocked for publication by this concern; and if this concern triggers any action it should be in the form of a revision to RFC 2359. Nothing in the MULTIAPPEND extension can define the semantics of UIDPLUS behavior; such definition belongs in the UIDPLUS extension (RFC 2359 or successor). -- Mark -- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3F9X5b10328 for ietf-imapext-bks; Mon, 15 Apr 2002 02:33:05 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3F9X3m10323 for ; Mon, 15 Apr 2002 02:33:04 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g3F9Wuj18644; Mon, 15 Apr 2002 03:32:56 -0600 Message-ID: <3CB9F5AF.167327E9@messagingdirect.com> Date: Sun, 14 Apr 2002 15:33:35 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: iesg@ietf.org CC: Mark Crispin , IMAP Extensions WG , Lawrence Greenfield Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION to Proposed Standard References: <200203251902.OAA26608@ietf.org> 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: The IESG wrote: > The IESG has received a request to consider INTERNET MESSAGE ACCESS > PROTOCOL - MULTIAPPEND EXTENSION > as a Proposed Standard. This > has been reviewed in the IETF but is not the product of an IETF Working > Group. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by April 24, 2002. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-crispin-imap-multiappend-05.txt (I've sent this comment to Mark privately and he suggested that I post the comment on the imapext mailing list). I have a comment about MULTIAPPEND document regarding the section that defines interaction with UIDPLUS extension: >MULTIAPPEND Interaction with UIDPLUS Extension > > Servers which support both MULTIAPPEND and [UIDPLUS] will have the > "resp-code-apnd" rule modified as follows: > > resp-code-apnd = "APPENDUID" SP nz-number SP set > > That is, the APPENDUID response code returns as many UIDs as there > were messages appended in the multiple append. The UIDs returned > should be in the order the articles where appended. The message set > may not contain extraneous UIDs or the symbol "*". Unfortunately even with restrictions in the last paragraph, the ABNF for "set" still allows for ambiguous cases. Set can be a comma delimited list of numbers (e.g. "10117,10118,10119" [case 1: a,b,c]), a range construct (e.g. "10117:10119" [case 2: m:n, m < n] or "10119:10117" [case 3: "m:n", m >= n]) or a combination of those. Lets consider the following example. Client appended 4 messages and server support both MULTIAPPEND and UIDPLUS. Server can return [case 1]: a001 OK [APPENDUID 31345 10117,10118,10119,10120,10121] Multiappend completed. and this has a well understood semantics, i.e. appended message #1 gets UID 10117, #2 - 10118, ..., #5 - 10121 Some implementations (including CMU Cyrus server) will use "compressed" representation of this set to minimize amount of data sent across network [case 2]: a001 OK [APPENDUID 31345 10117:10121] Multiappend completed. and this seems to be a logical extension of the previous. Now, it is not clear what client is supposed to do if the server decides to return the following [case 3]: a001 OK [APPENDUID 31345 10121:10117] Multiappend completed. One possible interpretation: #1 gets UID 10121, #2 - 10120, ..., #5 - 10117 (i.e. m, m-1,m-2,...,n) Another possible interpretation: #1 gets UID 10117, #2 - 10118, ..., #5 - 10121 (i.e. n, n+1,n+2,...,m) I suggest that the case 3 is either explicitly prohibited or the document clarifies how the client should interpret the result. Regards, Alexey Melnikov P.S. The same problem exists with COPYUID response code described in UIDPLUS extension. __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g32JNTn12211 for ietf-imapext-bks; Tue, 2 Apr 2002 11:23:29 -0800 (PST) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g32JNSm12205 for ; Tue, 2 Apr 2002 11:23:28 -0800 (PST) Received: from mailscan-out3.cac.washington.edu (mailscan-out3.cac.washington.edu [140.142.32.18]) by mxout3.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g32JNU8J005823 for ; Tue, 2 Apr 2002 11:23:30 -0800 Received: FROM smtp.washington.edu BY mailscan-out3.cac.washington.edu ; Tue Apr 02 11:23:30 2002 -0800 Received: from Shimo-Tomobiki.Panda.COM (D-140-142-21-32.dhcp2.washington.edu [140.142.21.32]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g32JNOkx013876 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 2 Apr 2002 11:23:29 -0800 Date: Tue, 2 Apr 2002 11:23:22 -0800 (Pacific Standard Time) From: Mark Crispin To: Jutta Degener cc: ietf-imapext@imc.org Subject: Re: ACL 2: Why $ and not / ? In-Reply-To: <20020402140310.GA1371@jutta.sendmail.com> Message-ID: Organization: Networks & Distributed Computing 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 Tue, 2 Apr 2002, Jutta Degener wrote: > Why did choose "$" as a > prefix character and not "/" as in RFC 2244 (ACAP)? It was more or less selected out of the air. I originally advocated $, but I would not quarrel if it became something else. My main interest is in there being a formal and unambiguous theory of ACL identifiers (one which does not overlap the world identifier with a user named "anyone"), rather than picking a particular character. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g32IHfP08667 for ietf-imapext-bks; Tue, 2 Apr 2002 10:17:41 -0800 (PST) Received: from mx.crypto.com (mx.crypto.com [207.140.168.138]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g32IHdm08655 for ; Tue, 2 Apr 2002 10:17:39 -0800 (PST) Received: from jutta.sendmail.com (localhost [127.0.0.1]) by MultiHostMXServer (8.9.3/8.9.x4) with ESMTP id NAA31549 for ; Tue, 2 Apr 2002 13:17:40 -0500 (EST) Received: by jutta.sendmail.com (Postfix, from userid 500) id C4BD119210; Tue, 2 Apr 2002 06:03:11 -0800 (PST) Date: Tue, 2 Apr 2002 06:03:10 -0800 From: Jutta Degener To: ietf-imapext@imc.org Subject: ACL 2: Why $ and not / ? Message-ID: <20020402140310.GA1371@jutta.sendmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.24i Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Why did choose "$" as a prefix character and not "/" as in RFC 2244 (ACAP)? Granted, "/" is fixed as a hierarchy separator in ACAP and not in IMAP, but isn't it still a _common_ hierarchy separator in IMAP? It's certainly more popular, and more frequently excluded from user names, than "$". Is there a user name scheme that IMAP is trying to support where identifiers do start with "/"? If not, wouldn't it be desirable to keep the number of different user name encoding schemes low and perhaps align ACL2 with ACAP? Jutta Degener