Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UDlPi2073909 for ; Wed, 30 Apr 2003 06:47:25 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UDlPVX073908 for ietf-imapext-bks; Wed, 30 Apr 2003 06:47:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UDlNi2073903 for ; Wed, 30 Apr 2003 06:47:24 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3UDlBbT019529; Wed, 30 Apr 2003 15:47:12 +0200 To: Arnt Gulbrandsen Cc: Rob Siemborski , Philip Guenther , Harrie Hazewinkel , Michael Fair , IMAP Extensions WG Subject: Re: IMAP Capability and Virtual Domains References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> <6VpYHVNLMn+i5DOZ665vZQ.md5@melkebalanse.gulbrandsen.priv.no> From: Simon Josefsson X-Payment: hashcash 1.2 0:030430:arnt@gulbrandsen.priv.no:645bcb69cdb12b07 X-Hashcash: 0:030430:arnt@gulbrandsen.priv.no:645bcb69cdb12b07 X-Payment: hashcash 1.2 0:030430:rjs3@andrew.cmu.edu:4f0142d4f4107a98 X-Hashcash: 0:030430:rjs3@andrew.cmu.edu:4f0142d4f4107a98 X-Payment: hashcash 1.2 0:030430:guenther@sendmail.com:cf58492e46086358 X-Hashcash: 0:030430:guenther@sendmail.com:cf58492e46086358 X-Payment: hashcash 1.2 0:030430:harrie@inet.it:b7fef978a01ec516 X-Hashcash: 0:030430:harrie@inet.it:b7fef978a01ec516 X-Payment: hashcash 1.2 0:030430:michael@daclubhouse.net:b4b89f492619b544 X-Hashcash: 0:030430:michael@daclubhouse.net:b4b89f492619b544 X-Payment: hashcash 1.2 0:030430:ietf-imapext@imc.org:511cf7fd847f3431 X-Hashcash: 0:030430:ietf-imapext@imc.org:511cf7fd847f3431 Date: Wed, 30 Apr 2003 15:47:11 +0200 In-Reply-To: <6VpYHVNLMn+i5DOZ665vZQ.md5@melkebalanse.gulbrandsen.priv.no> (Arnt Gulbrandsen's message of "Wed, 30 Apr 2003 11:03:03 +0200") Message-ID: User-Agent: Gnus/5.09002 (Oort Gnus v0.20) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen writes: > Rob Siemborski writes: >> On Tue, 29 Apr 2003, Michael Fair wrote: >> >>> I'm still assuming that people on this list are still somewhat >>> dubious about whether or not virtual hosting multiple domains on a >>> single IP address is even useful. >> >> I agree that virtual hosting on a single IP is useful. I'm >> personally unconvinced of the necessity of a VHOST command (or other >> additional argument to CAPABILITY) to do this, its almost entirely >> possible to do this using realms on user ids. > > The realms usage I see in RFC 2831 seems a little different. Realms > there aren't hostnames, and they're used for a multiple-choice > question. Basically, the server tells the client "pick one of these > realms" and the client does, perhaps using a listbox or menu. > > I would not want to give every IMAP client my customer list, > particularly not before authentication. And I would not want to tell > random IMAP clients "here, make a thousand-item pop-up menu and ask > the user to pick one". DIGEST-MD5 allows the realm field in step 1 to be empty, and in this case the client is allowed to chose a realm on their own. DIGEST-MD5 doesn't have to be used as "pick one of these realms". However, if the server sends some realms, the server SHOULD pick one of them. I hoped that 2831bis would allow the client to pick any realm it wants, regardless of what the server sent, thus further moving away from the problem you describe, but this doesn't seem to have happened. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UDNOi2073287 for ; Wed, 30 Apr 2003 06:23:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UDNOlE073286 for ietf-imapext-bks; Wed, 30 Apr 2003 06:23:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UDNHi2073268 for ; Wed, 30 Apr 2003 06:23:20 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp7.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3UDNCrh007015; Wed, 30 Apr 2003 09:23:12 -0400 Date: Wed, 30 Apr 2003 09:23:11 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: Philip Guenther , Harrie Hazewinkel , Michael Fair , IMAP Extensions WG Subject: Re: IMAP Capability and Virtual Domains In-Reply-To: <6VpYHVNLMn+i5DOZ665vZQ.md5@melkebalanse.gulbrandsen.priv.no> Message-ID: References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> <6VpYHVNLMn+i5DOZ665vZQ.md5@melkebalanse.gulbrandsen.priv.no> 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 Wed, 30 Apr 2003, Arnt Gulbrandsen wrote: > The realms usage I see in RFC 2831 seems a little different. Realms > there aren't hostnames, and they're used for a multiple-choice > question. Basically, the server tells the client "pick one of these > realms" and the client does, perhaps using a listbox or menu. Realms in DIGEST-MD5 are a little strange. But you *can* just append a @ or a % to an authentication identifier, followed by a domain, and call it a realm. This works with a much larger variety of SASL mechanisms. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U92Ni2057469 for ; Wed, 30 Apr 2003 02:02:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U92Nrb057468 for ietf-imapext-bks; Wed, 30 Apr 2003 02:02:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U92Mi2057461 for ; Wed, 30 Apr 2003 02:02:23 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:23717 "ehlo melkebalanse.gulbrandsen.priv.no" ident: "NO-IDENT-SERVICE[2]") by bra.gulbrandsen.priv.no with ESMTP id ; Wed, 30 Apr 2003 11:02:08 +0200 Message-Id: <6VpYHVNLMn+i5DOZ665vZQ.md5@melkebalanse.gulbrandsen.priv.no> From: Arnt Gulbrandsen To: Rob Siemborski Subject: Re: IMAP Capability and Virtual Domains Cc: Philip Guenther , Harrie Hazewinkel , Michael Fair , IMAP Extensions WG References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Wed, 30 Apr 2003 11:03:03 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: > On Tue, 29 Apr 2003, Michael Fair wrote: > >> I'm still assuming that people on this list are still somewhat >> dubious about whether or not virtual hosting multiple domains on a >> single IP address is even useful. > > I agree that virtual hosting on a single IP is useful. I'm personally > unconvinced of the necessity of a VHOST command (or other additional > argument to CAPABILITY) to do this, its almost entirely possible to > do this using realms on user ids. The realms usage I see in RFC 2831 seems a little different. Realms there aren't hostnames, and they're used for a multiple-choice question. Basically, the server tells the client "pick one of these realms" and the client does, perhaps using a listbox or menu. I would not want to give every IMAP client my customer list, particularly not before authentication. And I would not want to tell random IMAP clients "here, make a thousand-item pop-up menu and ask the user to pick one". > The only problem using realms with user IDs doesn't solve is the fact > that you don't know which certificate to present during a STARTTLS. I > suppose this can be solved with an argument to STARTTLS. You'd need > to advertise a new STARTTLS_WITH_DOMAIN capability too. As Simon Josefsson said, the TLS people are dealing with that. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U4Qxi2022244 for ; Tue, 29 Apr 2003 21:26:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U4QxX3022243 for ietf-imapext-bks; Tue, 29 Apr 2003 21:26:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U4Qvi2022238 for ; Tue, 29 Apr 2003 21:26:58 -0700 (PDT) (envelope-from leg+@andrew.cmu.edu) Received: from majormajor.REM.CMU.EDU (DYN-4-221.CC.cmu.edu [128.2.4.221] (may be forged)) (user=leg mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3U4Qvfg021619 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 30 Apr 2003 00:26:57 -0400 Date: Wed, 30 Apr 2003 00:26:31 -0400 From: Lawrence Greenfield To: Timo Sirainen , ned+imapext@INNOSOFT.COM cc: ietf-imapext@imc.org, ned.freed@mrochek.com, hardie@qualcomm.com Subject: Re: Review requested: draft-siemborski-mupdate-03.txt to be published as an experimental RFC Message-ID: <194349820.1051662391@majormajor.REM.CMU.EDU> In-Reply-To: <1051676131.26178.279.camel@hurina> References: <01KVAS4J29VM007FVT@mauve.mrochek.com> <1051676131.26178.279.camel@hurina> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, April 30, 2003 7:15 AM +0300 Timo Sirainen wrote: > Just one question: Is there a reason why this should be RFC? I can see > that specific server implementations might want to use this internally, > but I just can't see why it should be interoperable with anything else > but itself. Would someone actually want to create an IMAP server farm > consisting of completely different IMAP server implementations? The purpose of documenting this isn't necessarily to get interoperable implementations, but to document the protocol and the approach for the future so that the community has a stable reference to an open approach that's been done before. Larry Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U4FWi2022021 for ; Tue, 29 Apr 2003 21:15:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U4FWmj022020 for ietf-imapext-bks; Tue, 29 Apr 2003 21:15:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U4FUi2022015 for ; Tue, 29 Apr 2003 21:15:30 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id B39CF5E107F8; Wed, 30 Apr 2003 07:15:32 +0300 (EEST) Subject: Re: Review requested: draft-siemborski-mupdate-03.txt to be published as an experimental RFC From: Timo Sirainen To: ned+imapext@INNOSOFT.COM Cc: ietf-imapext@imc.org, ned.freed@mrochek.com, hardie@qualcomm.com In-Reply-To: <01KVAS4J29VM007FVT@mauve.mrochek.com> References: <01KVAS4J29VM007FVT@mauve.mrochek.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051676131.26178.279.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 30 Apr 2003 07:15:32 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-04-29 at 22:06, ned+imapext@INNOSOFT.COM wrote: > I've received a request from the author to publish > > The MUPDATE Distributed Mailbox Database Protocol > draft-siemborski-mupdate-03.txt > > as an experimental RFC. It is customary for area directors to ask for > such documents to be reviewed by one or more working groups working in the > same or related area. Accordingly, I'm asking folks involved in IMAPEXT > to review this document and comment on its suitability for publication as > an experimental protocol. Just one question: Is there a reason why this should be RFC? I can see that specific server implementations might want to use this internally, but I just can't see why it should be interoperable with anything else but itself. Would someone actually want to create an IMAP server farm consisting of completely different IMAP server implementations? Or maybe there's some other uses that aren't obvious to me? I had to read Cyrus Aggregator web page before really even understanding how this protocol was supposed to be used. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U2gti2019320 for ; Tue, 29 Apr 2003 19:42:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U2gt2S019319 for ietf-imapext-bks; Tue, 29 Apr 2003 19:42:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U2gri2019313 for ; Tue, 29 Apr 2003 19:42:53 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 3D4FA883DD6; Tue, 29 Apr 2003 19:42:56 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 0BDE78831EB; Tue, 29 Apr 2003 19:42:55 -0700 (PDT) Message-ID: <01e901c30ec2$268376e0$d1d07b43@cocacola> From: "Michael Fair" To: "Simon Josefsson" Cc: "Abhijit Menon-Sen" , References: <019701c30dd9$d6019c80$d1d07b43@cocacola><00fa01c30e21$430c6020$d1d07b43@cocacola><20030430053747.F8948@lustre.dyn.wiw.org><01ac01c30eb6$16088640$d1d07b43@cocacola> Subject: Re: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 19:42:32 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Some environments will chose to not use STARTTLS, so this will never > hold. But some environments would chose to not use VHOST too, so I > don't see the difference. You can't ask for more than that people are > required to implement a feature -- whether it is used or not depends > on other things -- and people are already required to implement > STARTTLS. The difference is that with this proposed solution whether or not someone can use VHOST is completely predicated on whether or not they simultaneously use TLS. With this proposal if you want to use VHOST, you MUST use TLS - no choice - no option - no way around it - either use TLS or don't have per domain specific configs. I find unrealisticly limiting. Whether or not someone uses TLS is a totally separate decision from whether or not the they use virtualized hosting. Especially for domains specific configs that might not want to use TLS for whatever reason. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U1xhi2018177 for ; Tue, 29 Apr 2003 18:59:43 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U1xhTI018176 for ietf-imapext-bks; Tue, 29 Apr 2003 18:59:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U1xfi2018170 for ; Tue, 29 Apr 2003 18:59:42 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3U1xcbT002876; Wed, 30 Apr 2003 03:59:38 +0200 To: "Michael Fair" Cc: "Abhijit Menon-Sen" , Subject: Re: IMAP Capability and Virtual Domains References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <20030430053747.F8948@lustre.dyn.wiw.org> <01ac01c30eb6$16088640$d1d07b43@cocacola> From: Simon Josefsson X-Payment: hashcash 1.2 0:030430:michael@daclubhouse.net:9d08d78c232e46c7 X-Hashcash: 0:030430:michael@daclubhouse.net:9d08d78c232e46c7 X-Payment: hashcash 1.2 0:030430:ams@wiw.org:2eda68a84d553ccf X-Hashcash: 0:030430:ams@wiw.org:2eda68a84d553ccf X-Payment: hashcash 1.2 0:030430:ietf-imapext@imc.org:1fad1990737f6472 X-Hashcash: 0:030430:ietf-imapext@imc.org:1fad1990737f6472 Date: Wed, 30 Apr 2003 03:59:37 +0200 In-Reply-To: <01ac01c30eb6$16088640$d1d07b43@cocacola> (Michael Fair's message of "Tue, 29 Apr 2003 18:16:10 -0700") Message-ID: User-Agent: Gnus/5.09002 (Oort Gnus v0.20) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Michael Fair" writes: >> At 2003-04-30 00:38:48 +0200, jas@extundo.com wrote: >> > >> > Support draft-ietf-tls-extensions-06.txt in your STARTTLS >> > implementation. >> > >> > This is not a IMAP specific problem, so a IMAP specific solution is >> > not the best solution, engineering wise. >> >> I strongly prefer this approach over an optional argument to CAPABILITY, >> or a separate VHOST command, particularly since STARTTLS support is now >> mandatory for both servers and clients. > > I'm afraid I missed the part where the use of STARTTLS became > mandatory. See RFC 3501: Client and server implementations MUST implement the STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS]) capabilities. > Fortunately it's generally accepted that STARTTLS > requires a new CAPABILITY announcement anyway, thus if it can > be shown that all implementations of both clients and servers > not only support but MUST also use STARTTLS whenever it's > available then I'd probably accept this as a solution that > will work. Some environments will chose to not use STARTTLS, so this will never hold. But some environments would chose to not use VHOST too, so I don't see the difference. You can't ask for more than that people are required to implement a feature -- whether it is used or not depends on other things -- and people are already required to implement STARTTLS. This doesn't mean they are required to implement the TLS extension though... > It'd be harder to debug since you will now need to get something > more intelligent than telnet to test against, but I'm sure > there'll be tools to help with that (perhaps even an updated telnet). The tools exists. The problem isn't specific to TLS, some SASL mechanisms also encrypts the connection. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U1GUi2016901 for ; Tue, 29 Apr 2003 18:16:30 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U1GUsg016900 for ietf-imapext-bks; Tue, 29 Apr 2003 18:16:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U1GSi2016895 for ; Tue, 29 Apr 2003 18:16:28 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 1CDC0883DD6; Tue, 29 Apr 2003 18:16:31 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id E8AF88831EB; Tue, 29 Apr 2003 18:16:29 -0700 (PDT) Message-ID: <01ac01c30eb6$16088640$d1d07b43@cocacola> From: "Michael Fair" To: "Abhijit Menon-Sen" , References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <20030430053747.F8948@lustre.dyn.wiw.org> Subject: Re: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 18:16:10 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > At 2003-04-30 00:38:48 +0200, jas@extundo.com wrote: > > > > Support draft-ietf-tls-extensions-06.txt in your STARTTLS > > implementation. > > > > This is not a IMAP specific problem, so a IMAP specific solution is > > not the best solution, engineering wise. > > I strongly prefer this approach over an optional argument to CAPABILITY, > or a separate VHOST command, particularly since STARTTLS support is now > mandatory for both servers and clients. I'm afraid I missed the part where the use of STARTTLS became mandatory. Fortunately it's generally accepted that STARTTLS requires a new CAPABILITY announcement anyway, thus if it can be shown that all implementations of both clients and servers not only support but MUST also use STARTTLS whenever it's available then I'd probably accept this as a solution that will work. It'd be harder to debug since you will now need to get something more intelligent than telnet to test against, but I'm sure there'll be tools to help with that (perhaps even an updated telnet). Currently what's on the table is a Client Capability string. While I disagree that being able to select a VHOST context isn't a capability I'm not really opposed to anything that solves the whole problem. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U07pi2014990 for ; Tue, 29 Apr 2003 17:07:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U07p1j014989 for ietf-imapext-bks; Tue, 29 Apr 2003 17:07:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from miranda.org (IDENT:qmailr@miranda.org [209.58.150.153]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3U07oi2014984 for ; Tue, 29 Apr 2003 17:07:51 -0700 (PDT) (envelope-from ams@wiw.org) Received: (qmail 23457 invoked from network); 30 Apr 2003 00:07:50 -0000 Received: from miranda.org (HELO lustre.dyn.wiw.org) (ams@209.58.150.153) by miranda.org with SMTP; 30 Apr 2003 00:07:50 -0000 Received: from ams by lustre.dyn.wiw.org with local (Exim 3.36 #1) id 19Af8V-00039k-00; Wed, 30 Apr 2003 05:37:47 +0530 Date: Wed, 30 Apr 2003 05:37:47 +0530 From: Abhijit Menon-Sen To: ietf-imapext@imc.org Cc: Michael Fair Subject: Re: IMAP Capability and Virtual Domains Message-ID: <20030430053747.F8948@lustre.dyn.wiw.org> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> 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: At 2003-04-30 00:38:48 +0200, jas@extundo.com wrote: > > Support draft-ietf-tls-extensions-06.txt in your STARTTLS > implementation. > > This is not a IMAP specific problem, so a IMAP specific solution is > not the best solution, engineering wise. I strongly prefer this approach over an optional argument to CAPABILITY, or a separate VHOST command, particularly since STARTTLS support is now mandatory for both servers and clients. While a client capability string may be a good idea for other reasons, I don't think a virtual host selection mechanism should be shoehorned into it. It may be quite convenient, but it isn't a capability, and shouldn't be treated as one. -- ams Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNnpi2014600 for ; Tue, 29 Apr 2003 16:49:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TNnpN3014599 for ietf-imapext-bks; Tue, 29 Apr 2003 16:49:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNnni2014592 for ; Tue, 29 Apr 2003 16:49:49 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 16E905E107F8; Wed, 30 Apr 2003 02:49:51 +0300 (EEST) Subject: Re: IMAP Capability and Virtual Domains From: Timo Sirainen To: Michael Fair Cc: Philip Guenther , ietf-imapext@imc.org, Harrie Hazewinkel In-Reply-To: <012d01c30ea2$f6559300$d1d07b43@cocacola> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> <1051653875.26181.251.camel@hurina> <012d01c30ea2$f6559300$d1d07b43@cocacola> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051660190.26181.260.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 30 Apr 2003 02:49:51 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2003-04-30 at 01:59, Michael Fair wrote: > I actually happen to like Cyrus Daboo's latest proposal > of doing something like: > CAPABILITY VHOST=fqdn.example.com RLIST LANGUAGE=en_US,en_GB Fine with me, except that should be more IMAP way to avoid creating new parsers for server: * OK [CLIENTCAPABILITY] (or something) 1 CAPABILITY VHOST (fqdn.example.com) RLIST LANGUAGE (en_US en_GB) Server could just ignore capabilities it isn't interested in. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNC6i2013681 for ; Tue, 29 Apr 2003 16:12:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TNC6RG013680 for ietf-imapext-bks; Tue, 29 Apr 2003 16:12:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNC5i2013675 for ; Tue, 29 Apr 2003 16:12:05 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 78797883D93; Tue, 29 Apr 2003 16:12:07 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 3CAB78831EB; Tue, 29 Apr 2003 16:12:06 -0700 (PDT) Message-ID: <013f01c30ea4$b735fd20$d1d07b43@cocacola> From: "Michael Fair" To: "Cyrus Daboo" , Cc: "Harrie Hazewinkel" References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <1044733467.1051637254@PLATO.cyrusoft.com> <009a01c30e9a$e5abcd60$d1d07b43@cocacola> <1048623330.1051641144@PLATO.cyrusoft.com> Subject: Re: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 16:11:50 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Hi Michael, > > --On Tuesday, April 29, 2003 3:01 PM -0700 Michael Fair > wrote: > > | The one reservation I have about using a separate VHOST command > | that returns the same response as CAPABILITY is that you've now > | created to commands that do essentailly the exact same thing. > > Fine, but if we are going to extend capability lets do it in a way that > will allow future parameters to be easily added, e.g. use the capability > response syntax for the client command: > > a CAPABILITY VHOST=fqdn.example.com RLIST LANGUAGE=en_US,en_GB That would be great! Servers that don't care can still swallow it, and other perceived usefulness results. Great call! So what do we put in the HELLO response to give the client foreknowledge for accepting the extra info? Should we follow the SMTP example and prepend hello with [ECAPABILITY] and then create an ECAPABILITY command? Or are people comfortable with keeping the same named CAPABILITY command? I'm personally rather partial to not change the command name. But then again, I'm also the one who doesn't mind a client trying and failing as a method for determining whether or not this server supports what will be the norm. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMxXi2013414 for ; Tue, 29 Apr 2003 15:59:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TMxX56013413 for ietf-imapext-bks; Tue, 29 Apr 2003 15:59:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMxWi2013408 for ; Tue, 29 Apr 2003 15:59:32 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 216F9883D93; Tue, 29 Apr 2003 15:59:34 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id E19408831EB; Tue, 29 Apr 2003 15:59:32 -0700 (PDT) Message-ID: <012d01c30ea2$f6559300$d1d07b43@cocacola> From: "Michael Fair" To: "Timo Sirainen" Cc: "Philip Guenther" , , "Harrie Hazewinkel" References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> <1051653875.26181.251.camel@hurina> Subject: Re: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 15:59:17 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On Tue, 2003-04-29 at 23:51, Michael Fair wrote: > > But you also mentioned PREAUTH the and intitial OK. Let's talk > > about the initial OK for a second. This is acutally pretty cool > > and something I hadn't thought about. If we leave VHOST as part > > of the CAPABILITY announcement we can preinform a client about > > whether or not the server supports domain specific configs. > > This sounds good to me. To save some roundtrips, it could include > capability in it's reply as well: > > * OK [VHOST] IMAP server ready. > 1 VHOST foo.bar.org > 1 OK [CAPABILITY IMAP4rev1 ...] > 2 STARTTLS > 2 OK > ..etc.. If you're going to bother with a VHOST command that returns a CAPABILITY response why not just add it to CAPABILITY and make the argument valid SOLELY in the presence of a preannounced VHOST capability. It keeps the command set down and reduces the number of different commands that essentially do the exact same things. For instance, what's the difference between the above and: * OK [VHOST] IMAP server ready. 1 CAPABILITY foo.bar.org 1 OK [CAPABILITY IMAP4rev1 ...] 2 STARTTLS 2 OK ..etc.. I actually happen to like Cyrus Daboo's latest proposal of doing something like: CAPABILITY VHOST=fqdn.example.com RLIST LANGUAGE=en_US,en_GB -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMhYi2013088 for ; Tue, 29 Apr 2003 15:43:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TMhY1G013087 for ietf-imapext-bks; Tue, 29 Apr 2003 15:43:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-in.rrz.uni-koeln.de (smtp-in.rrz.Uni-Koeln.DE [134.95.19.47]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMhWi2013081 for ; Tue, 29 Apr 2003 15:43:33 -0700 (PDT) (envelope-from Hagedorn@spinfo.uni-koeln.de) Received: from [192.168.1.11] (xdsl-213-168-110-58.netcologne.de [213.168.110.58]) (authenticated as user a0620 using DIGEST-MD5 bits=0) by cyrus.rrz.uni-koeln.de (8.12.9/8.12.8) with ESMTP id h3TMhRXM031140; Wed, 30 Apr 2003 00:43:28 +0200 Date: Wed, 30 Apr 2003 00:43:25 +0200 From: Sebastian Hagedorn To: Michael Fair cc: ietf-imapext@imc.org Subject: Re: IMAP Capability and Virtual Domains Message-ID: <2147483647.1051663404@[192.168.1.11]> In-Reply-To: <007a01c30e91$1a391060$d1d07b43@cocacola> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> X-Mailer: Mulberry/3.0.3 (Mac OS X) Message-Context: text-message X-Spook: nuclear nuke spy secret assassination cia fbi nsa president MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2147493761==========" X-Virus-Scanned: by amavisd-new Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==========2147493761========== Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline -- Michael Fair is rumored to have mumbled on=20 Dienstag, 29. April 2003 13:51 Uhr -0700 regarding Re: IMAP Capability and=20 Virtual Domains : > For instance Outlook[ Express] only supports LOGIN. I wouldn't > want to enable that except for domains that required it. Just FYI: the most recent versions of Cyrus SASL and Cyrus IMAP offer NTLM=20 as an option, which is working pretty well with Outlook (Express) in my=20 experience. I know, it's not a standard, but if I have to choose between=20 LOGIN and that I prefer the latter ... Cheers, Sebastian -- Sebastian Hagedorn M.A. - Postmaster - RZKR-R1 (Flachbau), Zimmer 18 Zentrum f=FCr angewandte Informatik - Universit=E4tsweiter Service RRZK Universit=E4t zu K=F6ln / Cologne University - Tel. +49-221-478-5587 --==========2147493761========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iEYEARECAAYFAj6vAA4ACgkQGXsGmU0QW0W7zgCfev1scFMF8qA+6xH7M6Zp2sOX s/UAoMiqjEo49l8lt0td7mc0c2114TBF =eMBf -----END PGP SIGNATURE----- --==========2147493761==========-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMcri2013003 for ; Tue, 29 Apr 2003 15:38:53 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TMcrL8013002 for ietf-imapext-bks; Tue, 29 Apr 2003 15:38:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMcpi2012997 for ; Tue, 29 Apr 2003 15:38:52 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3TMcmbU030724 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 30 Apr 2003 00:38:48 +0200 To: "Michael Fair" Cc: , "Harrie Hazewinkel" Subject: Re: IMAP Capability and Virtual Domains References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> From: Simon Josefsson X-Payment: hashcash 1.2 0:030429:michael@daclubhouse.net:7f98a53897e5613a X-Hashcash: 0:030429:michael@daclubhouse.net:7f98a53897e5613a X-Payment: hashcash 1.2 0:030429:ietf-imapext@imc.org:a3b86b153f8cb5fd X-Hashcash: 0:030429:ietf-imapext@imc.org:a3b86b153f8cb5fd X-Payment: hashcash 1.2 0:030429:harrie@inet.it:bb0403a57b95afd6 X-Hashcash: 0:030429:harrie@inet.it:bb0403a57b95afd6 Date: Wed, 30 Apr 2003 00:38:48 +0200 In-Reply-To: <00fa01c30e21$430c6020$d1d07b43@cocacola> (Michael Fair's message of "Tue, 29 Apr 2003 00:30:46 -0700") Message-ID: User-Agent: Gnus/5.09002 (Oort Gnus v0.20) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-29.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Michael Fair" writes: > The problem with this solution is that there are several > things that happen before LOGIN or AUTH where knowing the > domain would be useful. Namely STARTTLS and CAPABILITY. Support draft-ietf-tls-extensions-06.txt in your STARTTLS implementation. This is not a IMAP specific problem, so a IMAP specific solution is not the best solution, engineering wise. A good authentication mechanism should have a means to allow clients to chose a "realm" they belong to. DIGEST-MD5 have this, as does the experimental KERBEROS_V5. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMXvi2012936 for ; Tue, 29 Apr 2003 15:33:57 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TMXvY8012935 for ietf-imapext-bks; Tue, 29 Apr 2003 15:33:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMXui2012930 for ; Tue, 29 Apr 2003 15:33:56 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from PLATO.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id SAA15394; Tue, 29 Apr 2003 18:27:45 -0400 (EDT) Date: Tue, 29 Apr 2003 18:32:24 -0400 From: Cyrus Daboo To: Michael Fair , ietf-imapext@imc.org cc: Harrie Hazewinkel Subject: Re: IMAP Capability and Virtual Domains Message-ID: <1048623330.1051641144@PLATO.cyrusoft.com> In-Reply-To: <009a01c30e9a$e5abcd60$d1d07b43@cocacola> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <1044733467.1051637254@PLATO.cyrusoft.com> <009a01c30e9a$e5abcd60$d1d07b43@cocacola> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Michael, --On Tuesday, April 29, 2003 3:01 PM -0700 Michael Fair wrote: | The one reservation I have about using a separate VHOST command | that returns the same response as CAPABILITY is that you've now | created to commands that do essentailly the exact same thing. Fine, but if we are going to extend capability lets do it in a way that will allow future parameters to be easily added, e.g. use the capability response syntax for the client command: a CAPABILITY VHOST=fqdn.example.com RLIST LANGUAGE=en_US,en_GB -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMFIi2012545 for ; Tue, 29 Apr 2003 15:15:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TMFIpH012544 for ietf-imapext-bks; Tue, 29 Apr 2003 15:15:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMFHi2012539 for ; Tue, 29 Apr 2003 15:15:17 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 51922883D93; Tue, 29 Apr 2003 15:15:19 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 12242812FF5; Tue, 29 Apr 2003 15:15:18 -0700 (PDT) Message-ID: <00d701c30e9c$c8980980$d1d07b43@cocacola> From: "Michael Fair" To: "Rob Siemborski" Cc: "Philip Guenther" , , "Harrie Hazewinkel" References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> Subject: Re: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 15:15:03 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Well, I've sort of been interested in a client-side capability string (how > does a server know that a client supports referrals if it doesn't execute > an RLIST first, for example?). In the case of referrals though, I suppose > an [L01 RLIST "" ""] is just as good as a client-side capability string, > since clients don't currently support it anyway. If a client side capability string would be something that would be generally useful, I would certainly be one of its supporters. It's one of those things that seems like it would be generally useful to me and would become more useful over time as people found ways to do things they previously couldn't, but that is more theory than fact at this point. If there are convincing enough arguments to sway the protocol designers to include, then I would propose the VHOST functionality be moved as part of that functionality. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TM4ai2012371 for ; Tue, 29 Apr 2003 15:04:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TM4a5D012370 for ietf-imapext-bks; Tue, 29 Apr 2003 15:04:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TM4Yi2012365 for ; Tue, 29 Apr 2003 15:04:34 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id E12745E107F8; Wed, 30 Apr 2003 01:04:35 +0300 (EEST) Subject: Re: IMAP Capability and Virtual Domains From: Timo Sirainen To: Michael Fair Cc: Philip Guenther , ietf-imapext@imc.org, Harrie Hazewinkel In-Reply-To: <007a01c30e91$1a391060$d1d07b43@cocacola> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051653875.26181.251.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 30 Apr 2003 01:04:35 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-04-29 at 23:51, Michael Fair wrote: > But you also mentioned PREAUTH the and intitial OK. Let's talk > about the initial OK for a second. This is acutally pretty cool > and something I hadn't thought about. If we leave VHOST as part > of the CAPABILITY announcement we can preinform a client about > whether or not the server supports domain specific configs. This sounds good to me. To save some roundtrips, it could include capability in it's reply as well: * OK [VHOST] IMAP server ready. 1 VHOST foo.bar.org 1 OK [CAPABILITY IMAP4rev1 ...] 2 STARTTLS 2 OK ..etc.. Non-vhost capable client simply works as before. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TM3ci2012341 for ; Tue, 29 Apr 2003 15:03:38 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TM3c9G012340 for ietf-imapext-bks; Tue, 29 Apr 2003 15:03:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TM3bi2012335 for ; Tue, 29 Apr 2003 15:03:37 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from UNIX46.andrew.cmu.edu (UNIX46.andrew.cmu.edu [128.2.13.176]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3TM3Zdg030378; Tue, 29 Apr 2003 18:03:35 -0400 Date: Tue, 29 Apr 2003 18:03:34 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: IMAP Extensions WG Subject: Re: IMAP Capability and Virtual Domains In-Reply-To: Message-ID: References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> 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, 29 Apr 2003, Mark Crispin wrote: > On Tue, 29 Apr 2003, Rob Siemborski wrote: > > In the case of referrals though, I suppose > > an [L01 RLIST "" ""] is just as good as a client-side capability string, > > since clients don't currently support it anyway. > > Clients don't currently support referrals? > > That's news to me; Pine has supported referrals for years. Sorry, I meant to say that the protocol doesn't currently support a client-side capability string, so for the case of mailbox referrals, a client-side capability string is just as good as sending RLIST "" "". -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TM1mi2012286 for ; Tue, 29 Apr 2003 15:01:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TM1lRq012285 for ietf-imapext-bks; Tue, 29 Apr 2003 15:01:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TM1ki2012280 for ; Tue, 29 Apr 2003 15:01:46 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id B9DF9883D93; Tue, 29 Apr 2003 15:01:48 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 49250812FF5; Tue, 29 Apr 2003 15:01:47 -0700 (PDT) Message-ID: <009a01c30e9a$e5abcd60$d1d07b43@cocacola> From: "Michael Fair" To: "Cyrus Daboo" , Cc: "Harrie Hazewinkel" References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <1044733467.1051637254@PLATO.cyrusoft.com> Subject: Re: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 15:01:32 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Here is what I propose as an alternative, assuming VHOST is going to be > implemented: > > 1) A VHOST aware server returns VHOST as the only capability in the > response code for the greeting string. This avoids the server having to > advertise any capabilites before its got the VHOST. But this also kills the servers ability to be backwards compatible and offer a "default domain" which would be the equivalent of whatever its pre-VHOST mail store mailboxes were. You can still put VHOST in the response code of the greeting string and it will still be useful, but I would augment this to say that it would be included as one of the capabilities listed (but still possibly the only one for a VHOST only environment). > 2) A VHOST aware client that sees VHOST in the greeting capability MUST > immediately issue a VHOST command with the server fqdn as a parameter. > > 3) The server responds to the command with a full capability response > listing the capabilites now available for that virtual domain. This simple creates an alternate CAPABILITY command. How about we keep (1) as augmented above, but for 2 use: 2) A VHOST aware client that sees CHOST in the greeting capability MUST immediately issue a CAPABILITY command with the server fqdn as a parameter. A client MUST NOT issue an argument to CAPABILITY if it has not previously seen a VHOST capability. The one reservation I have about using a separate VHOST command that returns the same response as CAPABILITY is that you've now created to commands that do essentailly the exact same thing. I don't mind requiring servers to announce VHOST as part of the greeting response at all. I like the feature and if that is what it takes to satisfy a "client always has foreknowledge" semantic. Then I can live with that. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLqoi2012017 for ; Tue, 29 Apr 2003 14:52:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TLqo36012016 for ietf-imapext-bks; Tue, 29 Apr 2003 14:52:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLqni2012011 for ; Tue, 29 Apr 2003 14:52:49 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3TLqiRG008591; Tue, 29 Apr 2003 14:52:49 -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+UW03.04/8.12.1+UW02.12) with ESMTP id h3TLqhQ0031115 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Apr 2003 14:52:44 -0700 Date: Tue, 29 Apr 2003 14:52:45 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: IMAP Extensions WG Subject: Re: IMAP Capability and Virtual Domains In-Reply-To: Message-ID: References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> 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, 29 Apr 2003, Rob Siemborski wrote: > In the case of referrals though, I suppose > an [L01 RLIST "" ""] is just as good as a client-side capability string, > since clients don't currently support it anyway. Clients don't currently support referrals? That's news to me; Pine has supported referrals for years. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLjAi2011849 for ; Tue, 29 Apr 2003 14:45:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TLjA5o011848 for ietf-imapext-bks; Tue, 29 Apr 2003 14:45:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLj8i2011841 for ; Tue, 29 Apr 2003 14:45:08 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3TLj2SL013547; Tue, 29 Apr 2003 14:45:07 -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+UW03.04/8.12.1+UW02.12) with ESMTP id h3TLj1Q0030340 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Apr 2003 14:45:01 -0700 Date: Tue, 29 Apr 2003 14:45:03 -0700 (Pacific Daylight Time) From: Mark Crispin To: Cyrus Daboo cc: IMAP Extensions WG Subject: Re: IMAP Capability and Virtual Domains In-Reply-To: <1044733467.1051637254@PLATO.cyrusoft.com> Message-ID: References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <1044733467.1051637254@PLATO.cyrusoft.com> 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, 29 Apr 2003, Cyrus Daboo wrote: > Other issues not withstanding, I do not like the idea of an optional > argument to capability, or using a VHOST command before issuing capability. Agreed, for the reasons you state. > 1) A VHOST aware server returns VHOST as the only capability in the > response code for the greeting string. This avoids the server having to > advertise any capabilites before its got the VHOST. No good. A VHOST-unaware client will issue a plaintext LOGIN command unless the client itself was configured not to do such a thing. That gets into including LOGINDISABLED, which in turn results in other implications. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLWvi2011576 for ; Tue, 29 Apr 2003 14:32:57 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TLWv9P011575 for ietf-imapext-bks; Tue, 29 Apr 2003 14:32:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLWti2011570 for ; Tue, 29 Apr 2003 14:32:55 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from BBOARD.andrew.cmu.edu (BBOARD.andrew.cmu.edu [128.2.11.39]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3TLWrfg003330; Tue, 29 Apr 2003 17:32:54 -0400 Date: Tue, 29 Apr 2003 17:32:53 -0400 (EDT) From: Rob Siemborski To: Michael Fair cc: Philip Guenther , ietf-imapext@imc.org, Harrie Hazewinkel Subject: Re: IMAP Capability and Virtual Domains In-Reply-To: <007a01c30e91$1a391060$d1d07b43@cocacola> Message-ID: References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> 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, 29 Apr 2003, Michael Fair wrote: > I'm still assuming that people on this list are still > somewhat dubious about whether or not virtual hosting > multiple domains on a single IP address is even useful. I agree that virtual hosting on a single IP is useful. I'm personally unconvinced of the necessity of a VHOST command (or other additional argument to CAPABILITY) to do this, its almost entirely possible to do this using realms on user ids. The only problem using realms with user IDs doesn't solve is the fact that you don't know which certificate to present during a STARTTLS. I suppose this can be solved with an argument to STARTTLS. You'd need to advertise a new STARTTLS_WITH_DOMAIN capability too. [As an aside, when I worked for a web hosting firm back in '97-99, I know we were using an IP-per-domain for HTTPS. Is this still the case? (I don't immediately know of any new solutions but I could be wrong).] Of course, you now have an issue where some of your customers may not be able to advertise STARTTLS (they don't have certs, and don't want junk certs). Maybe its good enough just to respond NO when these clients try to do STARTTLS "badcustomer.com" I agree with Cyrus's comments that placing a requirement that the client assume a server supports something before issuing a CAPABILITY command is bad. > I'll tell you what would be even more useful is just a > general command where the client can pass a set of > generic key value pairs to inform the server of generic > session parameters where clients and servers can be > modified to look for and send arbitrary info. Well, I've sort of been interested in a client-side capability string (how does a server know that a client supports referrals if it doesn't execute an RLIST first, for example?). In the case of referrals though, I suppose an [L01 RLIST "" ""] is just as good as a client-side capability string, since clients don't currently support it anyway. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLQei2011367 for ; Tue, 29 Apr 2003 14:26:40 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TLQefo011366 for ietf-imapext-bks; Tue, 29 Apr 2003 14:26:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLQdi2011361 for ; Tue, 29 Apr 2003 14:26:39 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from PLATO.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA14922; Tue, 29 Apr 2003 17:22:55 -0400 (EDT) Date: Tue, 29 Apr 2003 17:27:34 -0400 From: Cyrus Daboo To: Michael Fair , ietf-imapext@imc.org cc: Harrie Hazewinkel Subject: Re: IMAP Capability and Virtual Domains Message-ID: <1044733467.1051637254@PLATO.cyrusoft.com> In-Reply-To: <00fa01c30e21$430c6020$d1d07b43@cocacola> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Michael, --On Tuesday, April 29, 2003 12:30 AM -0700 Michael Fair wrote: | I had an offline discussion with Mark Crispin and proposed | adding the domain name as an optional parameter to CAPABILITY. | | My assumption was that the very first thing an IMAP client | is going to do (even before STARTTLS) is CAPABILITY to find | out if the server can even do STARTTLS and to figure out | what methods of authentication the server makes available. Other issues not withstanding, I do not like the idea of an optional argument to capability, or using a VHOST command before issuing capability. If you do that, how is a client to know that that is a valid thing to do with that server? The user would have to provide some configuration switch to enable it and that requires one extra step for the user that should be avoided. Here is what I propose as an alternative, assuming VHOST is going to be implemented: 1) A VHOST aware server returns VHOST as the only capability in the response code for the greeting string. This avoids the server having to advertise any capabilites before its got the VHOST. 2) A VHOST aware client that sees VHOST in the greeting capability MUST immediately issue a VHOST command with the server fqdn as a parameter. 3) The server responds to the command with a full capability response listing the capabilites now available for that virtual domain. This goes like: s: * OK [CAPABILITY imap4rev1 VHOST] c: a VHOST fqdn.example.com s: * CAPABILITY imap4rev1 starttls logindisabled auth=gssapi s: a OK I believe this approach minimises round trips and doesn't require the client to guess as to whether an extended capability command is present or not. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TKphi2009904 for ; Tue, 29 Apr 2003 13:51:43 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TKphXG009903 for ietf-imapext-bks; Tue, 29 Apr 2003 13:51:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TKpei2009897 for ; Tue, 29 Apr 2003 13:51:41 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id B92D7883D93; Tue, 29 Apr 2003 13:51:42 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 539BA8831EB; Tue, 29 Apr 2003 13:51:38 -0700 (PDT) Message-ID: <007a01c30e91$1a391060$d1d07b43@cocacola> From: "Michael Fair" To: "Philip Guenther" Cc: , "Harrie Hazewinkel" References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> Subject: Re: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 13:51:22 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-9.2 required=5.0 tests=OFFERS_ETC,QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > There are three 'issues' that the VHOST capability claims to address: > 1) the ad-hoc interpretation of authentication IDs as specifying user > and domain > 2) the ability to have domain-specific capability lists > 3) the choice of STARTTLS certificate by the server > > In my opinion, the first of these is a non-issue in practice. Indeed, > the VHOST extension leaves the client author in a sticky situation: if > it accepts the authentication ID as a single value ready for presenting > to LOGIN (or AUTHENTICATE PLAIN/CRAM-MD5/etc), then it must decide and > document how it splits that into a domain for VHOST and a username for > LOGIN. If it accepts the authentication ID as separate domain and user > values, then it must guess how to join them for non-VHOST-enabled > servers, or have another configuration parameter for _that_. The VHOST > extension would also need to specify how it affects and/or operates with > SASL mechanisms that convey the user's domain separate from their > username. The first of these is not a non-issue, but I grant is more of a minor annoyance than an issue. However, it forces administrators to dictate certain parts of customer usernames, where our preference would be to allow the customers to have complete control over that namespace. It save us and them time (and money). As for the client detecting the domain name, the client wouldn't split anything. Whatever was specified in the "IMAP server" field would be presented wholesale without modification as the FQDN for the VHOST or CAPABILITY argument to specify the targetted domain. It's a server and admin issue to make sure that whatever the client has as its server address is appropriately mapped internally. Think HTTP 1.1 and Apache Name Based Virtual Hosts if you have any experience with that. The servername is presented unmodified as part of the header to the request. > The second issue appears minor to me. Is it more than a matter of > differing domains being allowed different SASL mechanisms? Is that a > practical problem? This question is equivalent to "Why should any server ever offer a different CAPABILITY line?" Think ISP, think a 1,000 unique domains all on one IP, think 600 or more different companies all being hosted on the same machine. Each of those 1,000 domains deserves to be treated as if it had its own dedicated server. That currently requires 1,000 IP addresses. The goal here is simply to give the IMAP server the name of the server the client was trying to reach as early as possible so it can look up a config for that server and present it. Each domain should be as independantly configurable as a standalone server would be (with the exception of anything that happens on the wire before the client has a chance to speak). However, to address your direct question about the second issue, most of it surrounds SASL mechanisms, but tuning CAPABILITY based on the preferred clients in each domain is also an issue. Oftentimes the only way to get the desired behavior is to add or remove things from the CAPABILITY line. Other times, you don't want to offer certain CAPABILITY options unless you absolutely have to. For instance Outlook[ Express] only supports LOGIN. I wouldn't want to enable that except for domains that required it. > I agree that the third issue is a real problem. IMHO, STARTTLS would > have been better defined to take an "fqdn" argument that the server > could use to decide which certificate to use. An extension that did > only that---add an optional domain argument to STARTTLS---would appear > to provide most of the benefits of VHOST. I agree that STARTTLS would be better if the only issue were choosing a certificate. Perhaps the proposal should be expanded to add an argument to both CAPABILITY and STARTTLS. I chose CAPABILITY because the domain is is needed for all three issues listed, not just (3). I personally figure if you're going to bother fixing, you should look into fixing all of it not just propping up the most important piece. The cost of adding an argument is the same whether it is to STARTTLS or to CAPABILITY or to adding a new command. Things break, or you get more round trips. My goal was to get the server the info as early as possible. Not all clients issue a STARTTLS, nor should all be required to issue a STARTTLS just to get per domain information. If all clients issued a STARTTLS then I agree adding a domain argument to STARTTLS would solve the problem. However, not all clients do that. But, all clients do issue a CAPABILITY. Adding a domain argument to that would solve the problem neatly. I will address the "two round trips for failure" below. > It seems to me that the CAPABILITY command is ill-suited for such > treatment. If the client already has the server's list of capabilities > and therefore knows that the server supports the extension, then > overloading the CAPABILITY command doesn't save you anything. Right, adding a domain argument to CAPABILITY is intended to completely replace VHOST. A client would issue the extended version and fall back in the event of BAD. If this was just to figure out if the server supported the VHOST command then addidng a domain argument to CAPABILITY would be senseless. My goal with adding the domain argument to CAPABILITY is to reduce the number of round trips a client has to make. > If the > client doesn't already have the server's list of capabilities, then the > client will have to either try the extended version and fallback on BAD, > or send an unextended request with a followup if the capability is > advertised, either way requiring two roundtrips against some set of > servers. Leaving the VHOST command separate from CAPABILITY while > strengthing the recommendation that the server include a CAPABILITY > response code in the initial PREAUTH or OK response and that clients > recognize such would appear to be a simpler and cleaner approach. You seem to think that making clients issue a separate VHOST coammdn "two round trips for some set of servers". You've just inverted the set of servers that's all. I think it's fair to say that clients and servers of any proposal accepted would gravitate towards supporting it as long as it cost them very little to add (which I have explicity designed the proposal for). First, if we added a domain argument to CAPABILITY, then as my proposal suggested, servers could be modified to simply swallow it and go about their business. So supporting the argument is really trivial. It does require a code change, and it does require a release of a new server version which will take some time. So between now and then we have all the existing code that responds with "BAD" which is, and will remain, a correct response for servers that don't support the VHOST capability. In general, the clients that support this feature aren't going to be used against the servers that don't unless most future versions of clients decide they should support this (which then makes a compelling case for servers to at least swallow the argument), however there will be plenty of exceptions and for a time these clients will get a BAD response from those servers. Those exceptions will need to make two round trips, but over time those exceptions will become fewer. If you're interested in optimizing bandwidth, it quickly becomes very clear that, if accepted, the general trend of servers and clients will be to support the added domain argument to CAPABILITY (or some other proposal that provides equivalent functionality). It costs servers nothing but a little "ignore the argument" code. It costs clients some "tack the server name on" code, and if the response is "BAD" or "NO" then give up. Granted those are the bare minimums for compliance, but they are fairly trivial. But you also mentioned PREAUTH the and intitial OK. Let's talk about the initial OK for a second. This is acutally pretty cool and something I hadn't thought about. If we leave VHOST as part of the CAPABILITY announcement we can preinform a client about whether or not the server supports domain specific configs. Very cool! I'll be suggesting that in to my proposal. Originally I had intended on not doing anything with the CAPABILITY line because I wasn't thinking that a server could just announce its CAPABILITY without the client requesting it. But now we need to decide between a separate VHOST command or an argument to CAPABILITY? Here's a test case: Client shows up at the server, the server dumps a CAPABILITY line down its throat the client sees a VHOST option, or the Client shows up at the server, the server gives some kind of hello and the Client is unaware of whether or not the server supports the VHOST capability. It then ..... A) [issues a CAPABILITY and looks for VHOST (if unknown)] issues a VHOST command then issues another CAPABILITY or B) isssues a CAPABILITY with a domain argument [issues a CAPABILITY without a domain argument (if BAD)] The only other proposal that would obviate the need for a VHOST command to require a separate round trip would be if VHOST returned the same response as CAPABILITY. But now you've created two commands that do the exact same thing and for what? To protect existing servers from having to trip over a malformed CAPABILITY line that the servers are already prepared to ignore and that over time will learn to accept (even if they just ignore the argument which they are perfectly allowed to do). > ... > >As an added bonus, this also lays the groundwork for > >some future planning on replicating and scaling IMAP > >mail stores to span multiple mail stores to provide > >geograhic redundancy. Without this feature the "IP burn > >rate" jumps to 1+N addresses per domain where N is the > >number of geographically redundant mail stores. > > I don't understand how geographically redundant mail stores are helped > out any more than any set of N mail stores that offer STARTTLS. If the > problem is the requirement for separate IPs for STARTTLS, then giving > STARTTLS an optional argument would "lower the burn rate" just as much > as VHOST or "CAPABILITY domain", no? Again you are somehow assuming that every conversation with every IMAP server issues a STARTTLS. An IMAP server doesn't even have to offer STARTTLS, most do because it's a good idea, but then you've got the same optional aspect on the client side. The real point is being able to connect to an IMAP server and identify what domain context you want the conversation to occur in. If STARTTLS were as ubiquitous as CAPABILITY and EVERY SESSION issued one, then I'd agree. But it's not. I also really don't understand why you would favor STARTTLS over CAPABILITY? It makes no sense to me. STARTTLS is only issued in the context of creating a secure connection, CAPABILITY is always offered. STARTTLS is discovered post CAPABILITY, so why not do it at the first opportunity? Further, whether or not STARTTLS is even offered may depend completely on what domain the client was trying to reach. (For instance if the customer hasn't provided a security certificate to be used, then why should the server offer that domain STARTTLS functionality?) The point is to let the server switch configurations based on the targetted domain. STARTTLS doesn't give us that because it isn't gauranteed to be issued. CAPABILITY and VHOST are both gauranteed to be issued if the client supports it. An argument to STARTTLS, or an argument to CAPABILITY sounds like six of one half a dozen of the other, it's still an extra argument that gets added to something that currently doesn't take one. You've dismissed the first two benefits of the three as not needed and then based on that came up with "oh only STARTTLS is needed" where for no extra cost (since you gotta add something somewhere), if we add it to CAPABILITY we get all three. Those of us who have actually had to deal with the issue, which by your dismissal of points 1 and 2 makes it obvious you haven't seriously had to deal with it, believe 1 and 2 are important and have suggested a solution which comes out to costing the same as an argument to STARTTLS, and provides the same benefit as an argument to STARTTLS, but also provides extra benefits that an argument to STARTTLS doesn't offer us (otherwise we probably would have proposed it that way to begin with). While I will certainly agree that STARTTLS and SASL mechanisms are the primary purposes, there are other secondary gripes that get handled by doing it via a VHOST or argument to CAPABILITY. I personally think that even VHOST is a waste. It gives us nothing that an argument to CAPABILITY doesn't give us, and it mandates extra round trips. An argument to CAPABILITY only causes _one_ extra round trip during the transitional period where new clients try and access servers that haven't been updated to ignore the argument yet. If you haven't had to deal with hosting lots of domains on a limit number of IPs then please don't assume you know what the issues are and what's important and what's not. I've tried to make the proposal as simple as possible _but no simpler_ to get the information we need. I'm more than willing to explain and educate, and there is a very large list of other things that you can start doing once you have this type of functionality that I'm refraining from mentioning because I believe that giving a huge laundry list of minor nice-to-haves distracts from the core issues. For instance one "nice-to-have" is to aggregate multiple domains to act as one single domain. Why? you ask.. It doesn't matter. If you've been there you'd get it, and you haven't then you don't really need to know. All you need to know is that being able to aggregate multiple domain names together to act as a single group is useful. Not as useful as being able to make every domain its own unique entity, and certainly not something all servers are going to support, but for those people who need the functionality, they're grateful that the protocol built in a space for a few extra bytes of information where the client can announce the server it was trying to reach. I'm still assuming that people on this list are still somewhat dubious about whether or not virtual hosting multiple domains on a single IP address is even useful. If that's still the case, then I'll be more than happy to take arguments and suggestions to find some other way to solve the problem until we can all agree. Believe me when I say I'll be more than happy to listen because if there is a way around it then hopefully it can be applied to lots of protocols that lack this support, not just IMAP and the host providers of the world won't have to wait for new versions of clients and servers before they can start rolling this out. However, I'll warn you, I've been working on the problem for six years, I've worked with lots of really smart networking engineers and system administrators who have also been working on it for several years (some longer than I have), and so far, no one in the entire hosting industry has been unable to find a generally useful solution that isn't based on the protocol providing a special place where the intended server name is provided. I'll tell you what would be even more useful is just a general command where the client can pass a set of generic key value pairs to inform the server of generic session parameters where clients and servers can be modified to look for and send arbitrary info. Kind of like the "X-" headers in SMTP. That way the server name could be stuffed into one of those, and it would not require a protocol change... A simple formal registry could maintain the most useful and widely accepted options that clients and server normally adopt. However, it's not clear to me the overall usefulness of the feature, whether it should be unidriectional or bidirectional, and how complicated the command should be. So for now, I'd be more than happy with just a server name submitted by the client to the server as early as possible during the conversation. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TJ8ii2006804 for ; Tue, 29 Apr 2003 12:08:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TJ8iGp006803 for ietf-imapext-bks; Tue, 29 Apr 2003 12:08:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TJ8ai2006796 for ; Tue, 29 Apr 2003 12:08:43 -0700 (PDT) (envelope-from ned+imapext@innosoft.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KVAIFWGJSW007FVT@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Tue, 29 Apr 2003 12:08:29 -0700 (PDT) Date: Tue, 29 Apr 2003 12:06:17 -0700 (PDT) From: ned+imapext@INNOSOFT.COM Subject: Review requested: draft-siemborski-mupdate-03.txt to be published as an experimental RFC To: ietf-imapext@imc.org Cc: ned.freed@mrochek.com, hardie@qualcomm.com Message-id: <01KVAS4J29VM007FVT@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've received a request from the author to publish The MUPDATE Distributed Mailbox Database Protocol draft-siemborski-mupdate-03.txt as an experimental RFC. It is customary for area directors to ask for such documents to be reviewed by one or more working groups working in the same or related area. Accordingly, I'm asking folks involved in IMAPEXT to review this document and comment on its suitability for publication as an experimental protocol. TIA. Ned P.S. I have already sent the author some feedback on missing boilerplate and other formalities. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3THANi2001758 for ; Tue, 29 Apr 2003 10:10:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3THAN3u001757 for ietf-imapext-bks; Tue, 29 Apr 2003 10:10:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3THAMi2001752 for ; Tue, 29 Apr 2003 10:10:22 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA12428; Tue, 29 Apr 2003 13:05:55 -0400 (EDT) Date: Tue, 29 Apr 2003 13:09:24 -0400 From: Cyrus Daboo To: Timo Sirainen , Philip Guenther cc: Michael Fair , ietf-imapext@imc.org, Harrie Hazewinkel Subject: Re: IMAP Capability and Virtual Domains Message-ID: <2147483647.1051621764@[63.163.82.24]> In-Reply-To: <1051634342.26178.240.camel@hurina> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <1051634342.26178.240.camel@hurina> X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Timo, --On Tuesday, April 29, 2003 7:39 PM +0300 Timo Sirainen wrote: | Related to 2, I've thought about giving different capability lists per | user. Couldn't both of these be solved by letting server reply with | untagged CAPABILITY reply (or resp-text-code) after login? All clients | might not update their lists, but that's better than having | extra/missing capabilities listed. rfc3501 already states that servers may send a capability response code in the tagged OK to the AUTHENTICATE command. Servers can also send the capability response code in the greeting response too. If both of those are implemented, then a client would only need to use the CAPABILITY command after STARTTLS. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TGdGi2000691 for ; Tue, 29 Apr 2003 09:39:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TGdGoS000690 for ietf-imapext-bks; Tue, 29 Apr 2003 09:39:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TGd9i2000683 for ; Tue, 29 Apr 2003 09:39:10 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 2D1245E107F8; Tue, 29 Apr 2003 19:39:03 +0300 (EEST) Subject: Re: IMAP Capability and Virtual Domains From: Timo Sirainen To: Philip Guenther Cc: Michael Fair , ietf-imapext@imc.org, Harrie Hazewinkel In-Reply-To: <200304291140.h3TBeCe23040@katroo.Sendmail.COM> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051634342.26178.240.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 29 Apr 2003 19:39:03 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-04-29 at 14:36, Philip Guenther wrote: > There are three 'issues' that the VHOST capability claims to address: > 1) the ad-hoc interpretation of authentication IDs as specifying user > and domain > 2) the ability to have domain-specific capability lists > 3) the choice of STARTTLS certificate by the server Related to 2, I've thought about giving different capability lists per user. Couldn't both of these be solved by letting server reply with untagged CAPABILITY reply (or resp-text-code) after login? All clients might not update their lists, but that's better than having extra/missing capabilities listed. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBwFi2084908 for ; Tue, 29 Apr 2003 04:58:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TBwFbD084907 for ietf-imapext-bks; Tue, 29 Apr 2003 04:58:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBwEi2084900 for ; Tue, 29 Apr 2003 04:58:14 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:53665 "ehlo melkebalanse.gulbrandsen.priv.no" ident: "NO-IDENT-SERVICE[2]") by bra.gulbrandsen.priv.no with ESMTP id ; Tue, 29 Apr 2003 13:58:02 +0200 Message-Id: From: Arnt Gulbrandsen To: Philip Guenther Subject: Re: IMAP Capability and Virtual Domains Cc: Harrie Hazewinkel , IMAP Extensions WG References: <7FE40FBE-7A27-11D7-998F-0003934A5A7E@inet.it> <200304291144.h3TBiCe23346@katroo.Sendmail.COM> In-Reply-To: <200304291144.h3TBiCe23346@katroo.Sendmail.COM> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 29 Apr 2003 13:58:50 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther writes: > Arnt Gulbrandsen writes: >> As long as VHOST does not block, it can be added almost anywere. I'd >> add it in step E: "send VHOST and STARTTLS". > > Imap servers are allowed to reorder pipelined commands, so that won't work. I'd quibble... but you're effectively right. Pity. > (The tagged OK of the STARTTLS command is sent _before_ TLS > negotiation and is therefore not protected.) (The server can send an unsolicited untagged OK afterwards. ISTR having seen one do. UW, I think... but it's at least a year ago.) OK. VHOST must add another round-trip. Then I dislike it even more. How about using something like 'STARTTLS VHOST=fqdn'? --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBgYi2083770 for ; Tue, 29 Apr 2003 04:42:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TBgYFr083769 for ietf-imapext-bks; Tue, 29 Apr 2003 04:42:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBgXi2083764 for ; Tue, 29 Apr 2003 04:42:33 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3TBgUFd020554; Tue, 29 Apr 2003 04:42:30 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7/8.11.6) with ESMTP id h3TBiCe23346; Tue, 29 Apr 2003 04:44:12 -0700 (PDT) Message-Id: <200304291144.h3TBiCe23346@katroo.Sendmail.COM> To: Arnt Gulbrandsen Cc: Harrie Hazewinkel , IMAP Extensions WG From: Philip Guenther Subject: Re: IMAP Capability and Virtual Domains In-reply-to: References: <7FE40FBE-7A27-11D7-998F-0003934A5A7E@inet.it> Date: Tue, 29 Apr 2003 04:40:49 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen writes: > >Harrie Hazewinkel writes: >> In such a case I believe we could 'convert' CAPABILITY by ading >> 'VHOST' semantics when the server is before the STARTTLS and/or >> AUTH/LOGIN. > >As long as VHOST does not block, it can be added almost anywere. I'd add >it in step E: "send VHOST and STARTTLS". Imap servers are allowed to reorder pipelined commands, so that won't work. >> What I neither understand why was the response of a CAPABILITY not >> added to the response of STARTTLS for example. Allowing that would >> have reduced the extra CAPABILITY commands and the associated >> waiting. > >It is. RFC 3501 resp-code-text includes capability-data, and section >7.2.1 describes how to do it. Recent versions of UW imapd use that. rfc3501, section 6.2.1: Once [TLS] has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in- the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS. (The tagged OK of the STARTTLS command is sent _before_ TLS negotiation and is therefore not protected.) Philip Guenther guenther@sendmail.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBcci2083137 for ; Tue, 29 Apr 2003 04:38:38 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TBccct083136 for ietf-imapext-bks; Tue, 29 Apr 2003 04:38:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBcXi2083090 for ; Tue, 29 Apr 2003 04:38:37 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3TBcUFd020175; Tue, 29 Apr 2003 04:38:31 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7/8.11.6) with ESMTP id h3TBeCe23040; Tue, 29 Apr 2003 04:40:12 -0700 (PDT) Message-Id: <200304291140.h3TBeCe23040@katroo.Sendmail.COM> To: "Michael Fair" Cc: ietf-imapext@imc.org, "Harrie Hazewinkel" Subject: Re: IMAP Capability and Virtual Domains In-reply-to: <00fa01c30e21$430c6020$d1d07b43@cocacola> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> Date: Tue, 29 Apr 2003 04:36:50 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Michael Fair" writes: ... >Current single IP implementations pack the domain info in >the usernames and then do some magic after authentication to >create the domain specific view. How they pack the domain >info varies from site to site, but the username is the >only client submitted information that can reliably be >used to identify the targetted domain. > >The problem with this solution is that there are several >things that happen before LOGIN or AUTH where knowing the >domain would be useful. Namely STARTTLS and CAPABILITY. There are three 'issues' that the VHOST capability claims to address: 1) the ad-hoc interpretation of authentication IDs as specifying user and domain 2) the ability to have domain-specific capability lists 3) the choice of STARTTLS certificate by the server In my opinion, the first of these is a non-issue in practice. Indeed, the VHOST extension leaves the client author in a sticky situation: if it accepts the authentication ID as a single value ready for presenting to LOGIN (or AUTHENTICATE PLAIN/CRAM-MD5/etc), then it must decide and document how it splits that into a domain for VHOST and a username for LOGIN. If it accepts the authentication ID as separate domain and user values, then it must guess how to join them for non-VHOST-enabled servers, or have another configuration parameter for _that_. The VHOST extension would also need to specify how it affects and/or operates with SASL mechanisms that convey the user's domain separate from their username. The second issue appears minor to me. Is it more than a matter of differing domains being allowed different SASL mechanisms? Is that a practical problem? I agree that the third issue is a real problem. IMHO, STARTTLS would have been better defined to take an "fqdn" argument that the server could use to decide which certificate to use. An extension that did only that---add an optional domain argument to STARTTLS---would appear to provide most of the benefits of VHOST. >The current IMAP extension draft adds a "VHOST" command >to specify which virtual host the client was trying to reach. >Overall I think it's a good proposal, but I believe the >same result can be accomplished without the need for adding >a new command. > >I had an offline discussion with Mark Crispin and proposed >adding the domain name as an optional parameter to CAPABILITY. It seems to me that the CAPABILITY command is ill-suited for such treatment. If the client already has the server's list of capabilities and therefore knows that the server supports the extension, then overloading the CAPABILITY command doesn't save you anything. If the client doesn't already have the server's list of capabilities, then the client will have to either try the extended version and fallback on BAD, or send an unextended request with a followup if the capability is advertised, either way requiring two roundtrips against some set of servers. Leaving the VHOST command separate from CAPABILITY while strengthing the recommendation that the server include a CAPABILITY response code in the initial PREAUTH or OK response and that clients recognize such would appear to be a simpler and cleaner approach. ... >As an added bonus, this also lays the groundwork for >some future planning on replicating and scaling IMAP >mail stores to span multiple mail stores to provide >geograhic redundancy. Without this feature the "IP burn >rate" jumps to 1+N addresses per domain where N is the >number of geographically redundant mail stores. I don't understand how geographically redundant mail stores are helped out any more than any set of N mail stores that offer STARTTLS. If the problem is the requirement for separate IPs for STARTTLS, then giving STARTTLS an optional argument would "lower the burn rate" just as much as VHOST or "CAPABILITY domain", no? Philip Guenther guenther@sendmail.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TA1oi2076330 for ; Tue, 29 Apr 2003 03:01:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TA1okQ076329 for ietf-imapext-bks; Tue, 29 Apr 2003 03:01:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TA1ni2076323 for ; Tue, 29 Apr 2003 03:01:50 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:5281 "ehlo melkebalanse.gulbrandsen.priv.no" ident: "NO-IDENT-SERVICE[2]") by bra.gulbrandsen.priv.no with ESMTP id ; Tue, 29 Apr 2003 12:01:33 +0200 Message-Id: From: Arnt Gulbrandsen To: Harrie Hazewinkel Subject: Re: IMAP Capability and Virtual Domains Cc: IMAP Extensions WG References: <7FE40FBE-7A27-11D7-998F-0003934A5A7E@inet.it> In-Reply-To: <7FE40FBE-7A27-11D7-998F-0003934A5A7E@inet.it> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 29 Apr 2003 12:02:21 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Harrie Hazewinkel writes: > In such a case I believe we could 'convert' CAPABILITY by ading > 'VHOST' semantics when the server is before the STARTTLS and/or > AUTH/LOGIN. As long as VHOST does not block, it can be added almost anywere. I'd add it in step E: "send VHOST and STARTTLS". > What I neither understand why was the response of a CAPABILITY not > added to the response of STARTTLS for example. Allowing that would > have reduced the extra CAPABILITY commands and the associated > waiting. It is. RFC 3501 resp-code-text includes capability-data, and section 7.2.1 describes how to do it. Recent versions of UW imapd use that. > Adding a fifth wait is a trade-off compared to the extra functionality on > can get. Explain. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T9gxi2075536 for ; Tue, 29 Apr 2003 02:42:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3T9gxb2075534 for ietf-imapext-bks; Tue, 29 Apr 2003 02:42:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mid-1.inet.it (mid-1.inet.it [213.92.5.18]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T9gvi2075523 for ; Tue, 29 Apr 2003 02:42:58 -0700 (PDT) (envelope-from harrie@inet.it) Received: from [::ffff:213.92.1.193] by mid-1.inet.it via I-SMTP-4.4.2-442 id ::ffff:213.92.1.193+FrLnnBgUaM71; Tue, 29 Apr 2003 11:42:56 +0200 Date: Tue, 29 Apr 2003 11:46:49 +0200 Subject: Re: IMAP Capability and Virtual Domains Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Harrie Hazewinkel , IMAP Extensions WG To: Arnt Gulbrandsen From: Harrie Hazewinkel In-Reply-To: Message-Id: <7FE40FBE-7A27-11D7-998F-0003934A5A7E@inet.it> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tuesday, April 29, 2003, at 11:26 AM, Arnt Gulbrandsen wrote: > Harrie Hazewinkel writes: >> Correct me if I am wrong, but "do clients not have to wait for >> STARTTLS to finish also before a login procedure can be given??" > > A client must wait for STARTTLS, yes. Regrettable, but given the > nature of the command it's unavoidable. > > Today, with most servers, I have to > > a) connect > b) wait until I see the IMAP banner > c) send CAPABILITY > d) wait for the answer > e) send STARTTLS (or switch to port 993 and repeat from step a) > f) wait for the answer > g) do TLS negotiation > h) send CAPABILITY > i) wait for the answer > j) send AUTH or LOGIN > k) wait for the answer > > Steps d, f, i and k add up to more than enough waiting. Adding a fifth > wait is not a good idea. In such a case I believe we could 'convert' CAPABILITY by ading 'VHOST' semantics when the server is before the STARTTLS and/or AUTH/LOGIN. What I neither understand why was the response of a CAPABILITY not added to the response of STARTTLS for example. Allowing that would have reduced the extra CAPABILITY commands and the associated waiting. Adding a fifth wait is a trade-off compared to the extra functionality on can get. In this case it is easier server administration that does not directly benefit a user. :-(( Harrie Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T9Pni2075134 for ; Tue, 29 Apr 2003 02:25:49 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3T9PnbD075133 for ietf-imapext-bks; Tue, 29 Apr 2003 02:25:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T9Pmi2075128 for ; Tue, 29 Apr 2003 02:25:49 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:5025 "ehlo melkebalanse.gulbrandsen.priv.no" ident: "NO-IDENT-SERVICE[2]") by bra.gulbrandsen.priv.no with ESMTP id ; Tue, 29 Apr 2003 11:25:35 +0200 Message-Id: From: Arnt Gulbrandsen To: Harrie Hazewinkel Subject: Re: IMAP Capability and Virtual Domains Cc: IMAP Extensions WG References: <60C91510-7A22-11D7-998F-0003934A5A7E@inet.it> In-Reply-To: <60C91510-7A22-11D7-998F-0003934A5A7E@inet.it> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 29 Apr 2003 11:26:24 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Harrie Hazewinkel writes: > Correct me if I am wrong, but "do clients not have to wait for > STARTTLS to finish also before a login procedure can be given??" A client must wait for STARTTLS, yes. Regrettable, but given the nature of the command it's unavoidable. Today, with most servers, I have to a) connect b) wait until I see the IMAP banner c) send CAPABILITY d) wait for the answer e) send STARTTLS (or switch to port 993 and repeat from step a) f) wait for the answer g) do TLS negotiation h) send CAPABILITY i) wait for the answer j) send AUTH or LOGIN k) wait for the answer Steps d, f, i and k add up to more than enough waiting. Adding a fifth wait is not a good idea. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T96Ri2074277 for ; Tue, 29 Apr 2003 02:06:27 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3T96R24074276 for ietf-imapext-bks; Tue, 29 Apr 2003 02:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from hal-5.inet.it (hal-5.inet.it [213.92.5.24]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T96Pi2074268 for ; Tue, 29 Apr 2003 02:06:26 -0700 (PDT) (envelope-from harrie@inet.it) Received: from [::ffff:213.92.1.193] by hal-5.inet.it via I-SMTP-4.4.2-442 id ::ffff:213.92.1.193+K38meodH7kk0; Tue, 29 Apr 2003 11:06:17 +0200 Date: Tue, 29 Apr 2003 11:10:10 +0200 Subject: Re: IMAP Capability and Virtual Domains Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Harrie Hazewinkel , IMAP Extensions WG To: Arnt Gulbrandsen From: Harrie Hazewinkel In-Reply-To: Message-Id: <60C91510-7A22-11D7-998F-0003934A5A7E@inet.it> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tuesday, April 29, 2003, at 10:51 AM, Arnt Gulbrandsen wrote: > I don't much like VHOST. Its benefit over the current user@host hacks > seems limited to providing the right TLS certificate. But I could live > with it, provided it were simpler. > > a) Clients using VHOST should always send the IMAP server's FQDN as > argument. Nothing else. > > b) BAD should be sent only for syntax errors or command unknown. > > c) Clients should explicitly not have to wait for the answer before > proceeding with the login procedure. Correct me if I am wrong, but "do clients not have to wait for STARTTLS to finish also before a login procedure can be given??" Harrie Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T8oZi2073895 for ; Tue, 29 Apr 2003 01:50:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3T8oZid073894 for ietf-imapext-bks; Tue, 29 Apr 2003 01:50:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T8oYi2073889 for ; Tue, 29 Apr 2003 01:50:34 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:1697 "ehlo melkebalanse.gulbrandsen.priv.no" ident: "NO-IDENT-SERVICE[2]") by bra.gulbrandsen.priv.no with ESMTP id ; Tue, 29 Apr 2003 10:50:21 +0200 Message-Id: From: Arnt Gulbrandsen To: Harrie Hazewinkel , IMAP Extensions WG Subject: Re: IMAP Capability and Virtual Domains References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> In-Reply-To: <00fa01c30e21$430c6020$d1d07b43@cocacola> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 29 Apr 2003 10:51:09 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I don't much like VHOST. Its benefit over the current user@host hacks seems limited to providing the right TLS certificate. But I could live with it, provided it were simpler. a) Clients using VHOST should always send the IMAP server's FQDN as argument. Nothing else. b) BAD should be sent only for syntax errors or command unknown. c) Clients should explicitly not have to wait for the answer before proceeding with the login procedure. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T7Uri2058555 for ; Tue, 29 Apr 2003 00:30:53 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3T7UrvG058554 for ietf-imapext-bks; Tue, 29 Apr 2003 00:30:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T7Uni2058533 for ; Tue, 29 Apr 2003 00:30:49 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 2349F883DD6; Tue, 29 Apr 2003 00:30:49 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 9EF1D883D93; Tue, 29 Apr 2003 00:30:46 -0700 (PDT) Message-ID: <00fa01c30e21$430c6020$d1d07b43@cocacola> From: "Michael Fair" To: Cc: "Harrie Hazewinkel" References: <019701c30dd9$d6019c80$d1d07b43@cocacola> Subject: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 00:30:46 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-6.6 required=5.0 tests=REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, I understand that in general this list is not very actively interested in scaling the IMAP protocol to support lots of domains on a single IP address. Myself and I know a number of others (mainly hosting companies) are interested in this feature. Currently only HTTP 1.1 has any kind of support for this kind of scaling. I'll be brief, a quick education on the issues for those that don't understand the problem or haven't read the VHOST extension draft and then a suggestion that I believe would quite neatly solve all the issues plus a couple that none of the existing solutions offer while still maintaing compatibility with existing clients/servers and allow for a mostly gradual transition between non-virtualized and virtualized deployment. The issues: At the core of it, in most hosting for hire environments you typically get a lot of domains that only have a few users (less than 30). In a modest ISP, having to support 1,000 domains is very reasonable. The vast majority of those domains typically have less than 5 accounts, and the number with more than 30 accounts is usually countable on one or two hands. This creates a situation where you have about 10,000-20,000 accounts spread over 1,000 domains. This is easily hosted on any decent sized server and hosting this on a single machine is a very reasonable thing to do. The problem is that this ISP typically has a /21 giving it a total of 1,275 IP addresses. If this ISP was to try and give the highest quality of service at 1 IP address per domain, which the existing protocol calls for, this ISP would have 1,000 IP addresses all pointed at the same server and have 273 left over for other uses. In the case of the medium size ISP it is actually impossible to even consider offering such a service. This is especially compounded if you start to include other services like FTP. As another consideration this doesn't even touch trying to provide geographically redundant services where the data is accessible from at least two (preferably three) redundant sites that are located on completely separate IP networks. (This means at least two preferably three IPs per domain) So the short of it is that for certain very common environments there is a clear and definite need for being able to multiplex multiple domains onto a single IP address. A brief overview on the current state of trying to accomplish this: When a client shows up at the server's door all it knows is the IP address the client was trying to reach. This is completely insufficient to determine the targetted domain unless you have 1 IP per domain. In short, the server must be told directly what domain the client was trying to reach before it can access any domain specific parameters (these include shared folders, security certificates and any other parameters a server might want to modify on a per domain basis (like AUTH services)). The other need for per domain identification is to allow for bob@domain1.dom to be differentiated from bob@domain2.dom when the client only presents the username "bob". Current single IP implementations pack the domain info in the usernames and then do some magic after authentication to create the domain specific view. How they pack the domain info varies from site to site, but the username is the only client submitted information that can reliably be used to identify the targetted domain. The problem with this solution is that there are several things that happen before LOGIN or AUTH where knowing the domain would be useful. Namely STARTTLS and CAPABILITY. The current IMAP extension draft adds a "VHOST" command to specify which virtual host the client was trying to reach. Overall I think it's a good proposal, but I believe the same result can be accomplished without the need for adding a new command. I had an offline discussion with Mark Crispin and proposed adding the domain name as an optional parameter to CAPABILITY. My assumption was that the very first thing an IMAP client is going to do (even before STARTTLS) is CAPABILITY to find out if the server can even do STARTTLS and to figure out what methods of authentication the server makes available. By identifying the domain prior to any other commands, the server has the opportunity to get into a domain specific mode very early. For instance, STARTTLS could now provide a per domain certificate instead of being forced to provide a single (usually ISP specific) cert, or even worse, not offering IMAPS at all. If that assumption is wrong, then I hope that someone would correct me as it makes this suggestion rather worthless and makes the VHOST addition a more viable solution. Once a client had issued a CAPABILITY with a domain parameter, the server would go into a domain specific mode where all responses would be local to that domain's config. The main restrictions for a client would be that during a TLS session and/or while in the AUTHENTICATED state the client MUST NOT issue a CAPABILITY where that domain parameter is different. If a client were allowed to jump domains in the middle of those contexts it would be ambiguous at best, and create security holes at worst. The server is of course encouraged to take whatever steps are appropriate to ensure that the client doesn't try and jump domains in these contexts. Currently CAPABILITY accepts no parameters and it's an error to present one. Clients could try first with the domain, and then upon receiving BAD try without the domain. If a server supported the parameter, but not the requested domain, the server could either respond with NO saying that the domain isn't supported, or it could respond with YES if the server just swallows the parameter and gives the same behavior regardless of the domain. This makes the existing servers behavior remain correct, allows for servers to be compatible by simply swallowing the parameter and not doing anything with it, and future servers can implement a true virtualized hosted environment. If a client tries to jump domain contexts, the server should answer "NO" if it would have answered "NO" to an unavailable or not supported domain, or it should simply swallow the parameter or respond with "BAD" if it would have swallowed the parameter or reposnded with "BAD" before. Clients that support this need only be prepared to receive a BAD or NO when issuing a CAPABILITY and conform to not trying to jump domains when in a TLS session or AUTHENTICATED state. As an added bonus, this also lays the groundwork for some future planning on replicating and scaling IMAP mail stores to span multiple mail stores to provide geograhic redundancy. Without this feature the "IP burn rate" jumps to 1+N addresses per domain where N is the number of geographically redundant mail stores. It's true that this might solveable with a distributed file system instead of an IMAP extension protocol, but I believe it would be harmful to ignore the idea that there are those in the world who care enough about reliability to use three or four distributed machines to maintain replicas of the mail store for performance and redundancy. Thank you very much for reading and I look forward to comments and feedback. Again, I do understand that this is not a need that most people on this list consider very important so taking the time out to lend some grey matter to it is greatly appreciated. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NC97t2014122 for ; Wed, 23 Apr 2003 05:09:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NC97nS014121 for ietf-imapext-bks; Wed, 23 Apr 2003 05:09:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NC95t2014116 for ; Wed, 23 Apr 2003 05:09:05 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 500045E017F5; Wed, 23 Apr 2003 15:09:05 +0300 (EEST) Subject: Re: Full text search and SEARCHM IMAP extention From: Timo Sirainen To: Takeshi Morishima Cc: ietf-imapext@imc.org In-Reply-To: <1955-Tue22Apr2003222857-0500-tm@onepost.net> References: <1955-Tue22Apr2003071742-0500-tm@onepost.net> <1051017925.32160.92.camel@hurina> <1955-Tue22Apr2003222857-0500-tm@onepost.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051099745.32157.157.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 23 Apr 2003 15:09:05 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2003-04-23 at 06:28, Takeshi Morishima wrote: > Will try to update the proposal modification based on the comments. I > need study LISTEXT more - don't fully understand how it's related or > can be merged. Actually, forget it. I was just thinking that since they added STATUS support there, it could be used as some generic "for each listed mailbox, do ". But it'd require replying with LIST replies, which is probably not so useful with SEARCHM. And if result has to be sorted, it's not so simple. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N3TSt2063943 for ; Tue, 22 Apr 2003 20:29:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3N3TRXr063942 for ietf-imapext-bks; Tue, 22 Apr 2003 20:29:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N3TQt2063935 for ; Tue, 22 Apr 2003 20:29:26 -0700 (PDT) (envelope-from tm@onepost.net) Received: from sage.ml-search.com (12-207-101-182.client.attbi.com[12.207.101.182]) by rwcrmhc52.attbi.com (rwcrmhc52) with ESMTP id <2003042303291905200ntvlee>; Wed, 23 Apr 2003 03:29:21 +0000 Date: Tue, 22 Apr 2003 22:28:57 -0500 Message-Id: <1955-Tue22Apr2003222857-0500-tm@onepost.net> X-Mailer: cmail 2.62 on GNU Emacs 20.7.1 / Mule 4.1 (AOI) (via feedmail 8 I) References: <1955-Tue22Apr2003071742-0500-tm@onepost.net> <1051017925.32160.92.camel@hurina> From: tm@onepost.net (Takeshi Morishima) To: tss@iki.fi CC: ietf-imapext@imc.org In-reply-to: Timo Sirainen's message of "22 Apr 2003 16:25:25 +0300" <1051017925.32160.92.camel@hurina> Subject: Re: Full text search and SEARCHM IMAP extention 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: In message "Re: Full text search and SEARCHM IMAP extention" on 2003/04/22, Timo Sirainen writes: > One thing that I've thought that could be useful is to return the text > that matched so client could display google-like search results directly > without fetching all the messages. I'd agree that this may be useful. This would be new data type though, with mime content headers re-constructed for summary text. > I'm not sure if msgmax / msgstart is such a good idea. You > probably want it for prev/next page-like feature, but if new > matches appear between searches, you might miss some messages. My initial motivation of these options was to allow client to specify max number of messages to be returned. Client could prepare only resource that would be needed that way, thus more effcient use of resources. It also saves a bit of bandwidth of returning only 200 of top score out of total 1000 hits. Then suddenly I thought that if we limit the amount of search result by msgmax, I would need msgstart in case user is not satisfactory in the search result and want to get next block of result, since otherwise the client may end up receiving the same block of data repeatedly as it increases msgmax, which did not sound very efficient. For the issue of result changes between searches, I also thought about it, and had one idea of using the search name to identify previous search context so that the server can remember it and provide consistent output. This would require the client to use differnt search name everytime new search is performed, the server side to provide more resource, and will complicate things, which did not sound like a good idea. Since this modified searchm is intended for best effort search, I thought that dup or missing messages may not be an issue for typical case, resulted in this form. (Probably no need of msgend, just use msgstart+msgmax.) Will try to update the proposal modification based on the comments. I need study LISTEXT more - don't fully understand how it's related or can be merged. Regards, Takeshi Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MLTBt2046673 for ; Tue, 22 Apr 2003 14:29:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MLTBMh046672 for ietf-imapext-bks; Tue, 22 Apr 2003 14:29:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MLT9t2046666 for ; Tue, 22 Apr 2003 14:29:10 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:10983 "ehlo melkebalanse.gulbrandsen.priv.no") by gulbrandsen.priv.no with ESMTP id convert rfc822-to-8bit; Tue, 22 Apr 2003 23:28:50 +0200 Message-Id: <2EHMpNqCojy8RKJEFJiRCw.md5@melkebalanse.gulbrandsen.priv.no> From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: WATCH extension for IMAP Cc: IMAP Extensions WG References: In-Reply-To: Content-Transfer-Encoding: 8BIT Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 22 Apr 2003 23:28:29 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > This is in effect an IMAP interface to an ultra-lightweight > notification protocol and facility that I am working on. The IMAP > server won't do any actual "watching"; instead, it will just be a > client to the notification facility. Isn't that a natural implementation choice? > I am interested in feedback as to whether this proposed extension is > interesting or not. Yes. But as internet-draft, please. > Also, would it be better to build an extension which has extensibility > but with restraints ("ultra-lightweight") on how it can be extended, > or if it should be strictly a new mail watching facility ... If the latter, perhaps it can avoid the fate of so many similar proposals? --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MIpXt2038958 for ; Tue, 22 Apr 2003 11:51:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MIpXuh038957 for ietf-imapext-bks; Tue, 22 Apr 2003 11:51:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MIpUt2038949 for ; Tue, 22 Apr 2003 11:51:31 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:15589 "ehlo melkebalanse.gulbrandsen.priv.no") by gulbrandsen.priv.no with ESMTP id ; Tue, 22 Apr 2003 20:51:17 +0200 Message-Id: From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: WATCH extension for IMAP Cc: Cyrus Daboo , Lawrence Greenfield , IMAP Extensions WG References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 22 Apr 2003 20:50:56 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Tue, 22 Apr 2003, Arnt Gulbrandsen wrote: >> > LIST can never be more expensive than STATUS. >> I can disprove that by counterexample. >> C: b list "" * > > You are comparing apples and oranges. There is no such thing as a > wildcard STATUS. Perhaps I misunderstood. I was comparing LIST to a for loop sending STATUS for e.g. 1800 mailboxes. Seemed a fair enough comparison. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MHbSt2035634 for ; Tue, 22 Apr 2003 10:37:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MHbSNs035633 for ietf-imapext-bks; Tue, 22 Apr 2003 10:37:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MHbQt2035624 for ; Tue, 22 Apr 2003 10:37:27 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3MHbFSL029531; Tue, 22 Apr 2003 10:37:20 -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+UW03.04/8.12.1+UW02.12) with ESMTP id h3MHbF4t000995 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Apr 2003 10:37:15 -0700 Date: Tue, 22 Apr 2003 10:37:15 -0700 (Pacific Daylight Time) From: Mark Crispin To: Arnt Gulbrandsen cc: Cyrus Daboo , Lawrence Greenfield , IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: Message-ID: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> 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, 22 Apr 2003, Arnt Gulbrandsen wrote: > > LIST can never be more expensive than STATUS. > I can disprove that by counterexample. > C: b list "" * You are comparing apples and oranges. There is no such thing as a wildcard STATUS. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MGJvt2031834 for ; Tue, 22 Apr 2003 09:19:57 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MGJvjg031833 for ietf-imapext-bks; Tue, 22 Apr 2003 09:19:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MGJtt2031828 for ; Tue, 22 Apr 2003 09:19:55 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id ED57D5E017F5; Tue, 22 Apr 2003 19:19:55 +0300 (EEST) Subject: Re: Pending changes to CONDSTORE From: Timo Sirainen To: Alexey Melnikov Cc: IMAP Extensions WG In-Reply-To: <3EA4CC56.C9FE5BFA@messagingdirect.com> References: <3EA4CC56.C9FE5BFA@messagingdirect.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051028395.32159.107.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 22 Apr 2003 19:19:55 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-04-22 at 08:00, Alexey Melnikov wrote: > I haven't resolved an open issue regarding atomicity of CONDSTORE for a > message set. I am still waiting for more feedback. Yes, it could be difficult with maildir at least since you can't prevent flag changes by other clients. Is there even a reason to want atomicity? Is there a reason to return MODSEQ separately for each message with SILENT STORE? And why not return the modseq and flags directly for modified messages, wouldn't client want to ask them anyway next? Something like: a STORE 100:150 (UNCHANGEDSINCE 1) +FLAGS.SILENT ($Processed) * 101 FETCH (MODSEQ (2) FLAGS ($Processed)) * 105 FETCH (MODSEQ (2) FLAGS ($Processed)) a OK [MODSEQ 3 MODIFIED 101,105] Some flags weren't changed b STORE 100 (UNCHANGEDSINCE 1) +FLAGS.SILENT ($Processed) * 100 FETCH (MODSEQ (3) FLAGS ($Processed)) b OK [MODIFIED 100] No flags were changed c STORE 100,151 (UNCHANGEDSINCE 1) +FLAGS ($Processed) * 100 FETCH (MODSEQ (3) FLAGS ($Processed)) * 151 FETCH (MODSEQ (4) FLAGS ($Processed)) c OK [MODSEQ 4 MODIFIED 100] Some flags weren't changed Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MFMlt2029713 for ; Tue, 22 Apr 2003 08:22:47 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MFMlOp029712 for ietf-imapext-bks; Tue, 22 Apr 2003 08:22:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MFMjt2029695 for ; Tue, 22 Apr 2003 08:22:46 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:25060 "ehlo melkebalanse.gulbrandsen.priv.no") by gulbrandsen.priv.no with ESMTP id ; Tue, 22 Apr 2003 17:22:29 +0200 Message-Id: From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: WATCH extension for IMAP Cc: Cyrus Daboo , Lawrence Greenfield , IMAP Extensions WG References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 22 Apr 2003 17:22:08 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > LIST can never be more expensive than STATUS. I can disprove that by counterexample. I have a crappy IMAP client (came preinstalled on a machine I bought) whose login sequence is like this when it talks to wu-imapd: C: a login arnt tnra S: a ok C: b list "" * S: ... C: (run out of memory and crash) The server's resource use is limited only by bandwidth and the client's available RAM, which is potentially far more than it would spend processing STATUS. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MDPZt2021731 for ; Tue, 22 Apr 2003 06:25:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MDPZSL021730 for ietf-imapext-bks; Tue, 22 Apr 2003 06:25:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MDPXt2021723 for ; Tue, 22 Apr 2003 06:25:33 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 043865E017F5; Tue, 22 Apr 2003 16:25:25 +0300 (EEST) Subject: Re: Full text search and SEARCHM IMAP extention From: Timo Sirainen To: Takeshi Morishima Cc: ietf-imapext@imc.org In-Reply-To: <1955-Tue22Apr2003071742-0500-tm@onepost.net> References: <1955-Tue22Apr2003071742-0500-tm@onepost.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051017925.32160.92.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 22 Apr 2003 16:25:25 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-04-22 at 15:17, Takeshi Morishima wrote: > My comments and proposed modification to the current SEARCHM draft are > described in the following file: > > http://www.ml-search.com/tmpdocs/draft-leiba-imap-search-multiple-01-comment.pdf > > It proposes to allow server to ignore unsupported criteria/mailbox, > provide sorted result fragmentation, more options to control search > result, and a new HITS response to return search statistics numbers. One thing that I've thought that could be useful is to return the text that matched so client could display google-like search results directly without fetching all the messages. This would be especially useful if server supported searching inside non-text file attachments like ms word docs, pdfs, postscripts, etc. > Also, because the search will be performed outside of selected state, > I thought that returning message sequence numbers may have a problem, > and for other reasons, I'm proposing to return UIDs and UIDVALIDITY > always in the SEARCHM response. Right. Maybe remove the whole "UID SEARCHM". Some other thoughts: Sorting conflicts a bit with SORT extension. At least change "sentdate" to "date" so they're compatible. I'm not sure if msgmax / msgstart is such a good idea. You probably want it for prev/next page-like feature, but if new matches appear between searches, you might miss some messages. I think "Mailbox URL" is wrong word to describe LIST-like mailbox wildcarded names. And should this maybe be merged with LISTEXT? Returning UIDVALIDITY before UIDs would be nicer. And it doesn't have to be in paranthesis. Anyway I'd like to have this kind of non-strict text searching. Current SEARCH can be useful for client internally, but for normal searching by user it's unnecessarily slow because it's strictness really limits the optimizations that server can do. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MCIDt2019865 for ; Tue, 22 Apr 2003 05:18:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MCIDaV019864 for ietf-imapext-bks; Tue, 22 Apr 2003 05:18:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MCICt2019859 for ; Tue, 22 Apr 2003 05:18:12 -0700 (PDT) (envelope-from tm@onepost.net) Received: from sage.ml-search.com (12-207-101-182.client.attbi.com[12.207.101.182]) by rwcrmhc52.attbi.com (rwcrmhc52) with ESMTP id <2003042212180605200h32m0e>; Tue, 22 Apr 2003 12:18:06 +0000 Date: Tue, 22 Apr 2003 07:17:42 -0500 Message-Id: <1955-Tue22Apr2003071742-0500-tm@onepost.net> X-Mailer: cmail 2.62 on GNU Emacs 20.7.1 / Mule 4.1 (AOI) (via feedmail 8 I) From: tm@onepost.net (Takeshi Morishima) To: ietf-imapext@imc.org Subject: Full text search and SEARCHM IMAP extention 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: Hello there, I've been looking into implementing a full text search on a client, to provide a multiple mailbox search with search performance similar to what we can find on many www based search engines. After implementing a repeat of select and search over multiple mailboxes, I found it slow and in most cases the search result does not appear very optimal. No framework to handle something like scoring based search result sorting, for example. Looking through existing RFCs and imap extention drafts, the closest to what I can use was the SEARCHM extention draft. The current SEARCHM draft, however, does not seem to be enough for the purpose of the above type of search. I would like this to be loosely coupled, best effort and best practice search capable, instead of requiring a strict listing for house keeping of client that SEARCHM is mainly intended to. A full text search would not need to deal with something like "unseen" type of search, and can omit messages that unlikely of user interest in a search result. My comments and proposed modification to the current SEARCHM draft are described in the following file: http://www.ml-search.com/tmpdocs/draft-leiba-imap-search-multiple-01-comment.pdf It proposes to allow server to ignore unsupported criteria/mailbox, provide sorted result fragmentation, more options to control search result, and a new HITS response to return search statistics numbers. Also, because the search will be performed outside of selected state, I thought that returning message sequence numbers may have a problem, and for other reasons, I'm proposing to return UIDs and UIDVALIDITY always in the SEARCHM response. Since the purposes of SEARCHM and the modified version above slightly differ, should it be different command? Or is this something that can be incorporated into the current searchm draft. If this is not worth discussing in this WG list nor standardization, please advice where I should take this to - any comments and suggestions would be appreciated. Regards, Takeshi Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MBgmt2015540 for ; Tue, 22 Apr 2003 04:42:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MBgmdk015539 for ietf-imapext-bks; Tue, 22 Apr 2003 04:42:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MBgkt2015531 for ; Tue, 22 Apr 2003 04:42:47 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03297; Tue, 22 Apr 2003 07:40:02 -0400 (EDT) Message-Id: <200304221140.HAA03297@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-condstore-01.txt Date: Tue, 22 Apr 2003 07:40:02 -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. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP Extension for Conditional STORE operation Author(s) : A. Melnikov, S. Hole Filename : draft-ietf-imapext-condstore-01.txt Pages : 16 Date : 2003-4-21 Often, multiple IMAP clients need to coordinate changes to a common IMAP mailbox. Examples include different clients for the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags or annotations) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-01.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-ietf-imapext-condstore-01.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-ietf-imapext-condstore-01.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: <2003-4-21143900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-condstore-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-condstore-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-21143900.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3M5R9t2073356 for ; Mon, 21 Apr 2003 22:27:09 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3M5R9Ev073355 for ietf-imapext-bks; Mon, 21 Apr 2003 22:27:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3M5R8t2073350 for ; Mon, 21 Apr 2003 22:27:08 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust66.tnt3.edmonton.ab.da.uu.net [64.10.184.66]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3M5UhV18436; Mon, 21 Apr 2003 23:30:43 -0600 Message-ID: <3EA4CC56.C9FE5BFA@messagingdirect.com> Date: Mon, 21 Apr 2003 23:00:06 -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: IMAP Extensions WG Subject: Pending changes to CONDSTORE 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: I haven't resolved an open issue regarding atomicity of CONDSTORE for a message set. I am still waiting for more feedback. Also, I would like to propose to add a new capability if MODSEQ sort criteria is implemented with SORT. Any objections to this? Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5pJt2032072 for ; Sat, 19 Apr 2003 22:51:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K5pJCR032071 for ietf-imapext-bks; Sat, 19 Apr 2003 22:51:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5pHt2032066 for ; Sat, 19 Apr 2003 22:51:17 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust193.tnt3.edmonton.ab.da.uu.net [64.10.184.193]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3K5rBV29565; Sat, 19 Apr 2003 23:53:12 -0600 Message-ID: <3EA234E7.6F36C341@messagingdirect.com> Date: Sat, 19 Apr 2003 23:49:27 -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: IMAP Extensions WG CC: IMAP Discusson List Subject: Updated draft-ietf-imapext-condstore document Content-Type: multipart/mixed; boundary="------------6D49FEEA8037F438115381F7" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6D49FEEA8037F438115381F7 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit I've updated the document as per comments from Mark and Cyrus. New version (draft-ietf-imapext-condstore-01) should appear shortly. In the meantime, I've attached the diff for the changes. Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html I speak for myself only, not for my employer. __________________________________________ --------------6D49FEEA8037F438115381F7 Content-Type: text/plain; charset=koi8-r; name="00-01.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="00-01.diff.txt" --- draft-ietf-imapext-condstore-00.txt Thu Mar 27 00:27:06 2003 +++ draft-ietf-imapext-condstore-01.txt Fri Apr 11 23:29:42 2003 @@ -1,7 +1,7 @@ Internet Draft: IMAP Extension for Conditional STORE A. Melnikov -Document: draft-ietf-imapext-condstore-00.txt S. Hole -Expires: September 2003 ACI WorldWide/MessagingDirect - March 2003 +Document: draft-ietf-imapext-condstore-01.txt S. Hole +Expires: October 2003 ACI WorldWide/MessagingDirect + April 2003 IMAP Extension for Conditional STORE operation @@ -43,6 +43,13 @@ 0.2. Change History + Changes from draft-ietf-imapext-condstore-00 + 1. Dropped "/message" prefix in entry names as per decision in San Francisco. + 2. Fixed ABNF for SEARCH and SORT untagged responses. + 3. Changed "private" to "priv" to be consistent with ANNOTATE. + 4. MODIFIED response code is now returned in OK response, not NO. + 5. Added NOMODSEQ response code. + Changes from draft-melnikov-imap-condstore-09: 1. Some text clarifications based on suggestions by Harrie Hazewinkel 2. Added paragraph about mailbox locking and DOS when conditional STORE @@ -139,6 +146,7 @@ 4 IMAP Protocol Changes ..................................... X 4.1 New OK untagged responses for SELECT and EXAMINE ......... X 4.1.1 HIGHESTMODSEQ response code ............................ X + 4.1.2 NOMODSEQ response code ................................. X 4.2 STORE and UID STORE Commands ............................. X 4.3 MODSEQ message data item in FETCH Command ................ X 4.4 MODSEQ search criterion in SEARCH ........................ X @@ -240,13 +248,18 @@ different metadata items. If the server does so, per message mod-sequence is the highest mod-sequence of all metadata items for the specified message. + The server that supports this extention is not required to be able to store + mod-sequences for every available mailbox. Section 4.1.2 describes how + the server may act if a particular mailbox doesn't support the persistent + storage of mod-sequences. + This extension makes the following changes to the IMAP4 protocol: a) extends the syntax of the STORE command to allow STORE modifiers b) adds the MODIFIED response code which should be used with - a NO response to the STORE command + an OK response to the STORE command c) adds a new MODSEQ message data item for use with the FETCH command @@ -269,13 +282,26 @@ 4.1. New OK untagged responses for SELECT and EXAMINE + This document adds two new response codes HIGHESTMODSEQ and NOMODSEQ. + One of those response codes MUST be returned in the OK untagged + response for a successful SELECT and EXAMINE commands. + + When opening a mailbox the server must check if the mailbox supports + the persistent storage of mod-sequences. If the mailbox supports + the persistent storage of mod-sequences and mailbox open operation succeeds, + the server MUST send the OK untagged response including HIGHESTMODSEQ + response code. If the persistent storage for the mailbox is not supported, + the server MUST send the OK untagged response including NOMODSEQ response + code instead. + + 4.1.1. HIGHESTMODSEQ response code This document adds a new response code that is returned in the OK untagged response for the SELECT and EXAMINE commands. A server - supporting the CONDSTORE extension MUST send the OK untagged - response including HIGHESTMODSEQ response code with every successful - SELECT or EXAMINE command: + supporting the persistent storage of mod-sequences for the mailbox MUST + send the OK untagged response including HIGHESTMODSEQ response code with + every successful SELECT or EXAMINE command: OK [HIGHESTMODSEQ ] @@ -307,6 +333,24 @@ S: A142 OK [READ-WRITE] SELECT completed +4.1.2 NOMODSEQ response code + + A server that doesn't support the persistent storage of mod-sequences for + the mailbox MUST send the OK untagged response including NOMODSEQ response + code with every successful SELECT or EXAMINE command. + + Example: C: A142 SELECT INBOX + S: * 172 EXISTS + S: * 1 RECENT + S: * OK [UNSEEN 12] Message 12 is first unseen + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: * OK [UIDNEXT 4392] Predicted next UID + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited + S: * OK [NOMODSEQ] Sorry, this mailbox format doesn't support modsequences + S: A142 OK [READ-WRITE] SELECT completed + + 4.2. STORE and UID STORE Commands Arguments: message set @@ -328,8 +372,9 @@ UNCHANGEDSINCE If the mod-sequence of any metadata item specified in the STORE operation for any message in the message set is greater than the - specified unchangedsince value, then the command fails. - On failure, a MODIFIED response code is returned which includes + specified unchangedsince value, then the command MUST NOT change + any flags. Instead, the server replies with the OK tagged response that + includes a MODIFIED response code. The MODIFIED response code includes the message set (for STORE) or set of UIDs (for UID STORE) of all messages that failed the UNCHANGESINCE test. @@ -337,7 +382,7 @@ C: a101 STORE 7,5,9 (UNCHANGEDSINCE 20000320162338) +FLAGS.SILENT (\Deleted) - S: a101 NO [MODIFIED 7,9] Conditional STORE failed + S: a101 OK [MODIFIED 7,9] Conditional STORE failed In spite of the failure of the conditional STORE operation for message 7, the server continues to process the conditional @@ -351,7 +396,7 @@ C: a102 STORE 12 (UNCHANGEDSINCE 0) +FLAGS.SILENT ($MDNSent) - S: a102 NO [MODIFIED 12] Conditional STORE failed + S: a102 OK [MODIFIED 12] Conditional STORE failed Note: A client trying to atomically change the state of a particular flag (or a set of flags) should be prepared to deal with the case @@ -370,7 +415,7 @@ Example: C: a106 STORE 100:150 (UNCHANGEDSINCE 200212030000000) +FLAGS.SILENT ($Processed) - S: a106 NO [MODIFIED 101] Conditional STORE failed + S: a106 OK [MODIFIED 101] Conditional STORE failed the flag $Processed was set on the message 101 ... C: a107 NOOP @@ -560,15 +605,15 @@ cache. The client may also specify (name of metadata item) and (type of metadata item) before . can be one of "shared", - "private" or "all". The latter means that the server should use - the biggest value among "private" and "shared" modseqs for the + "priv" (private) or "all". The latter means that the server should use + the biggest value among "priv" and "shared" mod-sequences for the metadata item. If the server doesn't store internally separate mod-sequences for different flags and annotations, it MUST ignore and . Otherwise the server should use them to narrow down the search. For a flag the corresponding has a form - "/message/flags/" as defined in [ANNOTATE]. Note, that + "/flags/" as defined in [ANNOTATE]. Note, that the leading "\" character that denotes a system flag has to be escaped as per Section 4.3 of [IMAP4], as the uses syntax for quoted strings. @@ -580,14 +625,14 @@ See also section 4.6. Example: - C: a SEARCH MODSEQ "/message/flags/draft" all 20010320162338 - ANNOTATION "/message/comment" "value" "IMAP4" + C: a SEARCH MODSEQ "/flags/draft" all 20010320162338 + ANNOTATION "/comment" "value" "IMAP4" S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 20010917162500) S: a OK Search complete In the above example, the message numbers of any messages containing the string "IMAP4" in the "value" attribute of the - "/message/comment" entry and having a mod-sequence equal to or + "/comment" entry and having a mod-sequence equal to or greater than 20010320162338 for the "\Draft" flag are returned in the search results. @@ -684,9 +729,6 @@ status-att-req = status-att / "HIGHESTMODSEQ" - mailbox-data =/ "STATUS" SP mailbox SP "(" - [status-rsp-info *(SP status-rsp-info)] ")" - status-rsp-info = status-att SP number / "HIGHESTMODSEQ" SP mod-sequence-value @@ -713,21 +755,22 @@ search-modseq-ext = SP entry-name SP entry-type-req resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value / + "NOMODSEQ" / "MODIFIED" SP set - entry-name = '"' "/message/flags/" attr-flag '"' + entry-name = '"' "/flags/" attr-flag '"' ;; each system or user defined flag - ;; is mapped to "/message/flags/". + ;; is mapped to "/flags/". ;; ;; follows the escape rules used ;; by "quoted" string as described in Section ;; 4.3 of [IMAP4], e.g. for the flag \Seen ;; the corresponding is - ;; "/message/flags/\\seen", and for the flag + ;; "/flags/\\seen", and for the flag ;; $MDNSent, the corresponding - ;; is "/message/flags/$mdnsent". + ;; is "/flags/$mdnsent". - entry-type-resp = "private" | "shared" + entry-type-resp = "priv" | "shared" ;; metadata item type entry-type-req = entry-type-resp | "all" @@ -749,8 +792,10 @@ ;;Borrowed from IMAP4rev1 and modified accordingly: - mailbox-data =/ "SEARCH" [SP nz-number *(SP nz-number) search_sort_mod_seq] / - "SORT" [SP nz-number *(SP nz-number) search_sort_mod_seq] + mailbox-data =/ "STATUS" SP mailbox SP "(" + [status-rsp-info *(SP status-rsp-info)] ")" / + "SEARCH" [1*(SP nz-number) SP search_sort_mod_seq] / + "SORT" [1*(SP nz-number) SP search_sort_mod_seq] attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" / "\\Seen" / "\\Draft" / attr-flag-keyword / @@ -828,8 +873,8 @@ interact with ANNOTATE extension and for thorough review of the document. Authors also acknowledge the feedback provided by Cyrus Daboo, Larry - Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen and Timo - Sirainen. + Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen Timo + Sirainen and Mark Crispin. 9. Author's Addresses --------------6D49FEEA8037F438115381F7-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5cxt2031869 for ; Sat, 19 Apr 2003 22:38:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K5cxTn031868 for ietf-imapext-bks; Sat, 19 Apr 2003 22:38:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5cwt2031861 for ; Sat, 19 Apr 2003 22:38:58 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust193.tnt3.edmonton.ab.da.uu.net [64.10.184.193]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3K5gRV29510; Sat, 19 Apr 2003 23:42:28 -0600 Message-ID: <3EA22FD4.57358871@messagingdirect.com> Date: Sat, 19 Apr 2003 23:27:48 -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: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <2147483647.1050082841@[10.0.1.6]> <3EA22E31.DA45B5C@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Cyrus Daboo wrote: > > > The formal syntax for 'entry-name' should be simply defined as: > > > > entry-name = string > > > > to fall in line with ANNOTATE. > > BTW, there is no ABNF element for entry-name in ANNOTATE, there are "entry" and > "entry-match". Also, ANNOTATE SEARCH criteria uses entry-match, which allows for wildcards. CONDSTORE doesn't use wildcards. Any opinions whether the document should/should not allow for wildcards? Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5cnt2031859 for ; Sat, 19 Apr 2003 22:38:49 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K5cng9031858 for ietf-imapext-bks; Sat, 19 Apr 2003 22:38:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5clt2031853 for ; Sat, 19 Apr 2003 22:38:48 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust193.tnt3.edmonton.ab.da.uu.net [64.10.184.193]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3K5gFV29502; Sat, 19 Apr 2003 23:42:20 -0600 Message-ID: <3EA22E31.DA45B5C@messagingdirect.com> Date: Sat, 19 Apr 2003 23:20:49 -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: Cyrus Daboo CC: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <2147483647.1050082841@[10.0.1.6]> 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: Cyrus Daboo wrote: > The formal syntax for 'entry-name' should be simply defined as: > > entry-name = string > > to fall in line with ANNOTATE. BTW, there is no ABNF element for entry-name in ANNOTATE, there are "entry" and "entry-match". > There should be a comment/reference to the > annotate spec at that point. Sure. > That will also allow you to remove the comment > about escape rules at that point. There is nothing wrong with repeating obvious ;-). > Also, could be use "priv" instead of "private" for entry-type-resp just to > fall in line with the suffixes that ANNOTATE uses? So you want to use "priv" and "shared"? I've just updated the document. Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5cht2031851 for ; Sat, 19 Apr 2003 22:38:43 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K5chbb031850 for ietf-imapext-bks; Sat, 19 Apr 2003 22:38:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5cft2031845 for ; Sat, 19 Apr 2003 22:38:41 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust193.tnt3.edmonton.ab.da.uu.net [64.10.184.193]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3K5g8V29498; Sat, 19 Apr 2003 23:42:08 -0600 Message-ID: <3EA226A8.C4AC1C0A@messagingdirect.com> Date: Sat, 19 Apr 2003 22:48:40 -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: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <2147483647.1050084387@[10.0.1.6]> <3E9793F0.A48EF7E2@messagingdirect.com> <2147483647.1050147388@[10.0.1.3]> 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: > On Sat, 12 Apr 2003, Cyrus Daboo wrote: > > | Why would one want to use MODSEQ with THREAD? > > For the same reason one would use it in the search criteria on sort: to > > have the command return results only for those messages that changed since > > the MODSEQ. I doubt this is really a useful behaviour but it has to be > > present for consistency if you are adding MODSEQ to search unless its > > explicitly stated MODSEQ can't be used in sort/thread search criteria. > > I'm hard-pressed to think of a use for MODSEQ with THREAD; and while SORT > presents some possible use I doubt that there would be much of that in > real life. I agree with Mark here. I can see a utility in MODSEQ criterion in SEARCH and MODSEQ sort order in SORT. I prefer to live it unspecified how MODSEQ search criteria can be used in THREAD. Any objections? > If you declare that MODSEQ is an additional argument to SEARCH (much as > CHARSET is) instead of a SEARCH criterion, then you avoid the issue. But > that's no good if you decide to have MODSEQ in SORT. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J0C5t2041997 for ; Fri, 18 Apr 2003 17:12:05 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3J0C5V6041996 for ietf-imapext-bks; Fri, 18 Apr 2003 17:12:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J0C4t2041991 for ; Fri, 18 Apr 2003 17:12:04 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.4] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id UAA16017; Fri, 18 Apr 2003 20:08:37 -0400 (EDT) Date: Fri, 18 Apr 2003 20:12:06 -0400 From: Cyrus Daboo To: Ken Murchison cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP Message-ID: <2147483647.1050696726@[10.0.1.4]> In-Reply-To: <3EA04FD7.B5D87545@oceana.com> References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> <200304180824.h3I8ODe28297@katroo.Sendmail.COM> <2147483647.1050673752@[63.163.82.24]> <3EA04FD7.B5D87545@oceana.com> X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Ken, --On Friday, April 18, 2003 3:19 PM -0400 Ken Murchison wrote: |> This shows up the problem that the client still has to poll via NOOP to |> get results. Obviously, if a mailbox was selected, the client could use |> IDLE and WATCH would come back during IDLE without the need to poll. But |> how would we deal with a connection that does not have a selected |> mailbox? The client could select a 'dummy' mailbox and then use idle, |> but wouldn't it be better to allow IDLE outside of selected state if |> WATCH is present? | | IIRC, IDLE is already allowed in both the authenticated and selected | states. You're right - it is. The comment on what state its valid for is in the formal syntax and I missed it there. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IM36t2039367 for ; Fri, 18 Apr 2003 15:03:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IM36X6039366 for ietf-imapext-bks; Fri, 18 Apr 2003 15:03:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IM35t2039359 for ; Fri, 18 Apr 2003 15:03:05 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3IM2tFd014840; Fri, 18 Apr 2003 15:02:55 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7/8.11.6) with ESMTP id h3IM4Ze26467; Fri, 18 Apr 2003 15:04:35 -0700 (PDT) Message-Id: <200304182204.h3IM4Ze26467@katroo.Sendmail.COM> To: Rob Siemborski Cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-reply-to: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> <200304180824.h3I8ODe28297@katroo.Sendmail.COM> Date: Fri, 18 Apr 2003 15:03:01 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: >On Fri, 18 Apr 2003, Philip Guenther wrote: > >> It's all a matter to explaining to the execs the costs of the tradeoffs >> that they're requesting. > >Sure, but that just moves around who is looking at the cost, the fact is >that server costs aren't the ONLY ones to consider. Right; that's why I used the word 'tradeoffs' to indicate that there are costs and benefits to every choice. Anyone who hides that fact only has themselves to blame when all the costs end up on their shoulders. Writing a protocol that does the same by transfering all the costs and complexity to the server is all too easy. There are reasons why IMAP and LDAP are widely implemented and ACAP isn't. ... >Saying that a proposal can't be improved because it is already better than >what we currently have doesn't make a lot of sense. Of course, faster is always better, but 1) going from "poll-interval" to "round-trip time" is a big saving compared to going from "round-trip time" to "instantly". For updating 'background' information in a human interface (that's the use people have been talking about), I suspect the benefit to the user is all in that first big step. 2) clients *do* poll instead of opening N connections, one per-mailbox, even though the latter offers "as soon as possible" updates, so clients are willing to make a tradeoff when faced with it If WATCH BIFF is implementable on most servers with what appears to be a very short poll interval ("I always see BIFFs within a second or so") but WATCH STATUS varies server to server, sometimes appearing to be as responsive as BIFFs but other times appearing to have, say, a 30 second poll interval, how will client authors react? Always use WATCH BIFF? Always use WATCH STATUS? Always use WATCH STATUS and tell your users to yell at the authors of the slow servers? Something else? Philip Guenther Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IKcNt2037349 for ; Fri, 18 Apr 2003 13:38:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IKcNVo037348 for ietf-imapext-bks; Fri, 18 Apr 2003 13:38:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (lamarth@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IKcLt2037343 for ; Fri, 18 Apr 2003 13:38:21 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id NAA06793; Fri, 18 Apr 2003 13:38:14 -0700 (PDT) Date: Fri, 18 Apr 2003 13:34:35 -0700 (PDT) From: Mark Crispin Subject: RE: WATCH extension for IMAP To: Rob Siemborski cc: John Milan , "'Philip Guenther'" , "'IMAP Extensions WG'" 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 Fri, 18 Apr 2003 16:30:55 -0400 (EDT), Rob Siemborski wrote: > Sorry, perhaps I should have phrased it as "several people on the list > have expressed interest in following up on this", (both "WATCH=BIFF" and > "WATCH=STATUS") but certainly a WATCH extention of some type. OK. I agree that there is some concensus with that wording. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IKV0t2037177 for ; Fri, 18 Apr 2003 13:31:00 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IKUxTM037176 for ietf-imapext-bks; Fri, 18 Apr 2003 13:30:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IKUwt2037171 for ; Fri, 18 Apr 2003 13:30:58 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from UNIX45.andrew.cmu.edu (UNIX45.andrew.cmu.edu [128.2.13.175]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp7.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3IKUurh019254; Fri, 18 Apr 2003 16:30:56 -0400 Date: Fri, 18 Apr 2003 16:30:55 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: John Milan , "'Philip Guenther'" , "'IMAP Extensions WG'" Subject: RE: WATCH extension for IMAP In-Reply-To: Message-ID: References: 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, 18 Apr 2003, Mark Crispin wrote: > On Fri, 18 Apr 2003 15:52:59 -0400 (EDT), Rob Siemborski wrote: > > So, I think its pretty clear that this is a desired feature to have. > > I don't see how you came up with that conclusion, unless you mean "desire" in > terms of "asking for the moon". Sorry, perhaps I should have phrased it as "several people on the list have expressed interest in following up on this", (both "WATCH=BIFF" and "WATCH=STATUS") but certainly a WATCH extention of some type. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IKOgt2037035 for ; Fri, 18 Apr 2003 13:24:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IKOgUI037034 for ietf-imapext-bks; Fri, 18 Apr 2003 13:24:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (jtis@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IKOet2037029 for ; Fri, 18 Apr 2003 13:24:40 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id NAA06774; Fri, 18 Apr 2003 13:24:30 -0700 (PDT) Date: Fri, 18 Apr 2003 12:55:03 -0700 (PDT) From: Mark Crispin Subject: RE: WATCH extension for IMAP To: Rob Siemborski cc: John Milan , "'Philip Guenther'" , "'IMAP Extensions WG'" 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 Fri, 18 Apr 2003 15:52:59 -0400 (EDT), Rob Siemborski wrote: > So, I think its pretty clear that this is a desired feature to have. I don't see how you came up with that conclusion, unless you mean "desire" in terms of "asking for the moon". > Is there anything more formal written than what's been in this thread on > the list? There is working code. It only needs final assembly. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJrBt2036487 for ; Fri, 18 Apr 2003 12:53:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IJrB3r036486 for ietf-imapext-bks; Fri, 18 Apr 2003 12:53:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJr6t2036481 for ; Fri, 18 Apr 2003 12:53:06 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3IJqxdg004650; Fri, 18 Apr 2003 15:52:59 -0400 Date: Fri, 18 Apr 2003 15:52:59 -0400 (EDT) From: Rob Siemborski To: John Milan cc: "'Mark Crispin'" , "'Philip Guenther'" , "'IMAP Extensions WG'" Subject: RE: WATCH extension for IMAP In-Reply-To: <000201c305db$40896a30$3d02a8c0@Grant> Message-ID: References: <000201c305db$40896a30$3d02a8c0@Grant> 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, 18 Apr 2003, John Milan wrote: > Why put so much effort into half measures? If everyone acknowledges > WATCH to be an issue worth solving why not *completely* solve it in the > protocol and wait for implementations to catch up. So, I think its pretty clear that this is a desired feature to have. However, it is decidedly difficult to discuss a hypothetical protocol extention. Is there anything more formal written than what's been in this thread on the list? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJPNt2035948 for ; Fri, 18 Apr 2003 12:25:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IJPNDc035947 for ietf-imapext-bks; Fri, 18 Apr 2003 12:25:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from teamdirection.com (s173.n12.vds2000.com [66.84.12.173]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJPMt2035941 for ; Fri, 18 Apr 2003 12:25:22 -0700 (PDT) (envelope-from johnm@teamdirection.com) Received: from Grant ([64.122.96.14]) by teamdirection.com (8.12.9/8.11.2) with SMTP id h3IJP39h017674; Fri, 18 Apr 2003 15:25:04 -0400 Reply-To: From: "John Milan" To: "'Mark Crispin'" Cc: "'Rob Siemborski'" , "'Philip Guenther'" , "'IMAP Extensions WG'" Subject: RE: WATCH extension for IMAP Date: Fri, 18 Apr 2003 12:25:03 -0700 Organization: TeamDirection.com Message-ID: <000301c305e0$37f82b90$3d02a8c0@Grant> 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, Build 10.0.2627 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: >> Why put so much effort into half measures? If everyone acknowledges >> WATCH to be an issue worth solving why not *completely* solve it in >> the protocol and wait for implementations to catch up. > Sometimes, implementations never catch up. FTP is an excellent example. I think this just means that some pieces are more important than others. As a developer for commercial software I'm often surprised at how the market responds to features regardless of my level of effort. It would be hard to argue that FTP is somehow wrong simply because the marketplace hasn't clamored for full implementation. In fact, the ubiquity of FTP speaks precisely to the fact that the designers thoroughly solved a problem, and that the world at large prioritized the bare minimum needed. > On the other hand, if you do a partial solution that solves the 98% case and is available now, it will be good enough *and* > get useful work accomplished. Well, 98% is more of a nearly complete solution than a partial solution my book :) If you think this is a nearly complete solution, then you are doing the right thing by pushing it. However, I would like to see expressions be watchable as well. Maybe that falls in the missing 2%, but other people are bringing up issues as well, so there may be a few more percentage points missing. My thesis is, regardless of whether it technically feasible or not, why not create a richer implementation of WATCH that addresses as many features everyone is proposing as possible. Yeah things get more complicated, but take a look at the XML spec. Talk about complicated! But if it solves a problem, then complication is a necessary tradeoff. And as the adoption of XML shows, implementors can navigate the complexity. I just think its very useful to address as many issues in a protocol as possible, not because you want to make life hard, but because its an excellent record of what people believe is an excellent and well-thought-out solution to a difficult problem. Or, for the executive summary, the less you have to assume about a protocol the better. A bit of a soap box moment, but thems my thoughts. JM Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJOtt2035930 for ; Fri, 18 Apr 2003 12:24:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IJOtpl035929 for ietf-imapext-bks; Fri, 18 Apr 2003 12:24:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJOrt2035924 for ; Fri, 18 Apr 2003 12:24:54 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4a-b-98.buf.adelphia.net [24.51.29.98]) (authenticated bits=0) by eagle.oceana.com (8.12.9/8.12.9) with ESMTP id h3IJJnTO015791 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Fri, 18 Apr 2003 15:19:49 -0400 (EDT) Message-ID: <3EA04FD7.B5D87545@oceana.com> Date: Fri, 18 Apr 2003 15:19:51 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: WATCH extension for IMAP References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> <200304180824.h3I8ODe28297@katroo.Sendmail.COM> <2147483647.1050673752@[63.163.82.24]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > > Hi Rob, > > --On Friday, April 18, 2003 1:34 PM -0400 Rob Siemborski > wrote: > > | That said, I was imagining WATCH=STATUS to work something like: > | > | a WATCH public.folder (UNSEEN) > | a OK Watching public.folder > | b NOOP > | b OK NOOP Done > | c NOOP > | * WATCH EXISTS "public.folder" > | * WATCH EXISTS "public.folder" > | * STATUS "public.folder" (UNSEEN 3) > | c OK NOOP done > > This shows up the problem that the client still has to poll via NOOP to get > results. Obviously, if a mailbox was selected, the client could use IDLE > and WATCH would come back during IDLE without the need to poll. But how > would we deal with a connection that does not have a selected mailbox? The > client could select a 'dummy' mailbox and then use idle, but wouldn't it be > better to allow IDLE outside of selected state if WATCH is present? IIRC, IDLE is already allowed in both the authenticated and selected states. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJ1Ht2035346 for ; Fri, 18 Apr 2003 12:01:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IJ1HME035345 for ietf-imapext-bks; Fri, 18 Apr 2003 12:01:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (del@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJ1Gt2035340 for ; Fri, 18 Apr 2003 12:01:16 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id MAA06653; Fri, 18 Apr 2003 12:01:07 -0700 (PDT) Date: Fri, 18 Apr 2003 11:52:06 -0700 (PDT) From: Mark Crispin Subject: RE: WATCH extension for IMAP To: johnm@teamdirection.com cc: "'Rob Siemborski'" , "'Philip Guenther'" , "'IMAP Extensions WG'" In-Reply-To: <000201c305db$40896a30$3d02a8c0@Grant> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 18 Apr 2003 11:49:31 -0700, John Milan wrote: > Why put so much effort into half measures? If everyone acknowledges > WATCH to be an issue worth solving why not *completely* solve it in the > protocol and wait for implementations to catch up. Sometimes, implementations never catch up. FTP is an excellent example. > On the other hand, if you do a partial solution, then when it becomes > technically feasible or economically viable, the protocol will not be > correct and will splinter. On the other hand, if you do a partial solution that solves the 98% case and is available now, it will be good enough *and* get useful work accomplished. We'd still be arguing IMP-IMP protocol if we refused to do anything before we solved the last 2%. Notifications are not a new idea. The idea been bandied about for years. Nothing has gotten done because people have refused to make the necessary compromises necessary to accomplish results. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IInqt2035129 for ; Fri, 18 Apr 2003 11:49:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IInquu035128 for ietf-imapext-bks; Fri, 18 Apr 2003 11:49:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from teamdirection.com (s173.n12.vds2000.com [66.84.12.173]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IInkt2035117 for ; Fri, 18 Apr 2003 11:49:47 -0700 (PDT) (envelope-from johnm@teamdirection.com) Received: from Grant ([64.122.96.14]) by teamdirection.com (8.12.9/8.11.2) with SMTP id h3IInUIg026727; Fri, 18 Apr 2003 14:49:31 -0400 Reply-To: From: "John Milan" To: "'Mark Crispin'" , "'Rob Siemborski'" Cc: "'Philip Guenther'" , "'IMAP Extensions WG'" Subject: RE: WATCH extension for IMAP Date: Fri, 18 Apr 2003 11:49:31 -0700 Organization: TeamDirection.com Message-ID: <000201c305db$40896a30$3d02a8c0@Grant> 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, Build 10.0.2627 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: > After many years, the Cyrus server still does not implement the RENAME command correctly because it is technically infeasible > for it to do it right. >> Saying that a proposal can't be improved because it is already better >> than what we currently have doesn't make a lot of sense. >It makes perfect sense if the "improvement" precludes the entire thing from being implemented. The history of Internet > protocols is littered with specifications that weren't implemented because someone would not take "no" for an answer. > Sometimes if you refuse an offer as inadequate, you end up with nothing. Why put so much effort into half measures? If everyone acknowledges WATCH to be an issue worth solving why not *completely* solve it in the protocol and wait for implementations to catch up. For instance, not implementing the RENAME command correctly hasn't stopped the progress of Cyrus' IMAP server. And if the RENAME command is correct, then when it becomes technically feasible to do it right, the protocol will survive because it was correct. On the other hand, if you do a partial solution, then when it becomes technically feasible or economically viable, the protocol will not be correct and will splinter. I see no reason why the IMAP protocol can't fully define a WATCH extension and leave server vendors to figure out what pieces they can and can't support today. John Milan Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIh6t2035013 for ; Fri, 18 Apr 2003 11:43:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IIh5NO035012 for ietf-imapext-bks; Fri, 18 Apr 2003 11:43:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (clane@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIh4t2035007 for ; Fri, 18 Apr 2003 11:43:04 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA06628; Fri, 18 Apr 2003 11:42:04 -0700 (PDT) Date: Fri, 18 Apr 2003 11:39:14 -0700 (PDT) From: Mark Crispin Subject: re: WATCH: changes to mailboxes being watched To: Cyrus Daboo cc: IMAP Extensions WG In-Reply-To: <2147483647.1050676527@[63.163.82.24]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 18 Apr 2003 14:35:27 -0400, Cyrus Daboo wrote: > How should WATCH deal with changes to mailboxes being watched? The ultra-lightweight facility that I am offering has no provisions to deal with this. All it will do is deliver an event which matches. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIZPt2034658 for ; Fri, 18 Apr 2003 11:35:25 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IIZOl8034657 for ietf-imapext-bks; Fri, 18 Apr 2003 11:35:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIZNt2034652 for ; Fri, 18 Apr 2003 11:35:23 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA14260 for ; Fri, 18 Apr 2003 14:31:58 -0400 (EDT) Date: Fri, 18 Apr 2003 14:35:27 -0400 From: Cyrus Daboo To: IMAP Extensions WG Subject: WATCH: changes to mailboxes being watched Message-ID: <2147483647.1050676527@[63.163.82.24]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: How should WATCH deal with changes to mailboxes being watched? e.g.: what happens if a watched mailbox is deleted by some other client? Should the watched connection send back a response to indicate that the watched mailbox is now gone and there will be no more watch responses for that mailbox? What about renaming a mailbox? Does the watch state 'follow' a mailbox as it is renamed? Does the watched connection send a response indicating a name change by some other client? -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIUot2034487 for ; Fri, 18 Apr 2003 11:30:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IIUo4m034485 for ietf-imapext-bks; Fri, 18 Apr 2003 11:30:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIUnt2034479 for ; Fri, 18 Apr 2003 11:30:49 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA14238; Fri, 18 Apr 2003 14:27:12 -0400 (EDT) Date: Fri, 18 Apr 2003 14:30:40 -0400 From: Cyrus Daboo To: Pete Resnick cc: Rob Siemborski , Philip Guenther , IMAP Extensions WG Subject: Re: WATCH extension for IMAP Message-ID: <2147483647.1050676240@[63.163.82.24]> In-Reply-To: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> <200304180824.h3I8ODe28297@katroo.Sendmail.COM> <2147483647.1050673752@[63.163.82.24]> X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Pete, --On Friday, April 18, 2003 1:06 PM -0500 Pete Resnick wrote: |> This shows up the problem that the client still has to poll via NOOP |> to get results. | | Why? Isn't the WATCH response going to come in as unilateral server data? If WATCH is written to require idle-like behaviour ithout a command in progress that would be fine. But the implications of that for clients needs to be spelled out. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIKmt2034038 for ; Fri, 18 Apr 2003 11:20:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IIKmTI034037 for ietf-imapext-bks; Fri, 18 Apr 2003 11:20:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (btik@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIKkt2034032 for ; Fri, 18 Apr 2003 11:20:46 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA06604; Fri, 18 Apr 2003 11:20:36 -0700 (PDT) Date: Fri, 18 Apr 2003 10:51:54 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Rob Siemborski cc: Philip Guenther , IMAP Extensions WG 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 Fri, 18 Apr 2003 13:34:19 -0400 (EDT), Rob Siemborski wrote: > Sure, but that just moves around who is looking at the cost, the fact is > that server costs aren't the ONLY ones to consider. Nevertheless, server costs can not be disregarded. After many years, the Cyrus server still does not implement the RENAME command correctly because it is technically infeasible for it to do it right. Real implementation concerns can not be disregarded just because it may be less of a concern in a particular implementation. There has to be compromise, and respect for the compromise. That is what interoperability is all about. > Saying that a proposal can't be improved because it is already better than > what we currently have doesn't make a lot of sense. It makes perfect sense if the "improvement" precludes the entire thing from being implemented. The history of Internet protocols is littered with specifications that weren't implemented because someone would not take "no" for an answer. Sometimes if you refuse an offer as inadequate, you end up with nothing. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3II6Ut2032585 for ; Fri, 18 Apr 2003 11:06:30 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3II6U7h032584 for ietf-imapext-bks; Fri, 18 Apr 2003 11:06:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3II6St2032565 for ; Fri, 18 Apr 2003 11:06:29 -0700 (PDT) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.1b1); Fri, 18 Apr 2003 13:06:30 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <2147483647.1050673752@[63.163.82.24]> References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> <200304180824.h3I8ODe28297@katroo.Sendmail.COM> <2147483647.1050673752@[63.163.82.24]> X-Mailer: Eudora [Macintosh version 6.0a15] Date: Fri, 18 Apr 2003 13:06:24 -0500 To: Cyrus Daboo From: Pete Resnick Subject: Re: WATCH extension for IMAP Cc: Rob Siemborski , Philip Guenther , IMAP Extensions WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 4/18/03 at 1:49 PM -0400, Cyrus Daboo wrote: >This shows up the problem that the client still has to poll via NOOP >to get results. Why? Isn't the WATCH response going to come in as unilateral server data? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IHnGt2031741 for ; Fri, 18 Apr 2003 10:49:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IHnG2H031740 for ietf-imapext-bks; Fri, 18 Apr 2003 10:49:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IHnFt2031733 for ; Fri, 18 Apr 2003 10:49:15 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA13855; Fri, 18 Apr 2003 13:45:44 -0400 (EDT) Date: Fri, 18 Apr 2003 13:49:12 -0400 From: Cyrus Daboo To: Rob Siemborski , Philip Guenther cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP Message-ID: <2147483647.1050673752@[63.163.82.24]> In-Reply-To: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> <200304180824.h3I8ODe28297@katroo.Sendmail.COM> X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Friday, April 18, 2003 1:34 PM -0400 Rob Siemborski wrote: | That said, I was imagining WATCH=STATUS to work something like: | | a WATCH public.folder (UNSEEN) | a OK Watching public.folder | b NOOP | b OK NOOP Done | c NOOP | * WATCH EXISTS "public.folder" | * WATCH EXISTS "public.folder" | * STATUS "public.folder" (UNSEEN 3) | c OK NOOP done This shows up the problem that the client still has to poll via NOOP to get results. Obviously, if a mailbox was selected, the client could use IDLE and WATCH would come back during IDLE without the need to poll. But how would we deal with a connection that does not have a selected mailbox? The client could select a 'dummy' mailbox and then use idle, but wouldn't it be better to allow IDLE outside of selected state if WATCH is present? -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IHYMt2031493 for ; Fri, 18 Apr 2003 10:34:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IHYMqr031492 for ietf-imapext-bks; Fri, 18 Apr 2003 10:34:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IHYKt2031485 for ; Fri, 18 Apr 2003 10:34:21 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp7.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3IHYKrh009071; Fri, 18 Apr 2003 13:34:20 -0400 Date: Fri, 18 Apr 2003 13:34:19 -0400 (EDT) From: Rob Siemborski To: Philip Guenther cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: <200304180824.h3I8ODe28297@katroo.Sendmail.COM> Message-ID: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> <200304180824.h3I8ODe28297@katroo.Sendmail.COM> 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, 18 Apr 2003, Philip Guenther wrote: > It's all a matter to explaining to the execs the costs of the tradeoffs > that they're requesting. Sure, but that just moves around who is looking at the cost, the fact is that server costs aren't the ONLY ones to consider. > Also, complaining about round-trips seems unfair, given that *right now* > the client has to poll. Unless your round-trip is on the same order as > your poll interval, Mark's lightweight proposal has a lower latency than > polling, period. Client that want STATUS information can throw a normal > STATUS command into their command pipe and still end up ahead of those > that just poll. Indeed, the client can sanely implement the batching > you proposed: "after receiving a notification, wait until N seconds have > passed *without* receiving a notification for that same mailbox, but no > more than M seconds total, before sending a STATUS command for the > mailbox". Saying that a proposal can't be improved because it is already better than what we currently have doesn't make a lot of sense. That said, I was imagining WATCH=STATUS to work something like: a WATCH public.folder (UNSEEN) a OK Watching public.folder b NOOP b OK NOOP Done c NOOP * WATCH EXISTS "public.folder" * WATCH EXISTS "public.folder" * STATUS "public.folder" (UNSEEN 3) c OK NOOP done (you could, in this case, just drop the "WATCH" responses, I have them there just to indicate more than one message arrived). But the idea was that you wouldn't queue them up based on a time interval, you'd send the status as soon as there was new mail, within the same response that would cover just the first message. Maybe the looser requirements of the POLL command are good enough, I'd like to hear from a client author though. Certainly, it is an improvement of having the client POLL explicitly though. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3I8Mjt2002990 for ; Fri, 18 Apr 2003 01:22:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3I8Mje7002989 for ietf-imapext-bks; Fri, 18 Apr 2003 01:22:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3I8Met2002983 for ; Fri, 18 Apr 2003 01:22:45 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3I8MXFd028771; Fri, 18 Apr 2003 01:22:33 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7/8.11.6) with ESMTP id h3I8ODe28297; Fri, 18 Apr 2003 01:24:13 -0700 (PDT) Message-Id: <200304180824.h3I8ODe28297@katroo.Sendmail.COM> To: Rob Siemborski Cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-reply-to: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> Date: Fri, 18 Apr 2003 01:22:45 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: >On Thu, 17 Apr 2003, Mark Crispin wrote: >>> Or how about this: Suppose any time >>> your users had to wait for the server cost you $5. >> >> This is also nonsense. Customers pay their service providers, not the >> other way around. > >Sure, but ISPs aren't the only ones providing IMAP service. IT >departments in corporations likely can't easily say to their VP, >Presidents, or CEOs "screw you, our server resources are worth more than >your time". Sure they can: "enabling that feature will result in increased server costs on the order of N thousand dollars per-year. In the best judgement of our staff, the ROI of such an expenditure is worse than that of the following other items. If you tell us to, we can, of course, move it up on our priority list, but please be aware that something else will have to give." When I was sysadmin at a college in Minnesota, we pushed back on "orders from on high" all the time. Sometimes our VP agreed with our judgement/reasoning and relaxed the mandate, other times we were told that the benefits were more than we thought (publicity, inter-department deals, prestige of the VP, whatever) and so we were the ones to give. It's all a matter to explaining to the execs the costs of the tradeoffs that they're requesting. ... ... >All that said, there is NO REASON, that a WATCH extention can not be >extensible enough serve both the "ultra-lightweight" people and the "I >want to STATUS every folder on every message arrival" people, without >requiring additional round trips. Using the same name for different actions isn't a step forward. You've already suggested that a WATCH STATUS should batch responses, while Mark has mentioned dropping notifications if the queue overflows. Those are significantly different behaviors and I would expect some servers to implement them with completely different backend mechanisms with completely different efficiencies and latencies. Calling them the same thing encourages clients to treat them the same, which skews the tradeoffs. Also, complaining about round-trips seems unfair, given that *right now* the client has to poll. Unless your round-trip is on the same order as your poll interval, Mark's lightweight proposal has a lower latency than polling, period. Client that want STATUS information can throw a normal STATUS command into their command pipe and still end up ahead of those that just poll. Indeed, the client can sanely implement the batching you proposed: "after receiving a notification, wait until N seconds have passed *without* receiving a notification for that same mailbox, but no more than M seconds total, before sending a STATUS command for the mailbox". Is that a 90% solution? If not and what client authors really want is a batched STATUS update, then perhaps we should be discussing a 'POLL' extension, say, something like: POLL Command Arguments: max-period STATUS command arguments Responses: untagged STATUS Result: OK - initial data returned, command will be performed as requested NO - too many POLLs requested or max-period too small BAD - command unknown or arguments invalid The POLL command requests that the IMAP server immediately perform the specified STATUS command and return its response. After the tagged OK, the server will continue to monitor the mailbox and unilaterally send updated STATUS responses for that mailbox. The server SHOULD NOT send an update unless the mailbox has actually been changed, though it MAY send an update for a mailbox that has change in ways not reflected in the STATUS response. [Alternatively, we could simply require it to track what it last sent and never send the exact same response twice in a row, even when the value changed but returned to their previous value before it composed the updated response.] If an update is to be sent, the server MAY delay sending it (e.g., so that the server can consolidate multiple changes into a single STATUS response), but MUST send it no later than if the server had received the specified STATUS command directly from the client 'max-period' seconds after the actual update occured. [Blech. How to phrase it that the server can't have any greater latency than a client that polled every 'max-period' seconds?] The server may limit the number of POLL commands that it will support on a single IMAP connection and may require the max-period to be no smaller than a give value. Those limits will be advertised in the capability string, blah blah blah. [What are the minimum requirements to comply? 20 concurrent POLLs, supporting a max-period of 20 seconds or more?] If a client issues a SELECT or EXAMINE command for a mailbox for which it previously issued a POLL command on the same connection, the server SHOULD suppress all STATUS updates for that mailbox for as long as the client has it selected. Example: C: A042 POLL 30 STATUS "Lists/imapext" (UNSEEN) S: * STATUS "Lists/imapext" (UNSEEN 3) S: A042 OK POLL started ...time passes; new mail arrives S: * STATUS "Lists/imapext" (UNSEEN 10) ... I tried to write the above to allow both implementations that would simply poll at the requested rate and those that would be truly notification triggered, while hopefully making the result compelling for clients either way. Philip Guenther Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLv8t2064075 for ; Thu, 17 Apr 2003 14:57:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HLv8hH064074 for ietf-imapext-bks; Thu, 17 Apr 2003 14:57:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLv7t2064069 for ; Thu, 17 Apr 2003 14:57:07 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp7.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3HLuwrh030873; Thu, 17 Apr 2003 17:56:58 -0400 Date: Thu, 17 Apr 2003 17:56:58 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Lawrence Greenfield , Cyrus Daboo , IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: Message-ID: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> 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, 17 Apr 2003, Mark Crispin wrote: > > Or how about this: Suppose any time > > your users had to wait for the server cost you $5. > > This is also nonsense. Customers pay their service providers, not the > other way around. Sure, but ISPs aren't the only ones providing IMAP service. IT departments in corporations likely can't easily say to their VP, Presidents, or CEOs "screw you, our server resources are worth more than your time". > Wait a second. You are implying that it is "frequent" that people will be > reading mail with more than one computer simultaneously. > > Once again, how frequent? Well, for me (using pine), all the time, actually. In fact, I'll often find myself with several pine sessions on the same machine. > How frequent is it that a user is distraught that one of his simultaneous > running clients isn't showing a new mail messages that he has already read > on his other simultaneously running client? If I accidently leave pine connected to a folder at work (happens almost every day, to various folders), then go home, pine at home won't notice that new mail has arrived in that folder when I hit "tab" to scan through my incoming folders, because the \Recent flags are being unset by the session at work. I haven't actually read (or even been notified of) the new messages. Sure "doctor, it hurts when I do this!", but it's an example of a very real problem with \Recent semantics. > The minimum definition of "interesting" in this context is defined in the > specification. RFC3501>>> \Marked The mailbox has been marked "interesting" by the server; the mailbox probably contains messages that have been added since the last time the mailbox was selected. <<< I don't see a minimum requirement. I see, at best, a suggestion of what "interesting" might mean. > > With this sort of specification, it is not surprising that clients > > choose not to use \Marked for anything. > > I claim that it's because of lazy programmers who only use fast > connections . Nevermind the fact that servers are allowed to not return \Marked or \Unmarked at all, if they feel like it, making the feature basically useless in the general case anyway. All that said, there is NO REASON, that a WATCH extention can not be extensible enough serve both the "ultra-lightweight" people and the "I want to STATUS every folder on every message arrival" people, without requiring additional round trips. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLXvt2063150 for ; Thu, 17 Apr 2003 14:33:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HLXvF6063149 for ietf-imapext-bks; Thu, 17 Apr 2003 14:33:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLXut2063144 for ; Thu, 17 Apr 2003 14:33:56 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3HLXsTc024869; Thu, 17 Apr 2003 14:33:54 -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+UW03.04/8.12.1+UW02.12) with ESMTP id h3HLXs8H029788 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Apr 2003 14:33:54 -0700 Date: Thu, 17 Apr 2003 14:33:54 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lawrence Greenfield cc: Cyrus Daboo , IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> Message-ID: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> 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 Thu, 17 Apr 2003, Lawrence Greenfield wrote: > Suppose your ISP had a charging system such that LIST was free, but each > STATUS cost $.05 (.05 Euros, 5 yen, take your pick...). Would you do things > differently? > Suppose your ISP had a charging system such that LIST responses were > 0.05 cents and STATUS was free. That's nonsense. LIST can never be more expensive than STATUS. I remind you; ISPs are disabling SEARCH in IMAP because they think it is too expensive. > Or how about this: Suppose any time > your users had to wait for the server cost you $5. This is also nonsense. Customers pay their service providers, not the other way around. > And this is one of the reasons that we're making LISTEXT be able to > return STATUS responses. Which I feel to be a serious mistake. Tell me, when is Cyrus going to implement RENAME according to the specification and remove its bogus NO_ATOMIC_RENAME capability? > True, the multiple clients connected to the same mailbox case is a problem. > But is that the 99% case? > 99% case? Of course not. A very frequent thing? Yes. How much is "very frequent"? 1% of the time? .001% of the time? > Many people read > e-mail with more than one computer. Will it become more frequent? I > hope so---and many many people have cell phones. Wait a second. You are implying that it is "frequent" that people will be reading mail with more than one computer simultaneously. Once again, how frequent? How frequent is it that a user is distraught that one of his simultaneous running clients isn't showing a new mail messages that he has already read on his other simultaneously running client? The day that email spam hits cell phones en masse will be the day that we see an end to that particular silliness, particularly in the US with its "cell phone user always pays" pricing model and carriers which can't even provide reliable service in the middle of a city. > Since LIST \Marked isn't required and isn't even well specified. (My > server could consider any message containing the word "penguin" > interesting---not very useful to anyone but me, but _I_ find those > messages "interesting".) The minimum definition of "interesting" in this context is defined in the specification. It is not implausible that there might be an IMAP extension to add "containing the word penguin" to the definition of "interesting". > With this sort of specification, it is not surprising that clients > choose not to use \Marked for anything. I claim that it's because of lazy programmers who only use fast connections . -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HKHRt2059840 for ; Thu, 17 Apr 2003 13:17:27 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HKHRHf059839 for ietf-imapext-bks; Thu, 17 Apr 2003 13:17:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HKHPt2059833 for ; Thu, 17 Apr 2003 13:17:25 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id AD6C75E017F5; Thu, 17 Apr 2003 23:17:26 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: IMAP Extensions WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050610646.16342.229.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 23:17:26 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 21:54, Mark Crispin wrote: > On 17 Apr 2003 21:46:18 +0300, Timo Sirainen wrote: > > I haven't actually thought of a single good usage of \Marked flag. It > > pretty much means that there's probably \Recent messages in the mailbox. > > Consider this thought exercise. > > Suppose your ISP had a charging system such that LIST was free, but each > STATUS cost $.05 (.05 Euros, 5 yen, take your pick...). Would you do things > differently? Maybe. But since it currently doesn't cost more than server resources, good user interface is more important to me as a user (and as admin for server with only a couple of users). > Wouldn't you do a LIST to determine whether or not you should do a STATUS? > After all, you can do a wildcard with the LIST. > > True, the multiple clients connected to the same mailbox case is a problem. > But is that the 99% case? I think that's one of the best features in IMAP. I use it, so checking only \Marked mailboxes wouldn't be enough for me. If the choice is between using more server resources and not necessarily seeing new message for hours or even days after it's received, I choose the resource consumption any time. Of course, client could do LIST often and ask STATUS for \Marked folders immediately, but still ask STATUS for non-marked folders at least once every n minutes. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJwEt2059276 for ; Thu, 17 Apr 2003 12:58:14 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HJwEjJ059274 for ietf-imapext-bks; Thu, 17 Apr 2003 12:58:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJwCt2059242 for ; Thu, 17 Apr 2003 12:58:12 -0700 (PDT) (envelope-from leg+@andrew.cmu.edu) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3HJw4df008659; Thu, 17 Apr 2003 15:58:04 -0400 Date: Thu, 17 Apr 2003 15:58:04 -0400 Message-Id: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Cyrus Daboo , Mark Crispin Cc: IMAP Extensions WG , Mark Crispin In-reply-to: Subject: Re: WATCH extension for IMAP References: User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Thu, 17 Apr 2003 11:54:55 -0700 (PDT) From: Mark Crispin [...] Suppose your ISP had a charging system such that LIST was free, but each STATUS cost $.05 (.05 Euros, 5 yen, take your pick...). Would you do things differently? Suppose your ISP had a charging system such that LIST responses were 0.05 cents and STATUS was free. Or how about this: Suppose any time your users had to wait for the server cost you $5. Wouldn't you prefetch as much data as possible? Wouldn't you do a LIST to determine whether or not you should do a STATUS? After all, you can do a wildcard with the LIST. And this is one of the reasons that we're making LISTEXT be able to return STATUS responses. True, the multiple clients connected to the same mailbox case is a problem. But is that the 99% case? 99% case? Of course not. A very frequent thing? Yes. Many people read e-mail with more than one computer. Will it become more frequent? I hope so---and many many people have cell phones. On Thu, 17 Apr 2003 21:01:25 +0200, Simon Josefsson wrote: > Some clients like to only display the mailbox that have unread > messages on the screen. So to find out which of the 1800 mailboxes to > display, the client sends STATUS for all of them. Such a client should use the LIST \Marked flag and not STATUS. Since LIST \Marked isn't required and isn't even well specified. (My server could consider any message containing the word "penguin" interesting---not very useful to anyone but me, but _I_ find those messages "interesting".) With this sort of specification, it is not surprising that clients choose not to use \Marked for anything. It is important that any notification mechanism ("light weight" or not) has well defined semantics that actually match what clients are interested in. Larry Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJawt2058699 for ; Thu, 17 Apr 2003 12:36:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HJaw3u058698 for ietf-imapext-bks; Thu, 17 Apr 2003 12:36:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJaut2058692 for ; Thu, 17 Apr 2003 12:36:56 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3HJanXK031775 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Apr 2003 21:36:50 +0200 To: Mark Crispin Cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP X-Payment: hashcash 1.2 0:030417:MRC@CAC.Washington.EDU:33dd8351ec3be070 X-Hashcash: 0:030417:MRC@CAC.Washington.EDU:33dd8351ec3be070 X-Payment: hashcash 1.2 0:030417:ietf-imapext@imc.org:46c44f70318a08f7 X-Hashcash: 0:030417:ietf-imapext@imc.org:46c44f70318a08f7 From: Simon Josefsson Date: Thu, 17 Apr 2003 21:36:49 +0200 In-Reply-To: (Mark Crispin's message of "Thu, 17 Apr 2003 11:54:55 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Thu, 17 Apr 2003 21:01:25 +0200, Simon Josefsson wrote: >> Some clients like to only display the mailbox that have unread >> messages on the screen. So to find out which of the 1800 mailboxes to >> display, the client sends STATUS for all of them. > > Such a client should use the LIST \Marked flag and not STATUS. No, LIST \Marked means the mailbox contain "interesting" messages. "Interesting" (recent) and unread are not the same thing, and some users prefer to display only mailboxes with unread messages, so the client must send STATUS for all of them. See RFC 3501: The LIST command SHOULD return its data quickly, without undue delay. For example, it SHOULD NOT go to excess trouble to calculate the \Marked or \Unmarked status or perform other processing; if each name requires 1 second of processing, then a list of 1200 names would take 20 minutes! ... \Marked The mailbox has been marked "interesting" by the server; the mailbox probably contains messages that have been added since the last time the mailbox was selected. ... If it is not feasible for the server to determine whether or not the mailbox is "interesting", or if the name is a \Noselect name, the server SHOULD NOT send either \Marked or \Unmarked. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJ9kt2057920 for ; Thu, 17 Apr 2003 12:09:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HJ9kCS057919 for ietf-imapext-bks; Thu, 17 Apr 2003 12:09:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (mtk@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJ9it2057914 for ; Thu, 17 Apr 2003 12:09:45 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id MAA04514; Thu, 17 Apr 2003 12:09:38 -0700 (PDT) Date: Thu, 17 Apr 2003 11:54:55 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Cyrus Daboo cc: Mark Crispin , IMAP Extensions WG In-Reply-To: <2147483647.1050590644@[63.163.82.24]> 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, 17 Apr 2003 14:44:04 -0400, Cyrus Daboo wrote: > \Marked is useful for finding out which mailboxes have new mail at the > start of a session (i.e. when LIST is done) but to keep that information up > to date, the client would have to do some form of LIST polling, at which > point you might just as well use status. On 17 Apr 2003 21:46:18 +0300, Timo Sirainen wrote: > I haven't actually thought of a single good usage of \Marked flag. It > pretty much means that there's probably \Recent messages in the mailbox. Consider this thought exercise. Suppose your ISP had a charging system such that LIST was free, but each STATUS cost $.05 (.05 Euros, 5 yen, take your pick...). Would you do things differently? Wouldn't you do a LIST to determine whether or not you should do a STATUS? After all, you can do a wildcard with the LIST. True, the multiple clients connected to the same mailbox case is a problem. But is that the 99% case? I suspect that the 99.99% case of multiple clients connected to the same mailbox is the *same* client with multiple sessions to the same mailbox. In that case, the client is perfectly capable of resolving the confusion itself. On Thu, 17 Apr 2003 21:01:25 +0200, Simon Josefsson wrote: > Some clients like to only display the mailbox that have unread > messages on the screen. So to find out which of the 1800 mailboxes to > display, the client sends STATUS for all of them. Such a client should use the LIST \Marked flag and not STATUS. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJ5It2057809 for ; Thu, 17 Apr 2003 12:05:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HJ5IaB057808 for ietf-imapext-bks; Thu, 17 Apr 2003 12:05:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJ5Gt2057803 for ; Thu, 17 Apr 2003 12:05:17 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3HJ58XK031114 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Apr 2003 21:05:09 +0200 To: Mark Crispin Cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP X-Payment: hashcash 1.2 0:030417:mrc@CAC.Washington.EDU:263af9c1b5e0faf9 X-Hashcash: 0:030417:mrc@CAC.Washington.EDU:263af9c1b5e0faf9 X-Payment: hashcash 1.2 0:030417:ietf-imapext@imc.org:f3ea133182faec6a X-Hashcash: 0:030417:ietf-imapext@imc.org:f3ea133182faec6a From: Simon Josefsson Date: Thu, 17 Apr 2003 21:05:08 +0200 In-Reply-To: (Mark Crispin's message of "Thu, 17 Apr 2003 09:39:53 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > The question is: > > If there was an ultra-lightweight notification mechanism available very > soon, would you use it? > OR > Do you say, "No, I can not make use of an ultra-lightweight notification > facility. I'd rather wait until LEMONADE finishes its work, and then wait > for that work to be implemented. Until then, I'd rather have nothing at > all." The charter for LEMONADE does not make it clear (to me, at least) that the message notification protocol they will develop is an IMAP extension. A notification protocol is not mentioned in the milestones of the group either. And no drafts. > I'm trying to ascertain if it's worth the effort. Personally, I believe > that while it isn't ideal, it's good enough. Since it appears (at best) unclear (to me) that LEMONADE will ever specify a IMAP notification facility with the bells and whistles I'd want, I don't think an effort in this direction would hurt. If if you changed your proposal into also providing (at least) the uidvalidity of the mailbox and uid of the new message, I'm positively for it. It doesn't appear like it would cost much to implement this change. If LEMONADE is on track towards creating a feature rich notification IMAP extension, I think it is a mistake to push your proposal now as it would result in two only slightly different solutions to the same problem. Just my .2 SEK. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJ1st2057659 for ; Thu, 17 Apr 2003 12:01:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HJ1scn057658 for ietf-imapext-bks; Thu, 17 Apr 2003 12:01:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJ1qt2057652 for ; Thu, 17 Apr 2003 12:01:53 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3HJ1PXK031006 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Apr 2003 21:01:28 +0200 To: Mark Crispin Cc: Cyrus Daboo , Timo Sirainen , Rob Siemborski , IMAP Extensions WG Subject: Re: WATCH extension for IMAP X-Payment: hashcash 1.2 0:030417:MRC@CAC.Washington.EDU:acff93aeeba95b3c X-Hashcash: 0:030417:MRC@CAC.Washington.EDU:acff93aeeba95b3c X-Payment: hashcash 1.2 0:030417:daboo@cyrusoft.com:e2265727f847a7e5 X-Hashcash: 0:030417:daboo@cyrusoft.com:e2265727f847a7e5 X-Payment: hashcash 1.2 0:030417:tss@iki.fi:8f275944499686e6 X-Hashcash: 0:030417:tss@iki.fi:8f275944499686e6 X-Payment: hashcash 1.2 0:030417:rjs3@andrew.cmu.edu:23a2a44a31328c00 X-Hashcash: 0:030417:rjs3@andrew.cmu.edu:23a2a44a31328c00 X-Payment: hashcash 1.2 0:030417:ietf-imapext@imc.org:acffedc72037dbdd X-Hashcash: 0:030417:ietf-imapext@imc.org:acffedc72037dbdd From: Simon Josefsson Date: Thu, 17 Apr 2003 21:01:25 +0200 In-Reply-To: (Mark Crispin's message of "Thu, 17 Apr 2003 11:26:02 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Thu, 17 Apr 2003 14:15:10 -0400, Cyrus Daboo wrote: >> STATUS is often used to show a count of the total number of messages and >> number of unseen messages in a 'closed' mailbox. > > I understand why people want/like that. But why do STATUS of 1800 mailboxes > when only 20 are currently visible on the screen? Some clients like to only display the mailbox that have unread messages on the screen. So to find out which of the 1800 mailboxes to display, the client sends STATUS for all of them. The client could also be a batch client, that slurps in all information it could possibly need, in order to be fast once it gotten past the slow startup, instead of being slightly slow (depending on the server) all the time. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HItCt2057364 for ; Thu, 17 Apr 2003 11:55:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HItCtH057363 for ietf-imapext-bks; Thu, 17 Apr 2003 11:55:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (mccabe@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HItAt2057358 for ; Thu, 17 Apr 2003 11:55:10 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA04484; Thu, 17 Apr 2003 11:54:45 -0700 (PDT) Date: Thu, 17 Apr 2003 11:42:41 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Cyrus Daboo cc: Rob Siemborski , IMAP Extensions WG In-Reply-To: <2147483647.1050590421@[63.163.82.24]> 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, 17 Apr 2003 14:40:21 -0400, Cyrus Daboo wrote: > You need to think about GUI clients that may have multiple views on screen > at the same time, all being updated and maintained as server state changes. I mentioned that possibility. On the other hand, there's only so much screen real estate. Most users do not have a screen large enough to display the message counts for 1800 mailboxes, and display an index of messages, a message being read, and a message being composed. Unfortunately, I see clients behave as if this is the user's display environment, the client has unlimited network bandwidth to the server, and the server has unlimited resources to respond to client demands. I see clients behave this way when the user is on a dialup IP connection from a laptop with a 14" screen. Much of the "IMAP is chatty" and "IMAP is slow" and "IMAP is resource intensive" folklore comes out of such experience. I'm not saying that Mulberry does this. But there are clients which do so. One of my ways of judging a "quality IMAP client" is the user experience and how much it costs to read your mail over roaming CDPD (at $.05/kilobyte!). LEMONADE should be an eye-opener. A lot about LEMONADE frightens me, but overall I think that it is a good thing that LEMONADE has happened. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIojt2057163 for ; Thu, 17 Apr 2003 11:50:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIojGQ057162 for ietf-imapext-bks; Thu, 17 Apr 2003 11:50:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIoit2057143 for ; Thu, 17 Apr 2003 11:50:44 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.9/8.12.9) with ESMTP id h3HInxTN020943; Thu, 17 Apr 2003 14:49:59 -0400 (EDT) Message-ID: <3E9EF813.5A0C0F39@oceana.com> Date: Thu, 17 Apr 2003 14:53:07 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: Rob Siemborski , Timo Sirainen , Cyrus Daboo , IMAP Extensions WG Subject: Re: WATCH extension for IMAP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > > On Thu, 17 Apr 2003 14:01:32 -0400 (EDT), Rob Siemborski wrote: > > Of course, if the user has recieved new mail in 1800 separate mailboxes, > > in a notification period, I'd say the server is under a pretty high load > > already. > > I wasn't talking about. I was talking about client startup. > > Does the client do 1800 STATUS commands when the user first goes into the list > of mailboxes? If so, I think that client has a problem. > > > I'm not sure if its better for the client to say on per session basis > > "tell me about mailboxes x, y, z, a, b, c" or just let the client say > > "tell me about my subscribed mailboxes". I think I like the former, > > actually. > > So do we! > > Originally, that was what subscribed mailboxes were supposed to do, but the > abuse of the subscription feature by certain other clients put an end to that > idea. > > In effect, it is a type of subscription; it's just kept in client > configuration instead of by the server. That keeps it safe from the > aforementioned certain other clients, but on the other hand other clients > won't inherit that information either. This might be a good mailbox annotation, eg: /mailbox/{}/watch (or whatever the syntax ends up being) -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIoYt2057141 for ; Thu, 17 Apr 2003 11:50:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIoYY6057140 for ietf-imapext-bks; Thu, 17 Apr 2003 11:50:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIoVt2057135 for ; Thu, 17 Apr 2003 11:50:32 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id D598F5E017F5; Thu, 17 Apr 2003 21:50:32 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: Rob Siemborski , Cyrus Daboo , IMAP Extensions WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050605432.16343.194.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 21:50:32 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 21:36, Mark Crispin wrote: > What I see is neither of the above. > > I see clients doing LIST "" * followed by STATUS of each returned name, at > startup. I see this repeated at periodic (obviously polling) intervals. > > The resulting experience is not good for the server or the user. Yeah, most IMAP clients suck. BTW. I wrote this some weeks ago: http://dovecot.procontrol.fi/imap-client-coding-howto.html Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HInCt2057071 for ; Thu, 17 Apr 2003 11:49:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HInC9Z057070 for ietf-imapext-bks; Thu, 17 Apr 2003 11:49:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from teamdirection.com (s173.n12.vds2000.com [66.84.12.173]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HInAt2057062 for ; Thu, 17 Apr 2003 11:49:11 -0700 (PDT) (envelope-from johnm@teamdirection.com) Received: from grendel (12-228-90-244.client.attbi.com [12.228.90.244]) by teamdirection.com (8.12.9/8.11.2) with SMTP id h3HIn0d8030689; Thu, 17 Apr 2003 14:49:00 -0400 From: "John Milan" To: "Mark Crispin" Cc: "IMAP Extensions WG" Subject: RE: WATCH extension for IMAP Date: Thu, 17 Apr 2003 11:57:37 -0700 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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > That is, in your "WATCH new mail where from = myboss@company.com" example, you > would get all new mail events, and locally filter out the ones that are not > from "myboss@company.com". Hmmm... But I thought one of the features of the IMAP protocol was 'smart' remote access. For instance, if I'm on a slow connection, I don't necessarily have to get all my mail messages. It seems to me that if I am in a connection speed challeged environment, I'd rather have the server filter out the messages I'm watching for than have to download all new messages and filter locally. Especially if I have a hotmail account with lots of spam. Such an environment might have a powerful server, but many remote access users, perhaps each using a dialup connection-- like the travelling salesman in his hotel room. They might be very interested in what their boss has to say, but not the funny movies their friends sent to them. I suppose just filtering off the message headers takes care of the above example, but then you can never really do content evaluation-- to costly to send everything across the wire. This just seems like building a problem into the protocol, especially when mail clients 'expect' this behavior in the future. John Milan Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIkJt2056984 for ; Thu, 17 Apr 2003 11:46:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIkJJY056983 for ietf-imapext-bks; Thu, 17 Apr 2003 11:46:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIkHt2056976 for ; Thu, 17 Apr 2003 11:46:18 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id CCBCD5E017F5; Thu, 17 Apr 2003 21:46:18 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: Cyrus Daboo , Rob Siemborski , IMAP Extensions WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050605178.16343.188.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 21:46:18 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 21:26, Mark Crispin wrote: > > Just indicating which have > > new mail is not enough - after all that is what \Marked does in LIST and > > very few implementations have bothered to use it. > > I never understood why this is the case. I haven't actually thought of a single good usage of \Marked flag. It pretty much means that there's probably \Recent messages in the mailbox. Those are another thing which I haven't found very useful. In single client case I guess it works well enough, but as soon as you have multiple clients connected to same mailbox, the behaviour gets pretty much random. Just because the client at work office noticed the mail before the client at home, doesn't mean that I wouldn't want to get notification of it when I'm at home. \Marked flag tells only that there's a folder where you very likely find new mail, but a client can't make any assumption if non-marked folders have new mail. So it ends up sending STATUS for all of them anyway. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIi5t2056862 for ; Thu, 17 Apr 2003 11:44:05 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIi59Q056861 for ietf-imapext-bks; Thu, 17 Apr 2003 11:44:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIi3t2056856 for ; Thu, 17 Apr 2003 11:44:04 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA06185; Thu, 17 Apr 2003 14:40:35 -0400 (EDT) Date: Thu, 17 Apr 2003 14:44:04 -0400 From: Cyrus Daboo To: Mark Crispin cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP Message-ID: <2147483647.1050590644@[63.163.82.24]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Thursday, April 17, 2003 11:26 AM -0700 Mark Crispin wrote: |> Just indicating which have |> new mail is not enough - after all that is what \Marked does in LIST and |> very few implementations have bothered to use it. | | I never understood why this is the case. \Marked is useful for finding out which mailboxes have new mail at the start of a session (i.e. when LIST is done) but to keep that information up to date, the client would have to do some form of LIST polling, at which point you might just as well use status. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIgkt2056832 for ; Thu, 17 Apr 2003 11:42:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIgkoh056831 for ietf-imapext-bks; Thu, 17 Apr 2003 11:42:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (lamarth@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIgjt2056824 for ; Thu, 17 Apr 2003 11:42:45 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA04465; Thu, 17 Apr 2003 11:42:34 -0700 (PDT) Date: Thu, 17 Apr 2003 11:36:58 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Rob Siemborski cc: Timo Sirainen , Cyrus Daboo , IMAP Extensions WG 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 Thu, 17 Apr 2003 14:31:10 -0400 (EDT), Rob Siemborski wrote: > I suppose that depends on your goal. If you assume STATUS is going to > take a long time, then from a user experience perspective it makes sense > to do them when the network connection is otherwise idle. > > If, on the other hand, you are solely concerned with overall server > performance, then you probably want this to be as lazy as possible. What I see is neither of the above. I see clients doing LIST "" * followed by STATUS of each returned name, at startup. I see this repeated at periodic (obviously polling) intervals. The resulting experience is not good for the server or the user. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIeNt2056775 for ; Thu, 17 Apr 2003 11:40:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIeN3l056774 for ietf-imapext-bks; Thu, 17 Apr 2003 11:40:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIeMt2056769 for ; Thu, 17 Apr 2003 11:40:22 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA06137; Thu, 17 Apr 2003 14:36:52 -0400 (EDT) Date: Thu, 17 Apr 2003 14:40:21 -0400 From: Cyrus Daboo To: Mark Crispin , Rob Siemborski cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP Message-ID: <2147483647.1050590421@[63.163.82.24]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Thursday, April 17, 2003 11:03 AM -0700 Mark Crispin wrote: |> Of course, if the user has recieved new mail in 1800 separate mailboxes, |> in a notification period, I'd say the server is under a pretty high load |> already. | | I wasn't talking about. I was talking about client startup. | | Does the client do 1800 STATUS commands when the user first goes into the | list of mailboxes? If so, I think that client has a problem. That depends on how the client is implemented. We do all STATUS work via a background thread so it won't interfere with the user. And yes, the user could easily set things up so that they do 1800 STATUS commands. We have many users that like to have message counts on their entire personal hierarchy appear on startup - so those can all get checked once, and then a different (smaller) set checked at varying intervals after that. |> I'm not sure if its better for the client to say on per session basis |> "tell me about mailboxes x, y, z, a, b, c" or just let the client say |> "tell me about my subscribed mailboxes". I think I like the former, |> actually. | | So do we! | | Originally, that was what subscribed mailboxes were supposed to do, but | the abuse of the subscription feature by certain other clients put an end | to that idea. | | In effect, it is a type of subscription; it's just kept in client | configuration instead of by the server. That keeps it safe from the | aforementioned certain other clients, but on the other hand other clients | won't inherit that information either. Yes - subscribe has been abused :-( Note that ANNOTATEMORE does have an annotation that's meant to be used to indicate which mailboxes should be checked for new mail, so hopefully co-operating clients can use that once its implemented. |> But if the client author knows they are going to do a status for every |> notification anyway (or every set of notifications on a mailbox), then |> why cost them the additional round trip? | | Perhaps to discourage clients from doing that? Perhaps to encourage | innovative thinking that would avoid unnecessary STATUS commands? | | One very obvious thing would be to defer doing a STATUS command until the | user is in the list of mailboxes screen. It's rather silly to do 50 | STATUS commands on a mailbox while the user's screen is busy in composing | a message. | | This wouldn't hold for a client that always shows a list of mailboxes, | but the general idea still applies. If the data isn't visible on the | user's screen (the client is in a different mode, or that particular data | is scrolled out of the visible view, or even if another window overlaps), | then there's no need to update it until it becomes visible. | You need to think about GUI clients that may have multiple views on screen at the same time, all being updated and maintained as server state changes. All that can be done in the background without interfering with the user's current focus. Plus, whether the mailbox is on screen or not is not relevant as the new mail check might bring it on screen if it has new mail or require some other form of notification that does not depend on the visibility of the mailbox itself (e.g. an audible text-to-speech alert that reads the name of the mailbox and the number of new messages). All of this is very much a client implementation issue. Providing a way to get status automatically will benefit a number of clients that are already doing expensive (polled) status calls. For low volume status changes, WATCH=STATUS will be a big win. For the high volume case, we need to have recommendations or limits on what should be done. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIcMt2056703 for ; Thu, 17 Apr 2003 11:38:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIcLLI056702 for ietf-imapext-bks; Thu, 17 Apr 2003 11:38:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIcKt2056694 for ; Thu, 17 Apr 2003 11:38:21 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA06117; Thu, 17 Apr 2003 14:32:53 -0400 (EDT) Date: Thu, 17 Apr 2003 14:36:22 -0400 From: Cyrus Daboo To: Rob Siemborski , John Milan cc: Mark Crispin , IMAP Extensions WG Subject: RE: WATCH extension for IMAP Message-ID: <2147483647.1050590182@[63.163.82.24]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Thursday, April 17, 2003 2:22 PM -0400 Rob Siemborski wrote: |> I'm thinking of a WATCH much like mail filtering. | | I suspect it would be possible to use the sieve notify extention to feed | this in some way. Indeed we could define WATCH=SIEVENOTIFY and have * WATCH responses that return the sieve data. However, this would require a WATCH command without a mailbox argument since sieve notifications are not tied to mailboxes. Using the empty string as an argument to WATCH in that case would make sense (and would mirror the syntax of server vs mailbox annotations in the next ANNOTATEMORE draft). | I think I'd rather see the IMAP side of this stay simple (but | extensible, if more features are desired later). Agreed - WATCH=XXX allows us to do that. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIaot2056588 for ; Thu, 17 Apr 2003 11:36:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIao0n056587 for ietf-imapext-bks; Thu, 17 Apr 2003 11:36:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (jzs@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIamt2056581 for ; Thu, 17 Apr 2003 11:36:48 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA04455; Thu, 17 Apr 2003 11:36:36 -0700 (PDT) Date: Thu, 17 Apr 2003 11:26:02 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Cyrus Daboo cc: Timo Sirainen , Rob Siemborski , IMAP Extensions WG In-Reply-To: <2147483647.1050588910@[63.163.82.24]> 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, 17 Apr 2003 14:15:10 -0400, Cyrus Daboo wrote: > STATUS is often used to show a count of the total number of messages and > number of unseen messages in a 'closed' mailbox. I understand why people want/like that. But why do STATUS of 1800 mailboxes when only 20 are currently visible on the screen? > Just indicating which have > new mail is not enough - after all that is what \Marked does in LIST and > very few implementations have bothered to use it. I never understood why this is the case. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIZSt2056542 for ; Thu, 17 Apr 2003 11:35:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIZSPD056541 for ietf-imapext-bks; Thu, 17 Apr 2003 11:35:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIZQt2056534 for ; Thu, 17 Apr 2003 11:35:27 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id D97D25E017F5; Thu, 17 Apr 2003 21:35:27 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: Rob Siemborski , Cyrus Daboo , IMAP Extensions WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050604527.16342.180.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 21:35:27 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 21:03, Mark Crispin wrote: > On Thu, 17 Apr 2003 14:01:32 -0400 (EDT), Rob Siemborski wrote: > > Of course, if the user has recieved new mail in 1800 separate mailboxes, > > in a notification period, I'd say the server is under a pretty high load > > already. > > I wasn't talking about. I was talking about client startup. > > Does the client do 1800 STATUS commands when the user first goes into the list > of mailboxes? If so, I think that client has a problem. Optimally it would send STATUS only for those mailboxes that are visible in screen. Good enough solution would be to check only the mailboxes that can become visible by scrolling (similiar to LIST "" % usage). Currently Evolution seems to do it for all subscribed folders if "check mail in all folders" flag is set. I'm not sure if it does it for all folders if I uncheck "show only subscribed folders" flag. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIVOt2056301 for ; Thu, 17 Apr 2003 11:31:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIVOGp056300 for ietf-imapext-bks; Thu, 17 Apr 2003 11:31:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIVNt2056290 for ; Thu, 17 Apr 2003 11:31:23 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp7.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3HIVArh015329; Thu, 17 Apr 2003 14:31:10 -0400 Date: Thu, 17 Apr 2003 14:31:10 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Timo Sirainen , Cyrus Daboo , IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: Message-ID: References: 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, 17 Apr 2003, Mark Crispin wrote: > One very obvious thing would be to defer doing a STATUS command until > the user is in the list of mailboxes screen. It's rather silly to do 50 > STATUS commands on a mailbox while the user's screen is busy in > composing a message. I suppose that depends on your goal. If you assume STATUS is going to take a long time, then from a user experience perspective it makes sense to do them when the network connection is otherwise idle. If, on the other hand, you are solely concerned with overall server performance, then you probably want this to be as lazy as possible. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIMSt2056083 for ; Thu, 17 Apr 2003 11:22:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIMS0h056082 for ietf-imapext-bks; Thu, 17 Apr 2003 11:22:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIMQt2056072 for ; Thu, 17 Apr 2003 11:22:27 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3HIMNfg005851; Thu, 17 Apr 2003 14:22:23 -0400 Date: Thu, 17 Apr 2003 14:22:22 -0400 (EDT) From: Rob Siemborski To: John Milan cc: Mark Crispin , IMAP Extensions WG Subject: RE: WATCH extension for IMAP In-Reply-To: Message-ID: References: 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, 17 Apr 2003, John Milan wrote: > Taking advantage of at least the RFC headers as watchable data. That way, no > matter how many folders I might have, I'll get that important message from > the boss. More aggressive implementations could probably extend the > expression matching to the message body. > > I'm thinking of a WATCH much like mail filtering. I suspect it would be possible to use the sieve notify extention to feed this in some way. I think I'd rather see the IMAP side of this stay simple (but extensible, if more features are desired later). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIFLt2055956 for ; Thu, 17 Apr 2003 11:15:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIFLil055955 for ietf-imapext-bks; Thu, 17 Apr 2003 11:15:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIFKt2055950 for ; Thu, 17 Apr 2003 11:15:20 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA06010; Thu, 17 Apr 2003 14:11:42 -0400 (EDT) Date: Thu, 17 Apr 2003 14:15:10 -0400 From: Cyrus Daboo To: Mark Crispin , Timo Sirainen cc: Rob Siemborski , IMAP Extensions WG Subject: Re: WATCH extension for IMAP Message-ID: <2147483647.1050588910@[63.163.82.24]> In-Reply-To: References: <1050545570.16338.112.camel@hurina> <1806305761.1050575601@[63.163.82.24]> <1050597813.16342.153.camel@hurina> X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Thursday, April 17, 2003 9:47 AM -0700 Mark Crispin wrote: | After all, what's the point of STATUS, other than to see if there is new | messages in the mailbox? In this case, we *know* that that are new | messages! STATUS is often used to show a count of the total number of messages and number of unseen messages in a 'closed' mailbox. Just indicating which have new mail is not enough - after all that is what \Marked does in LIST and very few implementations have bothered to use it. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HID9t2055905 for ; Thu, 17 Apr 2003 11:13:09 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HID9kB055904 for ietf-imapext-bks; Thu, 17 Apr 2003 11:13:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (jgr@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HID7t2055899 for ; Thu, 17 Apr 2003 11:13:08 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA04436; Thu, 17 Apr 2003 11:12:57 -0700 (PDT) Date: Thu, 17 Apr 2003 11:03:29 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Rob Siemborski cc: Timo Sirainen , Cyrus Daboo , IMAP Extensions WG 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 Thu, 17 Apr 2003 14:01:32 -0400 (EDT), Rob Siemborski wrote: > Of course, if the user has recieved new mail in 1800 separate mailboxes, > in a notification period, I'd say the server is under a pretty high load > already. I wasn't talking about. I was talking about client startup. Does the client do 1800 STATUS commands when the user first goes into the list of mailboxes? If so, I think that client has a problem. > I'm not sure if its better for the client to say on per session basis > "tell me about mailboxes x, y, z, a, b, c" or just let the client say > "tell me about my subscribed mailboxes". I think I like the former, > actually. So do we! Originally, that was what subscribed mailboxes were supposed to do, but the abuse of the subscription feature by certain other clients put an end to that idea. In effect, it is a type of subscription; it's just kept in client configuration instead of by the server. That keeps it safe from the aforementioned certain other clients, but on the other hand other clients won't inherit that information either. > But if the client author knows they are going to do a status for every > notification anyway (or every set of notifications on a mailbox), then why > cost them the additional round trip? Perhaps to discourage clients from doing that? Perhaps to encourage innovative thinking that would avoid unnecessary STATUS commands? One very obvious thing would be to defer doing a STATUS command until the user is in the list of mailboxes screen. It's rather silly to do 50 STATUS commands on a mailbox while the user's screen is busy in composing a message. This wouldn't hold for a client that always shows a list of mailboxes, but the general idea still applies. If the data isn't visible on the user's screen (the client is in a different mode, or that particular data is scrolled out of the visible view, or even if another window overlaps), then there's no need to update it until it becomes visible. > (though I > could see WATCH=BIFF as just being WATCH=STATUS with no status fields > being returned). I agree with this observation. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HI3Yt2055605 for ; Thu, 17 Apr 2003 11:03:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HI3YiK055604 for ietf-imapext-bks; Thu, 17 Apr 2003 11:03:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (hik@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HI3St2055596 for ; Thu, 17 Apr 2003 11:03:33 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA04427; Thu, 17 Apr 2003 11:03:23 -0700 (PDT) Date: Thu, 17 Apr 2003 10:52:57 -0700 (PDT) From: Mark Crispin Subject: RE: WATCH extension for IMAP To: John Milan cc: IMAP Extensions WG 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: The underlying protocol has the potential for such a capability. It deals in terms of "object identifiers", so anything can be an object identifier. However, in the ultra-lightweight version, there's only exact match of object identifiers. So, in the case of a new mail event, you would have to receive events for everything that matches the object, and use data in the event payload to determine whether to do anything with the event or discard it. That is, in your "WATCH new mail where from = myboss@company.com" example, you would get all new mail events, and locally filter out the ones that are not from "myboss@company.com". The ultra-lightweight version also has a further restriction; what the payload can carry is limited. Only the SMTP return-path (which may not necessarily be the from) is available from mail delivery, and mail delivered via IMAP COPY or APPEND wouldn't even have that. It is possible to envision future versions in which the event generator (mail delivery or IMAP server) would parse the RFC 2822 headers and deliver such information as From, Subject, etc. In fact, that is absolutely part of the design; we're going to need that! But it isn't going to be in version 1. -- Mark -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HI1gt2055539 for ; Thu, 17 Apr 2003 11:01:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HI1gLW055538 for ietf-imapext-bks; Thu, 17 Apr 2003 11:01:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HI1ft2055531 for ; Thu, 17 Apr 2003 11:01:41 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp7.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3HI1Wrh012804; Thu, 17 Apr 2003 14:01:32 -0400 Date: Thu, 17 Apr 2003 14:01:32 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Timo Sirainen , Cyrus Daboo , IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: Message-ID: References: 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, 17 Apr 2003, Mark Crispin wrote: > On 17 Apr 2003 20:05:17 +0300, Timo Sirainen wrote: > > Well, my client has a list of around 20 mailboxes which show the number > > of unread messages after the mailbox name. I like this behaviour, I can > > leave some messages unread if they require some action that I didn't > > want to do immediately. > > I understand why you like this behavior. > > On the other hand, suppose the user has 1800 mailboxes. Do you do the same > thing? What if STATUS takes a second or so of real time on that server? It's > going to take a while to do 1800 STATUS commands even if the mail store has > fast STATUS metadata. Of course, if the user has recieved new mail in 1800 separate mailboxes, in a notification period, I'd say the server is under a pretty high load already. > Do you require that the user identify 20 mailboxes of particular interest, and > only do it for those 20 mailboxes? I'm not sure if its better for the client to say on per session basis "tell me about mailboxes x, y, z, a, b, c" or just let the client say "tell me about my subscribed mailboxes". I think I like the former, actually. > > I don't think it would be considered very good behaviour to select the > > mailbox immediately and fetch the new messages. I don't necessarily want > > to read them, and I may delete them using another client. > > I agree with that. I personally would like the marker, then a command that I > could give to get the current count. That way, a STATUS isn't done unless I > do it. But if the client author knows they are going to do a status for every notification anyway (or every set of notifications on a mailbox), then why cost them the additional round trip? I do like Cyrus's idea of WATCH=BIFF and WATCH=STATUS, etc (though I could see WATCH=BIFF as just being WATCH=STATUS with no status fields being returned). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHkdt2055132 for ; Thu, 17 Apr 2003 10:46:39 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HHkdbk055131 for ietf-imapext-bks; Thu, 17 Apr 2003 10:46:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (gle@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHkZt2055122 for ; Thu, 17 Apr 2003 10:46:37 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id KAA04393; Thu, 17 Apr 2003 10:46:20 -0700 (PDT) Date: Thu, 17 Apr 2003 10:25:44 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Timo Sirainen cc: Rob Siemborski , Cyrus Daboo , IMAP Extensions WG In-Reply-To: <1050599117.16342.168.camel@hurina> 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 17 Apr 2003 20:05:17 +0300, Timo Sirainen wrote: > Well, my client has a list of around 20 mailboxes which show the number > of unread messages after the mailbox name. I like this behaviour, I can > leave some messages unread if they require some action that I didn't > want to do immediately. I understand why you like this behavior. On the other hand, suppose the user has 1800 mailboxes. Do you do the same thing? What if STATUS takes a second or so of real time on that server? It's going to take a while to do 1800 STATUS commands even if the mail store has fast STATUS metadata. Do you require that the user identify 20 mailboxes of particular interest, and only do it for those 20 mailboxes? In my lightweight notification system, the only cost of watching 1800 mailboxes instead of 20 is that the notification server will have to keep some number of bytes per watch request. > Maybe it would be enough for some people to just see some kind of marker > that there's new mail in the mailbox. I hope that this is enough for many people. > I don't think it would be considered very good behaviour to select the > mailbox immediately and fetch the new messages. I don't necessarily want > to read them, and I may delete them using another client. I agree with that. I personally would like the marker, then a command that I could give to get the current count. That way, a STATUS isn't done unless I do it. I use CDPD a lot. I don't like it when my client decides to do something under the covers automatically. I recognize that sometimes it has no choice. The behavior of "just spawn another connection" makes things worse on CDPD. When your CDPD modem gets into channel scanning, the more that such a client does that, the longer the recovery time. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHfYt2054536 for ; Thu, 17 Apr 2003 10:41:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HHfYIM054535 for ietf-imapext-bks; Thu, 17 Apr 2003 10:41:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from teamdirection.com (s173.n12.vds2000.com [66.84.12.173]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHfWt2054523 for ; Thu, 17 Apr 2003 10:41:33 -0700 (PDT) (envelope-from johnm@teamdirection.com) Received: from grendel (12-228-90-244.client.attbi.com [12.228.90.244]) by teamdirection.com (8.12.9/8.11.2) with SMTP id h3HHfJxN008488; Thu, 17 Apr 2003 13:41:19 -0400 From: "John Milan" To: "Mark Crispin" , "IMAP Extensions WG" Subject: RE: WATCH extension for IMAP Date: Thu, 17 Apr 2003 10:49:56 -0700 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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Are the event types predefined? Such as you might have the following event types: new mail deleted mail flag changes Or can you WATCH an expression? For instance, could say (pardon the SQLness) WATCH new mail where from = myboss@company.com Taking advantage of at least the RFC headers as watchable data. That way, no matter how many folders I might have, I'll get that important message from the boss. More aggressive implementations could probably extend the expression matching to the message body. I'm thinking of a WATCH much like mail filtering. John Milan -----Original Message----- From: owner-ietf-imapext@mail.imc.org [mailto:owner-ietf-imapext@mail.imc.org]On Behalf Of Mark Crispin Sent: Wednesday, April 16, 2003 6:37 PM To: IMAP Extensions WG Subject: WATCH extension for IMAP I've been thinking about defining a WATCH extension to IMAP which would allow an IMAP client to watch for certain events happening to a non-selected mailbox. Once a WATCH is set, it remains in effect until that IMAP session is logged out, and untagged WATCH events for the watched mailbox(es) can be returned at any time. The command will be something like: tag WATCH mailbox event-list and the responses will be something like * WATCH mailbox event-pair-list where an event-pair contains an event type and event data. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HH5Jt2053335 for ; Thu, 17 Apr 2003 10:05:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HH5JQO053334 for ietf-imapext-bks; Thu, 17 Apr 2003 10:05:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HH5Gt2053328 for ; Thu, 17 Apr 2003 10:05:17 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id C0BDB5E017F5; Thu, 17 Apr 2003 20:05:17 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: Rob Siemborski , Cyrus Daboo , IMAP Extensions WG In-Reply-To: References: <1050545570.16338.112.camel@hurina> <1806305761.1050575601@[63.163.82.24]> <1050597813.16342.153.camel@hurina> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050599117.16342.168.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 20:05:17 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 19:47, Mark Crispin wrote: > On Thu, 17 Apr 2003, Timo Sirainen wrote: > > I think it's more likely that clients will be abusive with "new mail in > > mailbox xyz" notification. They'd probably just request STATUS every > > time they receive that. > > A client that does that will quickly have its notification queue filled > and notifications will get dropped. Wouldn't the same thing happen if server did it automatically? > I question why a client would want to issue a STATUS if notified about new > mail in such-and-such mailbox, as opposed to noting that that mailbox has > new mail and/or opening it. > > After all, what's the point of STATUS, other than to see if there is new > messages in the mailbox? In this case, we *know* that that are new > messages! Well, my client has a list of around 20 mailboxes which show the number of unread messages after the mailbox name. I like this behaviour, I can leave some messages unread if they require some action that I didn't want to do immediately. So, once in a while I look at the list and see if there's anything interesting in there. Not just new mail, but also those mails that I left unread. I may have marked some of them as read elsewhere, that pretty much requires STATUS (UNSEEN). Maybe it would be enough for some people to just see some kind of marker that there's new mail in the mailbox. I don't think it would be considered very good behaviour to select the mailbox immediately and fetch the new messages. I don't necessarily want to read them, and I may delete them using another client. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGlst2052734 for ; Thu, 17 Apr 2003 09:47:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HGlrfN052733 for ietf-imapext-bks; Thu, 17 Apr 2003 09:47:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGlqt2052728 for ; Thu, 17 Apr 2003 09:47:52 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3HGllSL032355; Thu, 17 Apr 2003 09:47:47 -0700 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3HGll8H000761 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 17 Apr 2003 09:47:47 -0700 Date: Thu, 17 Apr 2003 09:47:47 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: Rob Siemborski , Cyrus Daboo , IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: <1050597813.16342.153.camel@hurina> Message-ID: References: <1050545570.16338.112.camel@hurina> <1806305761.1050575601@[63.163.82.24]> <1050597813.16342.153.camel@hurina> Organization: Networks and 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 Thu, 17 Apr 2003, Timo Sirainen wrote: > I think it's more likely that clients will be abusive with "new mail in > mailbox xyz" notification. They'd probably just request STATUS every > time they receive that. A client that does that will quickly have its notification queue filled and notifications will get dropped. I question why a client would want to issue a STATUS if notified about new mail in such-and-such mailbox, as opposed to noting that that mailbox has new mail and/or opening it. After all, what's the point of STATUS, other than to see if there is new messages in the mailbox? In this case, we *know* that that are new messages! -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGhYt2052583 for ; Thu, 17 Apr 2003 09:43:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HGhYHB052582 for ietf-imapext-bks; Thu, 17 Apr 2003 09:43:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGhWt2052576 for ; Thu, 17 Apr 2003 09:43:33 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id AC4FA5E017F5; Thu, 17 Apr 2003 19:43:33 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: Rob Siemborski , Cyrus Daboo , IMAP Extensions WG In-Reply-To: References: <1050545570.16338.112.camel@hurina> <1806305761.1050575601@[63.163.82.24]> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050597813.16342.153.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 19:43:33 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 19:20, Mark Crispin wrote: > It's technically easy (trivial even) to do an automatic STATUS, and > perhaps a subscription type mechanism will suffice to avoid the problem. > However, the architecture has to be carefully designed to minimize the > likelihood of abusive client implementations. I think it's more likely that clients will be abusive with "new mail in mailbox xyz" notification. They'd probably just request STATUS every time they receive that. If server sends the STATUS replies directly, it can at least force some "max. n seconds between STATUS notifications" limit. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGe1t2052515 for ; Thu, 17 Apr 2003 09:40:01 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HGe1Mi052514 for ietf-imapext-bks; Thu, 17 Apr 2003 09:40:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGe0t2052506 for ; Thu, 17 Apr 2003 09:40:00 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3HGdsSL030713; Thu, 17 Apr 2003 09:39:54 -0700 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3HGdr8H032373 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 17 Apr 2003 09:39:54 -0700 Date: Thu, 17 Apr 2003 09:39:53 -0700 (PDT) From: Mark Crispin To: Simon Josefsson cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: Message-ID: References: Organization: Networks and 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 Thu, 17 Apr 2003, Simon Josefsson wrote: > If the extension isn't IMAP aware, my initial reaction is that it > should be a vendor specific capability. I.e., your server can > announce a WATCH capability that enables the command you propose. Vendor-specific is not useful. To be useful, it has to be something that is generally adopted. This does NOT preclude a separate, more heavyweight notification facility. It certainly does not compete with a heavyweight facility. The question is: If there was an ultra-lightweight notification mechanism available very soon, would you use it? OR Do you say, "No, I can not make use of an ultra-lightweight notification facility. I'd rather wait until LEMONADE finishes its work, and then wait for that work to be implemented. Until then, I'd rather have nothing at all." LEMONADE is working on the specification for a heavyweight notification facility. I am not competing with that effort. The LEMONADE charter says that they will have that effort done by summer. You can decide for yourself whether you believe that will happen. I know that everybody would like to have a heavyweight notification facility, with lots of bells and whistles. This is not such a facility. I have a prototype ultra-lightweight notification system which I wrote and demonstrated a year ago. All that needs to be done is to stitch it in. It is not likely to provoke server managers into turning it off either. I'm trying to ascertain if it's worth the effort. Personally, I believe that while it isn't ideal, it's good enough. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HG8rt2051592 for ; Thu, 17 Apr 2003 09:08:53 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HG8r8P051591 for ietf-imapext-bks; Thu, 17 Apr 2003 09:08:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HG8qt2051579 for ; Thu, 17 Apr 2003 09:08:52 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from ASG1.WEB.cmu.edu (ASG1.WEB.cmu.edu [128.2.11.38]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3HG8gfg027559; Thu, 17 Apr 2003 12:08:42 -0400 Date: Thu, 17 Apr 2003 12:08:42 -0400 (EDT) From: Rob Siemborski X-X-Sender: rjs3@asg1.web.cmu.edu To: Mark Crispin cc: Cyrus Daboo , Timo Sirainen , IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: Message-ID: References: <1050545570.16338.112.camel@hurina> <1806305761.1050575601@[63.163.82.24]> 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, 17 Apr 2003, Mark Crispin wrote: > What if there is a mail bomb, and multiple messages/second are arriving? > STATUS is not necessarily an inexpensive operation (and the specification > specifically says as much). True, but perhaps multiple notifications for a folder could be aggregated into a single STATUS reply as well? > Nor is it certain that every client would want to do a STATUS. Perhaps it > just wants to note that the mailbox has new messages, and let the user > decide to SELECT it. This is why I'd want to see clients able to subscribe to the particular information that comes back with the notifications. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HG8qt2051582 for ; Thu, 17 Apr 2003 09:08:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HG8q30051580 for ietf-imapext-bks; Thu, 17 Apr 2003 09:08:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HG8pt2051574 for ; Thu, 17 Apr 2003 09:08:51 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3HG8hTc025909; Thu, 17 Apr 2003 09:08:48 -0700 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3HG8h8H029176 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 17 Apr 2003 09:08:43 -0700 Date: Thu, 17 Apr 2003 09:08:43 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: <1050587458.16341.138.camel@hurina> Message-ID: References: <1050545570.16338.112.camel@hurina> <1050587458.16341.138.camel@hurina> Organization: Networks and 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 Thu, 17 Apr 2003, Timo Sirainen wrote: > How are you going to send the notification to IMAP server? Some signal? > Socket? Currently, it would be a TCP connection from the IMAP server to the notification system. There's a good effort being made to avoid dropping notifications (of course, if a drop has to happen, it will happen). The notification system itself does not require that a client receiving notifications be on the same system as the notification system. Generating notifications is currently also done by TCP, but it is likely to move to a datagram type mechanism. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HEXVt2046913 for ; Thu, 17 Apr 2003 07:33:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HEXV6m046912 for ietf-imapext-bks; Thu, 17 Apr 2003 07:33:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HEXTt2046907 for ; Thu, 17 Apr 2003 07:33:30 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id KAA04419; Thu, 17 Apr 2003 10:29:53 -0400 (EDT) Date: Thu, 17 Apr 2003 10:33:21 -0400 From: Cyrus Daboo To: Mark Crispin , Timo Sirainen cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP Message-ID: <1806305761.1050575601@[63.163.82.24]> In-Reply-To: References: <1050545570.16338.112.camel@hurina> X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Wednesday, April 16, 2003 7:43 PM -0700 Mark Crispin wrote: |> I think most of the clients would be just interested in getting |> automatic updates for "STATUS (MESSAGES UNSEEN)", maybe UIDVALIDITY and |> UIDNEXT too. For those it'd be easier if untagged STATUS replies were |> received directly. Maybe "WATCH mailbox (STATUS ())" | | I agree with your observation; this would be nice. Unfortunately, this | functionality is outside of the scope of ultra-lightweight notification. | The notification protocol can support this; however, the current set of | event generators (the mail delivery agents) can not. | | The mail delivery agents merely append to the mailbox file; they have no | concept of "number of messages", "number of unseen messages", | "UIDVALIDITY", "UIDNEXT", or any other STATUS-type metadata. The only | thing they know is "appended a string purported to be a new mail message | to such-and-such mailbox name, with return-path of such-and such". Well, the server will know which mailbox is being watched and when the event for that is seen, why can't the server do an implicit STATUS (with client provided parameters) and return that? i.e. the server does what the client would otherwise do - issue a status for that mailbox. I think for this to be useful within IMAP it has to return STATUS information - that's what clients will want - but I don't see that as being a problem or as interfering with the way the outside notification works. I think it does also have to handle COPY/APPEND changes to the mailbox as well. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HDp1t2045344 for ; Thu, 17 Apr 2003 06:51:01 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HDp1B7045343 for ietf-imapext-bks; Thu, 17 Apr 2003 06:51:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HDowt2045328 for ; Thu, 17 Apr 2003 06:50:59 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 166225E017F5; Thu, 17 Apr 2003 16:50:59 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: IMAP Extensions WG In-Reply-To: References: <1050545570.16338.112.camel@hurina> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050587458.16341.138.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 16:50:58 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 05:43, Mark Crispin wrote: > I agree with your observation; this would be nice. Unfortunately, this > functionality is outside of the scope of ultra-lightweight notification. > The notification protocol can support this; however, the current set of > event generators (the mail delivery agents) can not. How are you going to send the notification to IMAP server? Some signal? Socket? I've been thinking about using Linux's dnotify and BSD's kqueue() for this. They should be quite lightweight as well, and they notice all changes in mailbox file/directory. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HASVt2031980 for ; Thu, 17 Apr 2003 03:28:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HASVLK031979 for ietf-imapext-bks; Thu, 17 Apr 2003 03:28:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HASSt2031973 for ; Thu, 17 Apr 2003 03:28:29 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3HASAXK018099 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Apr 2003 12:28:11 +0200 To: Mark Crispin Cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP X-Payment: hashcash 1.2 0:030417:mrc@CAC.Washington.EDU:b40979cfe9315a21 X-Hashcash: 0:030417:mrc@CAC.Washington.EDU:b40979cfe9315a21 X-Payment: hashcash 1.2 0:030417:ietf-imapext@imc.org:888596dcd84ca2bf X-Hashcash: 0:030417:ietf-imapext@imc.org:888596dcd84ca2bf From: Simon Josefsson Date: Thu, 17 Apr 2003 12:28:10 +0200 In-Reply-To: (Mark Crispin's message of "Wed, 16 Apr 2003 18:36:56 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > The single most important event type will be new mail, with the event data > being the SMTP return-path of the message. So, in effect, this will be > "biff for IMAP". Yay! This would be very useful, at least for my client. I concur with Timo's observation, it is much more useful if the WATCH extension responded with requested information (i.e., one of the STATUS parameters, or possibly even a FETCH parameter -- imagine receiving BODY and immediately being able to display information about the new message) instead of just a maybe-there-is-new-mail-over-here type of indication. The latter kind of notification is sufficient in a non-IMAP notification protocol, like zephyr (which the client can support already), but if the feature is built into the IMAP protocol I think it should be IMAP-aware instead of simply a external notification protocol tunneled through IMAP. If the extension isn't IMAP aware, my initial reaction is that it should be a vendor specific capability. I.e., your server can announce a WATCH capability that enables the command you propose. A real IMAP-aware NOTIFICATION extension would be of separate utility, and could be defined in parallel with the WATCH capability. Then a server supporting WATCH can decide if it wants to do a STATUS internally in order to be able to support NOTIFICATION too, and clients can decide which kind of notification they are most helped by and decide accordingly. Thoughts? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H4kst2091131 for ; Wed, 16 Apr 2003 21:46:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H4ksTX091129 for ietf-imapext-bks; Wed, 16 Apr 2003 21:46:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (chince@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H4kqt2091123 for ; Wed, 16 Apr 2003 21:46:53 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id VAA03284; Wed, 16 Apr 2003 21:46:51 -0700 (PDT) Date: Wed, 16 Apr 2003 21:23:59 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Philip Guenther cc: IMAP Extensions WG In-Reply-To: <200304170424.h3H4OKe15727@katroo.Sendmail.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: On Wed, 16 Apr 2003 21:23:04 -0700, Philip Guenther wrote: > Does the IMAP server generate "new mail" notifications when it performs > APPEND and COPY operations? This could be done within the "ultra-lightweight" framework, although perhaps it should be a different type of event than new mail. Is this something that people would like to have/find useful? In the case of multiple-message COPY and multiple APPEND, it would most likely generate a single event and not an event per-message. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H4Mxt2090819 for ; Wed, 16 Apr 2003 21:22:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H4Mxkv090818 for ietf-imapext-bks; Wed, 16 Apr 2003 21:22:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H4Mst2090807 for ; Wed, 16 Apr 2003 21:22:58 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3H4MfFd022522; Wed, 16 Apr 2003 21:22:41 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7/8.11.6) with ESMTP id h3H4OKe15727; Wed, 16 Apr 2003 21:24:20 -0700 (PDT) Message-Id: <200304170424.h3H4OKe15727@katroo.Sendmail.COM> To: Mark Crispin Cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-reply-to: References: Date: Wed, 16 Apr 2003 21:23:04 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: ... >I am interested in feedback as to whether this proposed extension is >interesting or not. Also, would it be better to build an extension which >has extensibility but with restraints ("ultra-lightweight") on how it can >be extended, or if it should be strictly a new mail watching facility and >leave the possibility of other types of notifications to a different >facilty (such as what is being discussed in LEMONADE). Does the IMAP server generate "new mail" notifications when it performs APPEND and COPY operations? Philip Guenther Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H2hBt2085826 for ; Wed, 16 Apr 2003 19:43:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H2hB51085825 for ietf-imapext-bks; Wed, 16 Apr 2003 19:43:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H2hAt2085818 for ; Wed, 16 Apr 2003 19:43:10 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3H2h4t7020640; Wed, 16 Apr 2003 19:43:09 -0700 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3H2h38H005777 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 16 Apr 2003 19:43:03 -0700 Date: Wed, 16 Apr 2003 19:43:03 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: <1050545570.16338.112.camel@hurina> Message-ID: References: <1050545570.16338.112.camel@hurina> Organization: Networks and 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 Wed, 17 Apr 2003, Timo Sirainen wrote: > I think most of the clients would be just interested in getting > automatic updates for "STATUS (MESSAGES UNSEEN)", maybe UIDVALIDITY and > UIDNEXT too. For those it'd be easier if untagged STATUS replies were > received directly. Maybe "WATCH mailbox (STATUS ())" I agree with your observation; this would be nice. Unfortunately, this functionality is outside of the scope of ultra-lightweight notification. The notification protocol can support this; however, the current set of event generators (the mail delivery agents) can not. The mail delivery agents merely append to the mailbox file; they have no concept of "number of messages", "number of unseen messages", "UIDVALIDITY", "UIDNEXT", or any other STATUS-type metadata. The only thing they know is "appended a string purported to be a new mail message to such-and-such mailbox name, with return-path of such-and such". So, to rephase my original question. Would it be useful to receive, from the IMAP server, a notification that a mail delivery agent appended what purports to be new mail to such-and-such mailbox name with return-path of such-and-such? You could, in reaction to this notification, then do a STATUS. What this buys you is that you could react much faster if a mailbox gets new mail. Also, you won't have to issue STATUS (at least not as often) to poll for new messages. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H2Cut2085196 for ; Wed, 16 Apr 2003 19:12:56 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H2Cuvl085195 for ietf-imapext-bks; Wed, 16 Apr 2003 19:12:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H2Crt2085188 for ; Wed, 16 Apr 2003 19:12:54 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id D6F415E017F5; Thu, 17 Apr 2003 05:12:50 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: IMAP Extensions WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050545570.16338.112.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 05:12:50 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 04:36, Mark Crispin wrote: > I've been thinking about defining a WATCH extension to IMAP which would > allow an IMAP client to watch for certain events happening to a > non-selected mailbox. Once a WATCH is set, it remains in effect until > that IMAP session is logged out, and untagged WATCH events for the watched > mailbox(es) can be returned at any time. > > The command will be something like: > tag WATCH mailbox event-list > and the responses will be something like > * WATCH mailbox event-pair-list > where an event-pair contains an event type and event data. I think most of the clients would be just interested in getting automatic updates for "STATUS (MESSAGES UNSEEN)", maybe UIDVALIDITY and UIDNEXT too. For those it'd be easier if untagged STATUS replies were received directly. Maybe "WATCH mailbox (STATUS ())" Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H1b1t2084366 for ; Wed, 16 Apr 2003 18:37:01 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H1b1n6084365 for ietf-imapext-bks; Wed, 16 Apr 2003 18:37:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H1axt2084359 for ; Wed, 16 Apr 2003 18:37:00 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3H1aug9006788 for ; Wed, 16 Apr 2003 18:37:02 -0700 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3H1au8H003884 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 16 Apr 2003 18:36:56 -0700 Date: Wed, 16 Apr 2003 18:36:56 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG Subject: WATCH extension for IMAP Message-ID: Organization: Networks and 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: I've been thinking about defining a WATCH extension to IMAP which would allow an IMAP client to watch for certain events happening to a non-selected mailbox. Once a WATCH is set, it remains in effect until that IMAP session is logged out, and untagged WATCH events for the watched mailbox(es) can be returned at any time. The command will be something like: tag WATCH mailbox event-list and the responses will be something like * WATCH mailbox event-pair-list where an event-pair contains an event type and event data. The single most important event type will be new mail, with the event data being the SMTP return-path of the message. So, in effect, this will be "biff for IMAP". We have talked about other event types, such as "message flags changed" or "mailbox expunged", but it isn't clear how well this will scale (it's one thing to generate an event when delivering a new mail message, it's quite another to do so every time some flag gets altered!). This is in effect an IMAP interface to an ultra-lightweight notification protocol and facility that I am working on. The IMAP server won't do any actual "watching"; instead, it will just be a client to the notification facility. I need to emphasize the "ultra-lightweight" nature of this facility. Although the underlying notification protocol is completely extensible, a foremost consideration has been lightweight and low-cost (hence the tenative nature of the flags/expunge event types). That is also why the SMTP return-path is in the new-mail notification, because many mail delivery agents only know that. Last but not least, this is something that can be made available Real Soon. Much of the code already exists. I know that LEMONADE has a fairly aggressive schedule for its notification facility, but I suspect that schedule will slip. I am interested in feedback as to whether this proposed extension is interesting or not. Also, would it be better to build an extension which has extensibility but with restraints ("ultra-lightweight") on how it can be extended, or if it should be strictly a new mail watching facility and leave the possibility of other types of notifications to a different facilty (such as what is being discussed in LEMONADE). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3DNdAes008581 for ; Sun, 13 Apr 2003 16:39:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3DNdATx008580 for ietf-imapext-bks; Sun, 13 Apr 2003 16:39:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3DNd9es008571 for ; Sun, 13 Apr 2003 16:39:09 -0700 (PDT) (envelope-from phoffman@imc.org) Received: from localhost (phoffman@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) with ESMTP id h3DNd9n7008568 for ; Sun, 13 Apr 2003 16:39:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: phoffman owned process doing -bs Date: Sun, 13 Apr 2003 16:39:09 -0700 (PDT) From: Paul Hoffman X-X-Sender: phoffman@above.proper.com To: ietf-imapext@imc.org Subject: ADMINISTRIVIA: fighting with the new mail server Message-ID: <20030413163842.U8537@above.proper.com> 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 just changed the OS for the mail server, and am not convinced that I got all the bugs worked out. So I'm inflicting this on you. :-) Hopefully, you'll only see this once. --Paul Hoffman Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3DNZLes008459 for ; Sun, 13 Apr 2003 16:35:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3DNZLcZ008458 for ietf-imapext-bks; Sun, 13 Apr 2003 16:35:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3DNZKes008453 for ; Sun, 13 Apr 2003 16:35:20 -0700 (PDT) (envelope-from phoffman@imc.org) Received: from localhost (phoffman@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) with ESMTP id h3DNZK1t008450 for ; Sun, 13 Apr 2003 16:35:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: phoffman owned process doing -bs Date: Sun, 13 Apr 2003 16:35:20 -0700 (PDT) From: Paul Hoffman X-X-Sender: phoffman@above.proper.com To: ietf-imapext@imc.org Subject: ADMINISTRIVIA: testing the mail server Message-ID: <20030413163458.Q8122@above.proper.com> 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 just changed the OS for the mail server, and am not convinced that I got all the bugs worked out. So I'm inflicting this on you. :-) Hopefully, you'll only see this once. --Paul Hoffman Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3DNXSes008294 for ; Sun, 13 Apr 2003 16:33:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3DNXSff008293 for ietf-imapext-bks; Sun, 13 Apr 2003 16:33:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3DNXRes008288 for ; Sun, 13 Apr 2003 16:33:27 -0700 (PDT) (envelope-from phoffman@imc.org) Received: from localhost (phoffman@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) with ESMTP id h3DNXR62008285 for ; Sun, 13 Apr 2003 16:33:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: phoffman owned process doing -bs Date: Sun, 13 Apr 2003 16:33:27 -0700 (PDT) From: Paul Hoffman X-X-Sender: phoffman@above.proper.com To: ietf-imapext@imc.org Subject: ADMINISTRIVIA: testing out the new mail server setup Message-ID: <20030413163301.L8122@above.proper.com> 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 just changed the OS for the mail server, and am not convinced that I got all the bugs worked out. So I'm inflicting this on you. :-) Hopefully, you'll only see this once. --Paul Hoffman Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CHGIJM016818 for ; Sat, 12 Apr 2003 10:16:18 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3CHGInw016816 for ietf-imapext-bks; Sat, 12 Apr 2003 10:16:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CHGEJM016772 for ; Sat, 12 Apr 2003 10:16:14 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3CHG7RG013691; Sat, 12 Apr 2003 10:16:07 -0700 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3CHG78H010538 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 12 Apr 2003 10:16:07 -0700 Date: Sat, 12 Apr 2003 10:16:07 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo cc: Alexey Melnikov , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt In-Reply-To: <2147483647.1050147388@[10.0.1.3]> Message-ID: References: <2147483647.1050084387@[10.0.1.6]> <3E9793F0.A48EF7E2@messagingdirect.com> <2147483647.1050147388@[10.0.1.3]> Organization: Networks and 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 Sat, 12 Apr 2003, Cyrus Daboo wrote: > | Why would one want to use MODSEQ with THREAD? > For the same reason one would use it in the search criteria on sort: to > have the command return results only for those messages that changed since > the MODSEQ. I doubt this is really a useful behaviour but it has to be > present for consistency if you are adding MODSEQ to search unless its > explicitly stated MODSEQ can't be used in sort/thread search criteria. I'm hard-pressed to think of a use for MODSEQ with THREAD; and while SORT presents some possible use I doubt that there would be much of that in real life. If you declare that MODSEQ is an additional argument to SEARCH (much as CHARSET is) instead of a SEARCH criterion, then you avoid the issue. But that's no good if you decide to have MODSEQ in SORT. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CFkfJM012900 for ; Sat, 12 Apr 2003 08:46:41 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3CFkfbv012899 for ietf-imapext-bks; Sat, 12 Apr 2003 08:46:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CFkdJM012895 for ; Sat, 12 Apr 2003 08:46:40 -0700 (PDT) Received: from [10.0.1.3] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA24019; Sat, 12 Apr 2003 11:43:12 -0400 (EDT) Date: Sat, 12 Apr 2003 11:46:39 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt Message-ID: <2147483647.1050147999@[10.0.1.3]> In-Reply-To: <3E9796E8.6B6F4187@messagingdirect.com> References: <2147483647.1050082018@[10.0.1.6]> <3E9796E8.6B6F4187@messagingdirect.com> X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Friday, April 11, 2003 10:32 PM -0600 Alexey Melnikov wrote: |> You need to change the annotation entry names to exclude the "/message" |> prefix. We agreed to eliminate the /message and /body entry name prefixes |> at the last meeting. I'm hoping to get an updated annotation document out |> in the next week with that and other changes. | | Is the \Seen flag now "/flags/\\seen" or "flags/\\seen"? "/flags/\\seen" - i.e. / prefix is still present. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CFaVJM012350 for ; Sat, 12 Apr 2003 08:36:31 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3CFaVAi012349 for ietf-imapext-bks; Sat, 12 Apr 2003 08:36:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CFaUJM012342 for ; Sat, 12 Apr 2003 08:36:30 -0700 (PDT) Received: from [10.0.1.3] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA23981; Sat, 12 Apr 2003 11:33:02 -0400 (EDT) Date: Sat, 12 Apr 2003 11:36:28 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt Message-ID: <2147483647.1050147388@[10.0.1.3]> In-Reply-To: <3E9793F0.A48EF7E2@messagingdirect.com> References: <2147483647.1050084387@[10.0.1.6]> <3E9793F0.A48EF7E2@messagingdirect.com> X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Friday, April 11, 2003 10:20 PM -0600 Alexey Melnikov wrote: |> Interaction with SORT and THREAD - note that both SORT and THREAD take |> search criteria as arguments. Right now the draft only discusses SORT but |> it needs to include THREAD as well (an example for a thread response with |> MODSEQ would be good too). | | Why would one want to use MODSEQ with THREAD? For the same reason one would use it in the search criteria on sort: to have the command return results only for those messages that changed since the MODSEQ. I doubt this is really a useful behaviour but it has to be present for consistency if you are adding MODSEQ to search unless its explicitly stated MODSEQ can't be used in sort/thread search criteria. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C5W7JM011312 for ; Fri, 11 Apr 2003 22:32:07 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3C5W7tx011311 for ietf-imapext-bks; Fri, 11 Apr 2003 22:32:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C5W4JM011304 for ; Fri, 11 Apr 2003 22:32:06 -0700 (PDT) Received: from messagingdirect.com (1Cust203.tnt3.edmonton.ab.da.uu.net [64.10.184.203]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3C5Z7V15312; Fri, 11 Apr 2003 23:35:08 -0600 Message-ID: <3E97A4B1.5FD5F41B@messagingdirect.com> Date: Fri, 11 Apr 2003 23:31:29 -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: Cyrus Daboo CC: Mark Crispin , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <2147483647.1050081221@[10.0.1.6]> <3E97374C.7048A812@messagingdirect.com> <2147483647.1050083541@[10.0.1.6]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > |> I have no problems with the last suggested change (i.e. HIGHESTMODSEQ > |> with 0). > |> Alternatively, we can say that if no HIGHESTMODSEQ is returned on SELECT, > |> then CONDSTORE is not supported for the mailbox? This is probably better. > | > | Either way works for me. I think though that an affirmative statement is > | better than the absence of one; so HIGHESTMODSEQ 0 or NOMODSEQ seems > | better than a missing HIGHESTMODSEQ on SELECT. > > Agreed, and I would favour NOMODSEQ for clarity as well. Ok, I've added NOMODSEQ to the document. Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C4oJJM010248 for ; Fri, 11 Apr 2003 21:50:19 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3C4oJv7010247 for ietf-imapext-bks; Fri, 11 Apr 2003 21:50:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C4oFJM010243 for ; Fri, 11 Apr 2003 21:50:18 -0700 (PDT) Received: from messagingdirect.com (1Cust203.tnt3.edmonton.ab.da.uu.net [64.10.184.203]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3C4rMV15153; Fri, 11 Apr 2003 22:53:22 -0600 Message-ID: <3E979AEB.308DAE93@messagingdirect.com> Date: Fri, 11 Apr 2003 22:49:47 -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 , Chris Newman , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <3E9738BB.DBAD97E3@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Mark Crispin wrote: > > > . STORE should NEVER reply NO; instead, the untagged FETCH response > > should be relied upon to indicate what happened > > > > I disapprove of the idea of NO with the MODIFIED status code. This > > introduces, for the first time, an instance where the server replied NO > > but something happened anyway. Actually, nothing happened. This is not much different from [removed] "NEWNAME" response code. But I don't really care whether MODIFIED is returned with OK or NO. Does anybody else have any preferences? > The command succeeded and did what was > > requested; therefore OK should be returned (with the MODIFIED status > > code). > > This is fine with me. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C4X9JM009974 for ; Fri, 11 Apr 2003 21:33:09 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3C4X9n5009973 for ietf-imapext-bks; Fri, 11 Apr 2003 21:33:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C4X8JM009969 for ; Fri, 11 Apr 2003 21:33:08 -0700 (PDT) Received: from messagingdirect.com (1Cust203.tnt3.edmonton.ab.da.uu.net [64.10.184.203]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3C4aNV15103; Fri, 11 Apr 2003 22:36:23 -0600 Message-ID: <3E9796E8.6B6F4187@messagingdirect.com> Date: Fri, 11 Apr 2003 22:32:40 -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: Cyrus Daboo CC: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <2147483647.1050082018@[10.0.1.6]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > You need to change the annotation entry names to exclude the "/message" > prefix. We agreed to eliminate the /message and /body entry name prefixes > at the last meeting. I'm hoping to get an updated annotation document out > in the next week with that and other changes. Is the \Seen flag now "/flags/\\seen" or "flags/\\seen"? Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C4H3JM009747 for ; Fri, 11 Apr 2003 21:17:03 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3C4H2kp009746 for ietf-imapext-bks; Fri, 11 Apr 2003 21:17:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C4GxJM009742 for ; Fri, 11 Apr 2003 21:17:01 -0700 (PDT) Received: from messagingdirect.com (1Cust203.tnt3.edmonton.ab.da.uu.net [64.10.184.203]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3C4KGV15056; Fri, 11 Apr 2003 22:20:17 -0600 Message-ID: <3E9793F0.A48EF7E2@messagingdirect.com> Date: Fri, 11 Apr 2003 22: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: Cyrus Daboo CC: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <2147483647.1050084387@[10.0.1.6]> 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: Cyrus Daboo wrote: > Interaction with SORT and THREAD - note that both SORT and THREAD take > search criteria as arguments. Right now the draft only discusses SORT but > it needs to include THREAD as well (an example for a thread response with > MODSEQ would be good too). Why would one want to use MODSEQ with THREAD? > Also the formal syntax for the search and sort responses is slightly wrong > (missing SP) Thank you. > and should have thread added: > > mailbox-data =/ > "SEARCH" [1*(SP nz-number) SP search_sort_mod_seq] / > "SORT" [1*(SP nz-number) SP search_sort_mod_seq] / > "THREAD" [SP 1*thread-list SP search_sort_mod_seq] Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BM6TJM021650 for ; Fri, 11 Apr 2003 15:06:29 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BM6TL8021649 for ietf-imapext-bks; Fri, 11 Apr 2003 15:06:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BM6RJM021641 for ; Fri, 11 Apr 2003 15:06:28 -0700 (PDT) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id SAA19206 for ; Fri, 11 Apr 2003 18:03:03 -0400 (EDT) Date: Fri, 11 Apr 2003 18:06:27 -0400 From: Cyrus Daboo To: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt Message-ID: <2147483647.1050084387@[10.0.1.6]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Interaction with SORT and THREAD - note that both SORT and THREAD take search criteria as arguments. Right now the draft only discusses SORT but it needs to include THREAD as well (an example for a thread response with MODSEQ would be good too). Also the formal syntax for the search and sort responses is slightly wrong (missing SP) and should have thread added: mailbox-data =/ "SEARCH" [1*(SP nz-number) SP search_sort_mod_seq] / "SORT" [1*(SP nz-number) SP search_sort_mod_seq] / "THREAD" [SP 1*thread-list SP search_sort_mod_seq] -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLqRJM020242 for ; Fri, 11 Apr 2003 14:52:27 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLqRjZ020241 for ietf-imapext-bks; Fri, 11 Apr 2003 14:52:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLqPJM020236 for ; Fri, 11 Apr 2003 14:52:26 -0700 (PDT) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA19139; Fri, 11 Apr 2003 17:48:56 -0400 (EDT) Date: Fri, 11 Apr 2003 17:52:21 -0400 From: Cyrus Daboo To: Mark Crispin , Alexey Melnikov cc: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt Message-ID: <2147483647.1050083541@[10.0.1.6]> In-Reply-To: References: <2147483647.1050081221@[10.0.1.6]> <3E97374C.7048A812@messagingdirect.com> X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Friday, April 11, 2003 2:45 PM -0700 Mark Crispin wrote: |> I have no problems with the last suggested change (i.e. HIGHESTMODSEQ |> with 0). |> Alternatively, we can say that if no HIGHESTMODSEQ is returned on SELECT, |> then CONDSTORE is not supported for the mailbox? This is probably better. | | Either way works for me. I think though that an affirmative statement is | better than the absence of one; so HIGHESTMODSEQ 0 or NOMODSEQ seems | better than a missing HIGHESTMODSEQ on SELECT. Agreed, and I would favour NOMODSEQ for clarity as well. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLlNJM020110 for ; Fri, 11 Apr 2003 14:47:23 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLlNaw020109 for ietf-imapext-bks; Fri, 11 Apr 2003 14:47:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLlMJM020105 for ; Fri, 11 Apr 2003 14:47:22 -0700 (PDT) Received: from messagingdirect.com (dhcp198-169.esys.ca [198.161.92.169]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3BLopV13187; Fri, 11 Apr 2003 15:50:51 -0600 Message-ID: <3E9738BB.DBAD97E3@messagingdirect.com> Date: Fri, 11 Apr 2003 15:50:51 -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: Chris Newman , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt 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: > Comments: > > A document in Last Call should not have open issues. Resolve them one way > or another. I recommend that: > . it NOT be required that conditional STORE be atomic across the message > set Actually I was in favor of this (i.e. not atomic across the message set) for a long time. It might be just to complex for some servers to add transaction support. Chris? > . STORE should NEVER reply NO; instead, the untagged FETCH response > should be relied upon to indicate what happened > > I disapprove of the idea of NO with the MODIFIED status code. This > introduces, for the first time, an instance where the server replied NO > but something happened anyway. The command succeeded and did what was > requested; therefore OK should be returned (with the MODIFIED status > code). This is fine with me. > Otherwise, the document seems technically fine to me. I think that we > should be kind to the RFC Editor and edit it into a shape that's somewhat > closer to publication status. Yep. Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLjBJM019989 for ; Fri, 11 Apr 2003 14:45:11 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLjAMC019988 for ietf-imapext-bks; Fri, 11 Apr 2003 14:45:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLj7JM019984 for ; Fri, 11 Apr 2003 14:45:07 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3BLj6RG021446; Fri, 11 Apr 2003 14:45:07 -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+UW03.04/8.12.1+UW02.12) with ESMTP id h3BLj68H013436 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Apr 2003 14:45:06 -0700 Date: Fri, 11 Apr 2003 14:45:06 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov cc: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt In-Reply-To: <3E97374C.7048A812@messagingdirect.com> Message-ID: References: <2147483647.1050081221@[10.0.1.6]> <3E97374C.7048A812@messagingdirect.com> 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, 11 Apr 2003, Alexey Melnikov wrote: > I have no problems with the last suggested change (i.e. HIGHESTMODSEQ with > 0). > Alternatively, we can say that if no HIGHESTMODSEQ is returned on SELECT, > then CONDSTORE is not supported for the mailbox? This is probably better. Either way works for me. I think though that an affirmative statement is better than the absence of one; so HIGHESTMODSEQ 0 or NOMODSEQ seems better than a missing HIGHESTMODSEQ on SELECT. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLfSJM019859 for ; Fri, 11 Apr 2003 14:41:29 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLfSrP019858 for ietf-imapext-bks; Fri, 11 Apr 2003 14:41:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLfRJM019853 for ; Fri, 11 Apr 2003 14:41:27 -0700 (PDT) Received: from messagingdirect.com (dhcp198-169.esys.ca [198.161.92.169]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3BLioV13136; Fri, 11 Apr 2003 15:44:50 -0600 Message-ID: <3E97374C.7048A812@messagingdirect.com> Date: Fri, 11 Apr 2003 15:44:44 -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: Cyrus Daboo CC: Mark Crispin , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <2147483647.1050081221@[10.0.1.6]> 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: Cyrus Daboo wrote: > Hi Mark, > > --On Friday, April 11, 2003 1:58 PM -0700 Mark Crispin > wrote: > > | I know that this is rather late, but is there a recommended way for a > | server which has CONDSTORE to operate with a mail store that does not > | support it (e.g. always return 0)? > | > | I could offer CONDSTORE much faster in my server if I don't have to > | support in in all possible mailbox formats. > > I guess that could be done by either allowing 0 or having an untagged > response as part of SELECT to indicate CONDSTORE is not supported on the > mailbox being selected, even though the capability is present. The later > would be better because clients could then not use the extended commands > for that mailbox. Perhaps the HIGHESTMODSEQ response with value '0' could > be used as an indication of this? I have no problems with the last suggested change (i.e. HIGHESTMODSEQ with 0). Alternatively, we can say that if no HIGHESTMODSEQ is returned on SELECT, then CONDSTORE is not supported for the mailbox? This is probably better. Anybody else? Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLegJM019835 for ; Fri, 11 Apr 2003 14:40:42 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLegmC019834 for ietf-imapext-bks; Fri, 11 Apr 2003 14:40:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLefJM019830 for ; Fri, 11 Apr 2003 14:40:41 -0700 (PDT) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA19045 for ; Fri, 11 Apr 2003 17:37:17 -0400 (EDT) Date: Fri, 11 Apr 2003 17:40:41 -0400 From: Cyrus Daboo To: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt Message-ID: <2147483647.1050082841@[10.0.1.6]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The formal syntax for 'entry-name' should be simply defined as: entry-name = string to fall in line with ANNOTATE. There should be a comment/reference to the annotate spec at that point. That will also allow you to remove the comment about escape rules at that point. Also, could be use "priv" instead of "private" for entry-type-resp just to fall in line with the suffixes that ANNOTATE uses? -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLR0JM019302 for ; Fri, 11 Apr 2003 14:27:01 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLR0sf019301 for ietf-imapext-bks; Fri, 11 Apr 2003 14:27:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLQxJM019296 for ; Fri, 11 Apr 2003 14:26:59 -0700 (PDT) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA18969 for ; Fri, 11 Apr 2003 17:23:34 -0400 (EDT) Date: Fri, 11 Apr 2003 17:26:58 -0400 From: Cyrus Daboo To: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt Message-ID: <2147483647.1050082018@[10.0.1.6]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: You need to change the annotation entry names to exclude the "/message" prefix. We agreed to eliminate the /message and /body entry name prefixes at the last meeting. I'm hoping to get an updated annotation document out in the next week with that and other changes. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLEXJM018905 for ; Fri, 11 Apr 2003 14:14:33 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLEXgo018904 for ietf-imapext-bks; Fri, 11 Apr 2003 14:14:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLEVJM018900 for ; Fri, 11 Apr 2003 14:14:31 -0700 (PDT) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA18862; Fri, 11 Apr 2003 17:10:18 -0400 (EDT) Date: Fri, 11 Apr 2003 17:13:41 -0400 From: Cyrus Daboo To: Mark Crispin , Pete Resnick cc: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt Message-ID: <2147483647.1050081221@[10.0.1.6]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Friday, April 11, 2003 1:58 PM -0700 Mark Crispin wrote: | I know that this is rather late, but is there a recommended way for a | server which has CONDSTORE to operate with a mail store that does not | support it (e.g. always return 0)? | | I could offer CONDSTORE much faster in my server if I don't have to | support in in all possible mailbox formats. I guess that could be done by either allowing 0 or having an untagged response as part of SELECT to indicate CONDSTORE is not supported on the mailbox being selected, even though the capability is present. The later would be better because clients could then not use the extended commands for that mailbox. Perhaps the HIGHESTMODSEQ response with value '0' could be used as an indication of this? -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKwmJM018067 for ; Fri, 11 Apr 2003 13:58:48 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BKwmnm018066 for ietf-imapext-bks; Fri, 11 Apr 2003 13:58:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKwlJM018062 for ; Fri, 11 Apr 2003 13:58:47 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3BKwiSL023706; Fri, 11 Apr 2003 13:58:49 -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+UW03.04/8.12.1+UW02.12) with ESMTP id h3BKwh8H009689 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Apr 2003 13:58:44 -0700 Date: Fri, 11 Apr 2003 13:58:43 -0700 (Pacific Daylight Time) From: Mark Crispin To: Pete Resnick cc: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt In-Reply-To: Message-ID: References: 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: One last thing... I know that this is rather late, but is there a recommended way for a server which has CONDSTORE to operate with a mail store that does not support it (e.g. always return 0)? I could offer CONDSTORE much faster in my server if I don't have to support in in all possible mailbox formats. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKliJM017487 for ; Fri, 11 Apr 2003 13:47:44 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BKlhlN017486 for ietf-imapext-bks; Fri, 11 Apr 2003 13:47:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKlgJM017482 for ; Fri, 11 Apr 2003 13:47:42 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3BKldt7028983; Fri, 11 Apr 2003 13:47:44 -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+UW03.04/8.12.1+UW02.12) with ESMTP id h3BKld8H008742 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Apr 2003 13:47:39 -0700 Date: Fri, 11 Apr 2003 13:47:38 -0700 (Pacific Daylight Time) From: Mark Crispin To: Pete Resnick cc: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt In-Reply-To: Message-ID: References: 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: Comments: A document in Last Call should not have open issues. Resolve them one way or another. I recommend that: . it NOT be required that conditional STORE be atomic across the message set . STORE should NEVER reply NO; instead, the untagged FETCH response should be relied upon to indicate what happened I disapprove of the idea of NO with the MODIFIED status code. This introduces, for the first time, an instance where the server replied NO but something happened anyway. The command succeeded and did what was requested; therefore OK should be returned (with the MODIFIED status code). Otherwise, the document seems technically fine to me. I think that we should be kind to the RFC Editor and edit it into a shape that's somewhat closer to publication status. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BHYZJM006262 for ; Fri, 11 Apr 2003 10:34:35 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BHYZgd006261 for ietf-imapext-bks; Fri, 11 Apr 2003 10:34:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BHYXJM006257 for ; Fri, 11 Apr 2003 10:34:34 -0700 (PDT) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2b6) for ; Fri, 11 Apr 2003 12:34:34 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.0a8] Date: Fri, 11 Apr 2003 12:34:24 -0500 To: ietf-imapext@imc.org From: Pete Resnick Subject: WG last call on draft-ietf-imapext-condstore-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey has submitted the latest version of conditional store as a WG draft. We've all had plenty of time with it, so this is a WG last call on it. Please see: http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-00.txt Please post affirmative comments as well as any problems you might have. I'd like to submit this for IETF last call ASAP. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37GUeJM015196 for ; Mon, 7 Apr 2003 09:30:40 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37GUe39015195 for ietf-imapext-bks; Mon, 7 Apr 2003 09:30:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37GUcJM015191 for ; Mon, 7 Apr 2003 09:30:38 -0700 (PDT) Received: from messagingdirect.com (dhcp198-169.esys.ca [198.161.92.169]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h37GY3V06248; Mon, 7 Apr 2003 10:34:03 -0600 Message-ID: <3E910145.26596199@messagingdirect.com> Date: Sun, 06 Apr 2003 22:40:37 -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: Cyrus Daboo CC: Mark Crispin , IMAP Extensions WG , IMAP Discusson List Subject: Re: 'Label' flags 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: > On Sun, 06 Apr 2003 23:02:24 -0400, Cyrus Daboo wrote: > > I've seen 'in the wild' keywords such as $Label1, $Label2 etc Since I'm in > > the process of adding keyword support and want to have a fixed set of > > 'labels' that a user can define > ^^^^ client > > I think that my correction is important. > > If you want "labels" that a user can defined, that's keywords. > > What you are asking about is a set of fixed names which has a different > meaning on a per-client basis. I agree. Regarding the original question: I think we should standardize used client labels, but $Label1/$Label2/... should not be standardized, because they have no associated meaning. I've only seen $Label1/... being implemented in Mozilla. Mozilla allows a user to set on a message one of 5 mutually exclusive labels and a user can modify the meaning of these labels (i.e. their text description is editable). This is wrong, as there is no way to share what $Label1 means for different clients, and it is possible to have unpredictable results as two Mozillas can be configured differently. Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h373ZbJM003718 for ; Sun, 6 Apr 2003 20:35:37 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h373ZbGC003717 for ietf-imapext-bks; Sun, 6 Apr 2003 20:35:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (mhmcg@panda.com [206.124.149.114]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h373ZZJM003713 for ; Sun, 6 Apr 2003 20:35:36 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id UAA13646; Sun, 6 Apr 2003 20:35:33 -0700 (PDT) Date: Sun, 6 Apr 2003 20:31:27 -0700 (PDT) From: Mark Crispin Subject: re: 'Label' flags To: Cyrus Daboo cc: IMAP Extensions WG , IMAP Discusson List In-Reply-To: <2147483647.1049670144@[10.0.1.6]> 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, 06 Apr 2003 23:02:24 -0400, Cyrus Daboo wrote: > I've seen 'in the wild' keywords such as $Label1, $Label2 etc Since I'm in > the process of adding keyword support and want to have a fixed set of > 'labels' that a user can define ^^^^ client I think that my correction is important. If you want "labels" that a user can defined, that's keywords. What you are asking about is a set of fixed names which has a different meaning on a per-client basis. > I'm interested in knowing whether this is > something that should be 'standardised' behaviour to promote interop > between clients. I certainly hope not. But I'm not going to oppose it either. I am somewhat perplexed as to how this would be useful; but I don't see particular harm either. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3732PJM002807 for ; Sun, 6 Apr 2003 20:02:25 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3732Phl002806 for ietf-imapext-bks; Sun, 6 Apr 2003 20:02:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3732NJM002798 for ; Sun, 6 Apr 2003 20:02:24 -0700 (PDT) Received: from [10.0.1.6] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id WAA05980; Sun, 6 Apr 2003 22:59:00 -0400 (EDT) Date: Sun, 06 Apr 2003 23:02:24 -0400 From: Cyrus Daboo To: IMAP Extensions WG , IMAP Discusson List Subject: 'Label' flags Message-ID: <2147483647.1049670144@[10.0.1.6]> X-Mailer: Mulberry/3.0.3 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've seen 'in the wild' keywords such as $Label1, $Label2 etc Since I'm in the process of adding keyword support and want to have a fixed set of 'labels' that a user can define I'm interested in knowing whether this is something that should be 'standardised' behaviour to promote interop between clients. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UDlPi2073909 for ; Wed, 30 Apr 2003 06:47:25 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UDlPVX073908 for ietf-imapext-bks; Wed, 30 Apr 2003 06:47:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UDlNi2073903 for ; Wed, 30 Apr 2003 06:47:24 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3UDlBbT019529; Wed, 30 Apr 2003 15:47:12 +0200 To: Arnt Gulbrandsen Cc: Rob Siemborski , Philip Guenther , Harrie Hazewinkel , Michael Fair , IMAP Extensions WG Subject: Re: IMAP Capability and Virtual Domains References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> <6VpYHVNLMn+i5DOZ665vZQ.md5@melkebalanse.gulbrandsen.priv.no> From: Simon Josefsson X-Payment: hashcash 1.2 0:030430:arnt@gulbrandsen.priv.no:645bcb69cdb12b07 X-Hashcash: 0:030430:arnt@gulbrandsen.priv.no:645bcb69cdb12b07 X-Payment: hashcash 1.2 0:030430:rjs3@andrew.cmu.edu:4f0142d4f4107a98 X-Hashcash: 0:030430:rjs3@andrew.cmu.edu:4f0142d4f4107a98 X-Payment: hashcash 1.2 0:030430:guenther@sendmail.com:cf58492e46086358 X-Hashcash: 0:030430:guenther@sendmail.com:cf58492e46086358 X-Payment: hashcash 1.2 0:030430:harrie@inet.it:b7fef978a01ec516 X-Hashcash: 0:030430:harrie@inet.it:b7fef978a01ec516 X-Payment: hashcash 1.2 0:030430:michael@daclubhouse.net:b4b89f492619b544 X-Hashcash: 0:030430:michael@daclubhouse.net:b4b89f492619b544 X-Payment: hashcash 1.2 0:030430:ietf-imapext@imc.org:511cf7fd847f3431 X-Hashcash: 0:030430:ietf-imapext@imc.org:511cf7fd847f3431 Date: Wed, 30 Apr 2003 15:47:11 +0200 In-Reply-To: <6VpYHVNLMn+i5DOZ665vZQ.md5@melkebalanse.gulbrandsen.priv.no> (Arnt Gulbrandsen's message of "Wed, 30 Apr 2003 11:03:03 +0200") Message-ID: User-Agent: Gnus/5.09002 (Oort Gnus v0.20) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen writes: > Rob Siemborski writes: >> On Tue, 29 Apr 2003, Michael Fair wrote: >> >>> I'm still assuming that people on this list are still somewhat >>> dubious about whether or not virtual hosting multiple domains on a >>> single IP address is even useful. >> >> I agree that virtual hosting on a single IP is useful. I'm >> personally unconvinced of the necessity of a VHOST command (or other >> additional argument to CAPABILITY) to do this, its almost entirely >> possible to do this using realms on user ids. > > The realms usage I see in RFC 2831 seems a little different. Realms > there aren't hostnames, and they're used for a multiple-choice > question. Basically, the server tells the client "pick one of these > realms" and the client does, perhaps using a listbox or menu. > > I would not want to give every IMAP client my customer list, > particularly not before authentication. And I would not want to tell > random IMAP clients "here, make a thousand-item pop-up menu and ask > the user to pick one". DIGEST-MD5 allows the realm field in step 1 to be empty, and in this case the client is allowed to chose a realm on their own. DIGEST-MD5 doesn't have to be used as "pick one of these realms". However, if the server sends some realms, the server SHOULD pick one of them. I hoped that 2831bis would allow the client to pick any realm it wants, regardless of what the server sent, thus further moving away from the problem you describe, but this doesn't seem to have happened. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UDNOi2073287 for ; Wed, 30 Apr 2003 06:23:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UDNOlE073286 for ietf-imapext-bks; Wed, 30 Apr 2003 06:23:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UDNHi2073268 for ; Wed, 30 Apr 2003 06:23:20 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp7.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3UDNCrh007015; Wed, 30 Apr 2003 09:23:12 -0400 Date: Wed, 30 Apr 2003 09:23:11 -0400 (EDT) From: Rob Siemborski To: Arnt Gulbrandsen cc: Philip Guenther , Harrie Hazewinkel , Michael Fair , IMAP Extensions WG Subject: Re: IMAP Capability and Virtual Domains In-Reply-To: <6VpYHVNLMn+i5DOZ665vZQ.md5@melkebalanse.gulbrandsen.priv.no> Message-ID: References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> <6VpYHVNLMn+i5DOZ665vZQ.md5@melkebalanse.gulbrandsen.priv.no> 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 Wed, 30 Apr 2003, Arnt Gulbrandsen wrote: > The realms usage I see in RFC 2831 seems a little different. Realms > there aren't hostnames, and they're used for a multiple-choice > question. Basically, the server tells the client "pick one of these > realms" and the client does, perhaps using a listbox or menu. Realms in DIGEST-MD5 are a little strange. But you *can* just append a @ or a % to an authentication identifier, followed by a domain, and call it a realm. This works with a much larger variety of SASL mechanisms. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U92Ni2057469 for ; Wed, 30 Apr 2003 02:02:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U92Nrb057468 for ietf-imapext-bks; Wed, 30 Apr 2003 02:02:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U92Mi2057461 for ; Wed, 30 Apr 2003 02:02:23 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:23717 "ehlo melkebalanse.gulbrandsen.priv.no" ident: "NO-IDENT-SERVICE[2]") by bra.gulbrandsen.priv.no with ESMTP id ; Wed, 30 Apr 2003 11:02:08 +0200 Message-Id: <6VpYHVNLMn+i5DOZ665vZQ.md5@melkebalanse.gulbrandsen.priv.no> From: Arnt Gulbrandsen To: Rob Siemborski Subject: Re: IMAP Capability and Virtual Domains Cc: Philip Guenther , Harrie Hazewinkel , Michael Fair , IMAP Extensions WG References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Wed, 30 Apr 2003 11:03:03 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: > On Tue, 29 Apr 2003, Michael Fair wrote: > >> I'm still assuming that people on this list are still somewhat >> dubious about whether or not virtual hosting multiple domains on a >> single IP address is even useful. > > I agree that virtual hosting on a single IP is useful. I'm personally > unconvinced of the necessity of a VHOST command (or other additional > argument to CAPABILITY) to do this, its almost entirely possible to > do this using realms on user ids. The realms usage I see in RFC 2831 seems a little different. Realms there aren't hostnames, and they're used for a multiple-choice question. Basically, the server tells the client "pick one of these realms" and the client does, perhaps using a listbox or menu. I would not want to give every IMAP client my customer list, particularly not before authentication. And I would not want to tell random IMAP clients "here, make a thousand-item pop-up menu and ask the user to pick one". > The only problem using realms with user IDs doesn't solve is the fact > that you don't know which certificate to present during a STARTTLS. I > suppose this can be solved with an argument to STARTTLS. You'd need > to advertise a new STARTTLS_WITH_DOMAIN capability too. As Simon Josefsson said, the TLS people are dealing with that. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U4Qxi2022244 for ; Tue, 29 Apr 2003 21:26:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U4QxX3022243 for ietf-imapext-bks; Tue, 29 Apr 2003 21:26:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U4Qvi2022238 for ; Tue, 29 Apr 2003 21:26:58 -0700 (PDT) (envelope-from leg+@andrew.cmu.edu) Received: from majormajor.REM.CMU.EDU (DYN-4-221.CC.cmu.edu [128.2.4.221] (may be forged)) (user=leg mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3U4Qvfg021619 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 30 Apr 2003 00:26:57 -0400 Date: Wed, 30 Apr 2003 00:26:31 -0400 From: Lawrence Greenfield To: Timo Sirainen , ned+imapext@INNOSOFT.COM cc: ietf-imapext@imc.org, ned.freed@mrochek.com, hardie@qualcomm.com Subject: Re: Review requested: draft-siemborski-mupdate-03.txt to be published as an experimental RFC Message-ID: <194349820.1051662391@majormajor.REM.CMU.EDU> In-Reply-To: <1051676131.26178.279.camel@hurina> References: <01KVAS4J29VM007FVT@mauve.mrochek.com> <1051676131.26178.279.camel@hurina> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, April 30, 2003 7:15 AM +0300 Timo Sirainen wrote: > Just one question: Is there a reason why this should be RFC? I can see > that specific server implementations might want to use this internally, > but I just can't see why it should be interoperable with anything else > but itself. Would someone actually want to create an IMAP server farm > consisting of completely different IMAP server implementations? The purpose of documenting this isn't necessarily to get interoperable implementations, but to document the protocol and the approach for the future so that the community has a stable reference to an open approach that's been done before. Larry Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U4FWi2022021 for ; Tue, 29 Apr 2003 21:15:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U4FWmj022020 for ietf-imapext-bks; Tue, 29 Apr 2003 21:15:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U4FUi2022015 for ; Tue, 29 Apr 2003 21:15:30 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id B39CF5E107F8; Wed, 30 Apr 2003 07:15:32 +0300 (EEST) Subject: Re: Review requested: draft-siemborski-mupdate-03.txt to be published as an experimental RFC From: Timo Sirainen To: ned+imapext@INNOSOFT.COM Cc: ietf-imapext@imc.org, ned.freed@mrochek.com, hardie@qualcomm.com In-Reply-To: <01KVAS4J29VM007FVT@mauve.mrochek.com> References: <01KVAS4J29VM007FVT@mauve.mrochek.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051676131.26178.279.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 30 Apr 2003 07:15:32 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-04-29 at 22:06, ned+imapext@INNOSOFT.COM wrote: > I've received a request from the author to publish > > The MUPDATE Distributed Mailbox Database Protocol > draft-siemborski-mupdate-03.txt > > as an experimental RFC. It is customary for area directors to ask for > such documents to be reviewed by one or more working groups working in the > same or related area. Accordingly, I'm asking folks involved in IMAPEXT > to review this document and comment on its suitability for publication as > an experimental protocol. Just one question: Is there a reason why this should be RFC? I can see that specific server implementations might want to use this internally, but I just can't see why it should be interoperable with anything else but itself. Would someone actually want to create an IMAP server farm consisting of completely different IMAP server implementations? Or maybe there's some other uses that aren't obvious to me? I had to read Cyrus Aggregator web page before really even understanding how this protocol was supposed to be used. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U2gti2019320 for ; Tue, 29 Apr 2003 19:42:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U2gt2S019319 for ietf-imapext-bks; Tue, 29 Apr 2003 19:42:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U2gri2019313 for ; Tue, 29 Apr 2003 19:42:53 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 3D4FA883DD6; Tue, 29 Apr 2003 19:42:56 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 0BDE78831EB; Tue, 29 Apr 2003 19:42:55 -0700 (PDT) Message-ID: <01e901c30ec2$268376e0$d1d07b43@cocacola> From: "Michael Fair" To: "Simon Josefsson" Cc: "Abhijit Menon-Sen" , References: <019701c30dd9$d6019c80$d1d07b43@cocacola><00fa01c30e21$430c6020$d1d07b43@cocacola><20030430053747.F8948@lustre.dyn.wiw.org><01ac01c30eb6$16088640$d1d07b43@cocacola> Subject: Re: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 19:42:32 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Some environments will chose to not use STARTTLS, so this will never > hold. But some environments would chose to not use VHOST too, so I > don't see the difference. You can't ask for more than that people are > required to implement a feature -- whether it is used or not depends > on other things -- and people are already required to implement > STARTTLS. The difference is that with this proposed solution whether or not someone can use VHOST is completely predicated on whether or not they simultaneously use TLS. With this proposal if you want to use VHOST, you MUST use TLS - no choice - no option - no way around it - either use TLS or don't have per domain specific configs. I find unrealisticly limiting. Whether or not someone uses TLS is a totally separate decision from whether or not the they use virtualized hosting. Especially for domains specific configs that might not want to use TLS for whatever reason. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U1xhi2018177 for ; Tue, 29 Apr 2003 18:59:43 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U1xhTI018176 for ietf-imapext-bks; Tue, 29 Apr 2003 18:59:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U1xfi2018170 for ; Tue, 29 Apr 2003 18:59:42 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3U1xcbT002876; Wed, 30 Apr 2003 03:59:38 +0200 To: "Michael Fair" Cc: "Abhijit Menon-Sen" , Subject: Re: IMAP Capability and Virtual Domains References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <20030430053747.F8948@lustre.dyn.wiw.org> <01ac01c30eb6$16088640$d1d07b43@cocacola> From: Simon Josefsson X-Payment: hashcash 1.2 0:030430:michael@daclubhouse.net:9d08d78c232e46c7 X-Hashcash: 0:030430:michael@daclubhouse.net:9d08d78c232e46c7 X-Payment: hashcash 1.2 0:030430:ams@wiw.org:2eda68a84d553ccf X-Hashcash: 0:030430:ams@wiw.org:2eda68a84d553ccf X-Payment: hashcash 1.2 0:030430:ietf-imapext@imc.org:1fad1990737f6472 X-Hashcash: 0:030430:ietf-imapext@imc.org:1fad1990737f6472 Date: Wed, 30 Apr 2003 03:59:37 +0200 In-Reply-To: <01ac01c30eb6$16088640$d1d07b43@cocacola> (Michael Fair's message of "Tue, 29 Apr 2003 18:16:10 -0700") Message-ID: User-Agent: Gnus/5.09002 (Oort Gnus v0.20) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Michael Fair" writes: >> At 2003-04-30 00:38:48 +0200, jas@extundo.com wrote: >> > >> > Support draft-ietf-tls-extensions-06.txt in your STARTTLS >> > implementation. >> > >> > This is not a IMAP specific problem, so a IMAP specific solution is >> > not the best solution, engineering wise. >> >> I strongly prefer this approach over an optional argument to CAPABILITY, >> or a separate VHOST command, particularly since STARTTLS support is now >> mandatory for both servers and clients. > > I'm afraid I missed the part where the use of STARTTLS became > mandatory. See RFC 3501: Client and server implementations MUST implement the STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS]) capabilities. > Fortunately it's generally accepted that STARTTLS > requires a new CAPABILITY announcement anyway, thus if it can > be shown that all implementations of both clients and servers > not only support but MUST also use STARTTLS whenever it's > available then I'd probably accept this as a solution that > will work. Some environments will chose to not use STARTTLS, so this will never hold. But some environments would chose to not use VHOST too, so I don't see the difference. You can't ask for more than that people are required to implement a feature -- whether it is used or not depends on other things -- and people are already required to implement STARTTLS. This doesn't mean they are required to implement the TLS extension though... > It'd be harder to debug since you will now need to get something > more intelligent than telnet to test against, but I'm sure > there'll be tools to help with that (perhaps even an updated telnet). The tools exists. The problem isn't specific to TLS, some SASL mechanisms also encrypts the connection. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U1GUi2016901 for ; Tue, 29 Apr 2003 18:16:30 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U1GUsg016900 for ietf-imapext-bks; Tue, 29 Apr 2003 18:16:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U1GSi2016895 for ; Tue, 29 Apr 2003 18:16:28 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 1CDC0883DD6; Tue, 29 Apr 2003 18:16:31 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id E8AF88831EB; Tue, 29 Apr 2003 18:16:29 -0700 (PDT) Message-ID: <01ac01c30eb6$16088640$d1d07b43@cocacola> From: "Michael Fair" To: "Abhijit Menon-Sen" , References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <20030430053747.F8948@lustre.dyn.wiw.org> Subject: Re: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 18:16:10 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > At 2003-04-30 00:38:48 +0200, jas@extundo.com wrote: > > > > Support draft-ietf-tls-extensions-06.txt in your STARTTLS > > implementation. > > > > This is not a IMAP specific problem, so a IMAP specific solution is > > not the best solution, engineering wise. > > I strongly prefer this approach over an optional argument to CAPABILITY, > or a separate VHOST command, particularly since STARTTLS support is now > mandatory for both servers and clients. I'm afraid I missed the part where the use of STARTTLS became mandatory. Fortunately it's generally accepted that STARTTLS requires a new CAPABILITY announcement anyway, thus if it can be shown that all implementations of both clients and servers not only support but MUST also use STARTTLS whenever it's available then I'd probably accept this as a solution that will work. It'd be harder to debug since you will now need to get something more intelligent than telnet to test against, but I'm sure there'll be tools to help with that (perhaps even an updated telnet). Currently what's on the table is a Client Capability string. While I disagree that being able to select a VHOST context isn't a capability I'm not really opposed to anything that solves the whole problem. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3U07pi2014990 for ; Tue, 29 Apr 2003 17:07:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3U07p1j014989 for ietf-imapext-bks; Tue, 29 Apr 2003 17:07:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from miranda.org (IDENT:qmailr@miranda.org [209.58.150.153]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3U07oi2014984 for ; Tue, 29 Apr 2003 17:07:51 -0700 (PDT) (envelope-from ams@wiw.org) Received: (qmail 23457 invoked from network); 30 Apr 2003 00:07:50 -0000 Received: from miranda.org (HELO lustre.dyn.wiw.org) (ams@209.58.150.153) by miranda.org with SMTP; 30 Apr 2003 00:07:50 -0000 Received: from ams by lustre.dyn.wiw.org with local (Exim 3.36 #1) id 19Af8V-00039k-00; Wed, 30 Apr 2003 05:37:47 +0530 Date: Wed, 30 Apr 2003 05:37:47 +0530 From: Abhijit Menon-Sen To: ietf-imapext@imc.org Cc: Michael Fair Subject: Re: IMAP Capability and Virtual Domains Message-ID: <20030430053747.F8948@lustre.dyn.wiw.org> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> 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: At 2003-04-30 00:38:48 +0200, jas@extundo.com wrote: > > Support draft-ietf-tls-extensions-06.txt in your STARTTLS > implementation. > > This is not a IMAP specific problem, so a IMAP specific solution is > not the best solution, engineering wise. I strongly prefer this approach over an optional argument to CAPABILITY, or a separate VHOST command, particularly since STARTTLS support is now mandatory for both servers and clients. While a client capability string may be a good idea for other reasons, I don't think a virtual host selection mechanism should be shoehorned into it. It may be quite convenient, but it isn't a capability, and shouldn't be treated as one. -- ams Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNnpi2014600 for ; Tue, 29 Apr 2003 16:49:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TNnpN3014599 for ietf-imapext-bks; Tue, 29 Apr 2003 16:49:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNnni2014592 for ; Tue, 29 Apr 2003 16:49:49 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 16E905E107F8; Wed, 30 Apr 2003 02:49:51 +0300 (EEST) Subject: Re: IMAP Capability and Virtual Domains From: Timo Sirainen To: Michael Fair Cc: Philip Guenther , ietf-imapext@imc.org, Harrie Hazewinkel In-Reply-To: <012d01c30ea2$f6559300$d1d07b43@cocacola> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> <1051653875.26181.251.camel@hurina> <012d01c30ea2$f6559300$d1d07b43@cocacola> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051660190.26181.260.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 30 Apr 2003 02:49:51 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2003-04-30 at 01:59, Michael Fair wrote: > I actually happen to like Cyrus Daboo's latest proposal > of doing something like: > CAPABILITY VHOST=fqdn.example.com RLIST LANGUAGE=en_US,en_GB Fine with me, except that should be more IMAP way to avoid creating new parsers for server: * OK [CLIENTCAPABILITY] (or something) 1 CAPABILITY VHOST (fqdn.example.com) RLIST LANGUAGE (en_US en_GB) Server could just ignore capabilities it isn't interested in. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNC6i2013681 for ; Tue, 29 Apr 2003 16:12:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TNC6RG013680 for ietf-imapext-bks; Tue, 29 Apr 2003 16:12:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TNC5i2013675 for ; Tue, 29 Apr 2003 16:12:05 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 78797883D93; Tue, 29 Apr 2003 16:12:07 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 3CAB78831EB; Tue, 29 Apr 2003 16:12:06 -0700 (PDT) Message-ID: <013f01c30ea4$b735fd20$d1d07b43@cocacola> From: "Michael Fair" To: "Cyrus Daboo" , Cc: "Harrie Hazewinkel" References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <1044733467.1051637254@PLATO.cyrusoft.com> <009a01c30e9a$e5abcd60$d1d07b43@cocacola> <1048623330.1051641144@PLATO.cyrusoft.com> Subject: Re: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 16:11:50 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Hi Michael, > > --On Tuesday, April 29, 2003 3:01 PM -0700 Michael Fair > wrote: > > | The one reservation I have about using a separate VHOST command > | that returns the same response as CAPABILITY is that you've now > | created to commands that do essentailly the exact same thing. > > Fine, but if we are going to extend capability lets do it in a way that > will allow future parameters to be easily added, e.g. use the capability > response syntax for the client command: > > a CAPABILITY VHOST=fqdn.example.com RLIST LANGUAGE=en_US,en_GB That would be great! Servers that don't care can still swallow it, and other perceived usefulness results. Great call! So what do we put in the HELLO response to give the client foreknowledge for accepting the extra info? Should we follow the SMTP example and prepend hello with [ECAPABILITY] and then create an ECAPABILITY command? Or are people comfortable with keeping the same named CAPABILITY command? I'm personally rather partial to not change the command name. But then again, I'm also the one who doesn't mind a client trying and failing as a method for determining whether or not this server supports what will be the norm. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMxXi2013414 for ; Tue, 29 Apr 2003 15:59:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TMxX56013413 for ietf-imapext-bks; Tue, 29 Apr 2003 15:59:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMxWi2013408 for ; Tue, 29 Apr 2003 15:59:32 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 216F9883D93; Tue, 29 Apr 2003 15:59:34 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id E19408831EB; Tue, 29 Apr 2003 15:59:32 -0700 (PDT) Message-ID: <012d01c30ea2$f6559300$d1d07b43@cocacola> From: "Michael Fair" To: "Timo Sirainen" Cc: "Philip Guenther" , , "Harrie Hazewinkel" References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> <1051653875.26181.251.camel@hurina> Subject: Re: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 15:59:17 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On Tue, 2003-04-29 at 23:51, Michael Fair wrote: > > But you also mentioned PREAUTH the and intitial OK. Let's talk > > about the initial OK for a second. This is acutally pretty cool > > and something I hadn't thought about. If we leave VHOST as part > > of the CAPABILITY announcement we can preinform a client about > > whether or not the server supports domain specific configs. > > This sounds good to me. To save some roundtrips, it could include > capability in it's reply as well: > > * OK [VHOST] IMAP server ready. > 1 VHOST foo.bar.org > 1 OK [CAPABILITY IMAP4rev1 ...] > 2 STARTTLS > 2 OK > ..etc.. If you're going to bother with a VHOST command that returns a CAPABILITY response why not just add it to CAPABILITY and make the argument valid SOLELY in the presence of a preannounced VHOST capability. It keeps the command set down and reduces the number of different commands that essentially do the exact same things. For instance, what's the difference between the above and: * OK [VHOST] IMAP server ready. 1 CAPABILITY foo.bar.org 1 OK [CAPABILITY IMAP4rev1 ...] 2 STARTTLS 2 OK ..etc.. I actually happen to like Cyrus Daboo's latest proposal of doing something like: CAPABILITY VHOST=fqdn.example.com RLIST LANGUAGE=en_US,en_GB -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMhYi2013088 for ; Tue, 29 Apr 2003 15:43:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TMhY1G013087 for ietf-imapext-bks; Tue, 29 Apr 2003 15:43:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-in.rrz.uni-koeln.de (smtp-in.rrz.Uni-Koeln.DE [134.95.19.47]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMhWi2013081 for ; Tue, 29 Apr 2003 15:43:33 -0700 (PDT) (envelope-from Hagedorn@spinfo.uni-koeln.de) Received: from [192.168.1.11] (xdsl-213-168-110-58.netcologne.de [213.168.110.58]) (authenticated as user a0620 using DIGEST-MD5 bits=0) by cyrus.rrz.uni-koeln.de (8.12.9/8.12.8) with ESMTP id h3TMhRXM031140; Wed, 30 Apr 2003 00:43:28 +0200 Date: Wed, 30 Apr 2003 00:43:25 +0200 From: Sebastian Hagedorn To: Michael Fair cc: ietf-imapext@imc.org Subject: Re: IMAP Capability and Virtual Domains Message-ID: <2147483647.1051663404@[192.168.1.11]> In-Reply-To: <007a01c30e91$1a391060$d1d07b43@cocacola> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> X-Mailer: Mulberry/3.0.3 (Mac OS X) Message-Context: text-message X-Spook: nuclear nuke spy secret assassination cia fbi nsa president MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2147493761==========" X-Virus-Scanned: by amavisd-new Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==========2147493761========== Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline -- Michael Fair is rumored to have mumbled on=20 Dienstag, 29. April 2003 13:51 Uhr -0700 regarding Re: IMAP Capability and=20 Virtual Domains : > For instance Outlook[ Express] only supports LOGIN. I wouldn't > want to enable that except for domains that required it. Just FYI: the most recent versions of Cyrus SASL and Cyrus IMAP offer NTLM=20 as an option, which is working pretty well with Outlook (Express) in my=20 experience. I know, it's not a standard, but if I have to choose between=20 LOGIN and that I prefer the latter ... Cheers, Sebastian -- Sebastian Hagedorn M.A. - Postmaster - RZKR-R1 (Flachbau), Zimmer 18 Zentrum f=FCr angewandte Informatik - Universit=E4tsweiter Service RRZK Universit=E4t zu K=F6ln / Cologne University - Tel. +49-221-478-5587 --==========2147493761========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iEYEARECAAYFAj6vAA4ACgkQGXsGmU0QW0W7zgCfev1scFMF8qA+6xH7M6Zp2sOX s/UAoMiqjEo49l8lt0td7mc0c2114TBF =eMBf -----END PGP SIGNATURE----- --==========2147493761==========-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMcri2013003 for ; Tue, 29 Apr 2003 15:38:53 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TMcrL8013002 for ietf-imapext-bks; Tue, 29 Apr 2003 15:38:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMcpi2012997 for ; Tue, 29 Apr 2003 15:38:52 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3TMcmbU030724 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 30 Apr 2003 00:38:48 +0200 To: "Michael Fair" Cc: , "Harrie Hazewinkel" Subject: Re: IMAP Capability and Virtual Domains References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> From: Simon Josefsson X-Payment: hashcash 1.2 0:030429:michael@daclubhouse.net:7f98a53897e5613a X-Hashcash: 0:030429:michael@daclubhouse.net:7f98a53897e5613a X-Payment: hashcash 1.2 0:030429:ietf-imapext@imc.org:a3b86b153f8cb5fd X-Hashcash: 0:030429:ietf-imapext@imc.org:a3b86b153f8cb5fd X-Payment: hashcash 1.2 0:030429:harrie@inet.it:bb0403a57b95afd6 X-Hashcash: 0:030429:harrie@inet.it:bb0403a57b95afd6 Date: Wed, 30 Apr 2003 00:38:48 +0200 In-Reply-To: <00fa01c30e21$430c6020$d1d07b43@cocacola> (Michael Fair's message of "Tue, 29 Apr 2003 00:30:46 -0700") Message-ID: User-Agent: Gnus/5.09002 (Oort Gnus v0.20) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-29.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Michael Fair" writes: > The problem with this solution is that there are several > things that happen before LOGIN or AUTH where knowing the > domain would be useful. Namely STARTTLS and CAPABILITY. Support draft-ietf-tls-extensions-06.txt in your STARTTLS implementation. This is not a IMAP specific problem, so a IMAP specific solution is not the best solution, engineering wise. A good authentication mechanism should have a means to allow clients to chose a "realm" they belong to. DIGEST-MD5 have this, as does the experimental KERBEROS_V5. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMXvi2012936 for ; Tue, 29 Apr 2003 15:33:57 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TMXvY8012935 for ietf-imapext-bks; Tue, 29 Apr 2003 15:33:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMXui2012930 for ; Tue, 29 Apr 2003 15:33:56 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from PLATO.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id SAA15394; Tue, 29 Apr 2003 18:27:45 -0400 (EDT) Date: Tue, 29 Apr 2003 18:32:24 -0400 From: Cyrus Daboo To: Michael Fair , ietf-imapext@imc.org cc: Harrie Hazewinkel Subject: Re: IMAP Capability and Virtual Domains Message-ID: <1048623330.1051641144@PLATO.cyrusoft.com> In-Reply-To: <009a01c30e9a$e5abcd60$d1d07b43@cocacola> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <1044733467.1051637254@PLATO.cyrusoft.com> <009a01c30e9a$e5abcd60$d1d07b43@cocacola> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Michael, --On Tuesday, April 29, 2003 3:01 PM -0700 Michael Fair wrote: | The one reservation I have about using a separate VHOST command | that returns the same response as CAPABILITY is that you've now | created to commands that do essentailly the exact same thing. Fine, but if we are going to extend capability lets do it in a way that will allow future parameters to be easily added, e.g. use the capability response syntax for the client command: a CAPABILITY VHOST=fqdn.example.com RLIST LANGUAGE=en_US,en_GB -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMFIi2012545 for ; Tue, 29 Apr 2003 15:15:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TMFIpH012544 for ietf-imapext-bks; Tue, 29 Apr 2003 15:15:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TMFHi2012539 for ; Tue, 29 Apr 2003 15:15:17 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 51922883D93; Tue, 29 Apr 2003 15:15:19 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 12242812FF5; Tue, 29 Apr 2003 15:15:18 -0700 (PDT) Message-ID: <00d701c30e9c$c8980980$d1d07b43@cocacola> From: "Michael Fair" To: "Rob Siemborski" Cc: "Philip Guenther" , , "Harrie Hazewinkel" References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> Subject: Re: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 15:15:03 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Well, I've sort of been interested in a client-side capability string (how > does a server know that a client supports referrals if it doesn't execute > an RLIST first, for example?). In the case of referrals though, I suppose > an [L01 RLIST "" ""] is just as good as a client-side capability string, > since clients don't currently support it anyway. If a client side capability string would be something that would be generally useful, I would certainly be one of its supporters. It's one of those things that seems like it would be generally useful to me and would become more useful over time as people found ways to do things they previously couldn't, but that is more theory than fact at this point. If there are convincing enough arguments to sway the protocol designers to include, then I would propose the VHOST functionality be moved as part of that functionality. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TM4ai2012371 for ; Tue, 29 Apr 2003 15:04:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TM4a5D012370 for ietf-imapext-bks; Tue, 29 Apr 2003 15:04:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TM4Yi2012365 for ; Tue, 29 Apr 2003 15:04:34 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id E12745E107F8; Wed, 30 Apr 2003 01:04:35 +0300 (EEST) Subject: Re: IMAP Capability and Virtual Domains From: Timo Sirainen To: Michael Fair Cc: Philip Guenther , ietf-imapext@imc.org, Harrie Hazewinkel In-Reply-To: <007a01c30e91$1a391060$d1d07b43@cocacola> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051653875.26181.251.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 30 Apr 2003 01:04:35 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-04-29 at 23:51, Michael Fair wrote: > But you also mentioned PREAUTH the and intitial OK. Let's talk > about the initial OK for a second. This is acutally pretty cool > and something I hadn't thought about. If we leave VHOST as part > of the CAPABILITY announcement we can preinform a client about > whether or not the server supports domain specific configs. This sounds good to me. To save some roundtrips, it could include capability in it's reply as well: * OK [VHOST] IMAP server ready. 1 VHOST foo.bar.org 1 OK [CAPABILITY IMAP4rev1 ...] 2 STARTTLS 2 OK ..etc.. Non-vhost capable client simply works as before. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TM3ci2012341 for ; Tue, 29 Apr 2003 15:03:38 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TM3c9G012340 for ietf-imapext-bks; Tue, 29 Apr 2003 15:03:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TM3bi2012335 for ; Tue, 29 Apr 2003 15:03:37 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from UNIX46.andrew.cmu.edu (UNIX46.andrew.cmu.edu [128.2.13.176]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3TM3Zdg030378; Tue, 29 Apr 2003 18:03:35 -0400 Date: Tue, 29 Apr 2003 18:03:34 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: IMAP Extensions WG Subject: Re: IMAP Capability and Virtual Domains In-Reply-To: Message-ID: References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> 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, 29 Apr 2003, Mark Crispin wrote: > On Tue, 29 Apr 2003, Rob Siemborski wrote: > > In the case of referrals though, I suppose > > an [L01 RLIST "" ""] is just as good as a client-side capability string, > > since clients don't currently support it anyway. > > Clients don't currently support referrals? > > That's news to me; Pine has supported referrals for years. Sorry, I meant to say that the protocol doesn't currently support a client-side capability string, so for the case of mailbox referrals, a client-side capability string is just as good as sending RLIST "" "". -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TM1mi2012286 for ; Tue, 29 Apr 2003 15:01:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TM1lRq012285 for ietf-imapext-bks; Tue, 29 Apr 2003 15:01:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TM1ki2012280 for ; Tue, 29 Apr 2003 15:01:46 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id B9DF9883D93; Tue, 29 Apr 2003 15:01:48 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 49250812FF5; Tue, 29 Apr 2003 15:01:47 -0700 (PDT) Message-ID: <009a01c30e9a$e5abcd60$d1d07b43@cocacola> From: "Michael Fair" To: "Cyrus Daboo" , Cc: "Harrie Hazewinkel" References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <1044733467.1051637254@PLATO.cyrusoft.com> Subject: Re: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 15:01:32 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Here is what I propose as an alternative, assuming VHOST is going to be > implemented: > > 1) A VHOST aware server returns VHOST as the only capability in the > response code for the greeting string. This avoids the server having to > advertise any capabilites before its got the VHOST. But this also kills the servers ability to be backwards compatible and offer a "default domain" which would be the equivalent of whatever its pre-VHOST mail store mailboxes were. You can still put VHOST in the response code of the greeting string and it will still be useful, but I would augment this to say that it would be included as one of the capabilities listed (but still possibly the only one for a VHOST only environment). > 2) A VHOST aware client that sees VHOST in the greeting capability MUST > immediately issue a VHOST command with the server fqdn as a parameter. > > 3) The server responds to the command with a full capability response > listing the capabilites now available for that virtual domain. This simple creates an alternate CAPABILITY command. How about we keep (1) as augmented above, but for 2 use: 2) A VHOST aware client that sees CHOST in the greeting capability MUST immediately issue a CAPABILITY command with the server fqdn as a parameter. A client MUST NOT issue an argument to CAPABILITY if it has not previously seen a VHOST capability. The one reservation I have about using a separate VHOST command that returns the same response as CAPABILITY is that you've now created to commands that do essentailly the exact same thing. I don't mind requiring servers to announce VHOST as part of the greeting response at all. I like the feature and if that is what it takes to satisfy a "client always has foreknowledge" semantic. Then I can live with that. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLqoi2012017 for ; Tue, 29 Apr 2003 14:52:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TLqo36012016 for ietf-imapext-bks; Tue, 29 Apr 2003 14:52:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLqni2012011 for ; Tue, 29 Apr 2003 14:52:49 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3TLqiRG008591; Tue, 29 Apr 2003 14:52:49 -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+UW03.04/8.12.1+UW02.12) with ESMTP id h3TLqhQ0031115 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Apr 2003 14:52:44 -0700 Date: Tue, 29 Apr 2003 14:52:45 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: IMAP Extensions WG Subject: Re: IMAP Capability and Virtual Domains In-Reply-To: Message-ID: References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> 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, 29 Apr 2003, Rob Siemborski wrote: > In the case of referrals though, I suppose > an [L01 RLIST "" ""] is just as good as a client-side capability string, > since clients don't currently support it anyway. Clients don't currently support referrals? That's news to me; Pine has supported referrals for years. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLjAi2011849 for ; Tue, 29 Apr 2003 14:45:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TLjA5o011848 for ietf-imapext-bks; Tue, 29 Apr 2003 14:45:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLj8i2011841 for ; Tue, 29 Apr 2003 14:45:08 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3TLj2SL013547; Tue, 29 Apr 2003 14:45:07 -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+UW03.04/8.12.1+UW02.12) with ESMTP id h3TLj1Q0030340 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Apr 2003 14:45:01 -0700 Date: Tue, 29 Apr 2003 14:45:03 -0700 (Pacific Daylight Time) From: Mark Crispin To: Cyrus Daboo cc: IMAP Extensions WG Subject: Re: IMAP Capability and Virtual Domains In-Reply-To: <1044733467.1051637254@PLATO.cyrusoft.com> Message-ID: References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <1044733467.1051637254@PLATO.cyrusoft.com> 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, 29 Apr 2003, Cyrus Daboo wrote: > Other issues not withstanding, I do not like the idea of an optional > argument to capability, or using a VHOST command before issuing capability. Agreed, for the reasons you state. > 1) A VHOST aware server returns VHOST as the only capability in the > response code for the greeting string. This avoids the server having to > advertise any capabilites before its got the VHOST. No good. A VHOST-unaware client will issue a plaintext LOGIN command unless the client itself was configured not to do such a thing. That gets into including LOGINDISABLED, which in turn results in other implications. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLWvi2011576 for ; Tue, 29 Apr 2003 14:32:57 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TLWv9P011575 for ietf-imapext-bks; Tue, 29 Apr 2003 14:32:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLWti2011570 for ; Tue, 29 Apr 2003 14:32:55 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from BBOARD.andrew.cmu.edu (BBOARD.andrew.cmu.edu [128.2.11.39]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3TLWrfg003330; Tue, 29 Apr 2003 17:32:54 -0400 Date: Tue, 29 Apr 2003 17:32:53 -0400 (EDT) From: Rob Siemborski To: Michael Fair cc: Philip Guenther , ietf-imapext@imc.org, Harrie Hazewinkel Subject: Re: IMAP Capability and Virtual Domains In-Reply-To: <007a01c30e91$1a391060$d1d07b43@cocacola> Message-ID: References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <007a01c30e91$1a391060$d1d07b43@cocacola> 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, 29 Apr 2003, Michael Fair wrote: > I'm still assuming that people on this list are still > somewhat dubious about whether or not virtual hosting > multiple domains on a single IP address is even useful. I agree that virtual hosting on a single IP is useful. I'm personally unconvinced of the necessity of a VHOST command (or other additional argument to CAPABILITY) to do this, its almost entirely possible to do this using realms on user ids. The only problem using realms with user IDs doesn't solve is the fact that you don't know which certificate to present during a STARTTLS. I suppose this can be solved with an argument to STARTTLS. You'd need to advertise a new STARTTLS_WITH_DOMAIN capability too. [As an aside, when I worked for a web hosting firm back in '97-99, I know we were using an IP-per-domain for HTTPS. Is this still the case? (I don't immediately know of any new solutions but I could be wrong).] Of course, you now have an issue where some of your customers may not be able to advertise STARTTLS (they don't have certs, and don't want junk certs). Maybe its good enough just to respond NO when these clients try to do STARTTLS "badcustomer.com" I agree with Cyrus's comments that placing a requirement that the client assume a server supports something before issuing a CAPABILITY command is bad. > I'll tell you what would be even more useful is just a > general command where the client can pass a set of > generic key value pairs to inform the server of generic > session parameters where clients and servers can be > modified to look for and send arbitrary info. Well, I've sort of been interested in a client-side capability string (how does a server know that a client supports referrals if it doesn't execute an RLIST first, for example?). In the case of referrals though, I suppose an [L01 RLIST "" ""] is just as good as a client-side capability string, since clients don't currently support it anyway. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLQei2011367 for ; Tue, 29 Apr 2003 14:26:40 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TLQefo011366 for ietf-imapext-bks; Tue, 29 Apr 2003 14:26:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TLQdi2011361 for ; Tue, 29 Apr 2003 14:26:39 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from PLATO.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA14922; Tue, 29 Apr 2003 17:22:55 -0400 (EDT) Date: Tue, 29 Apr 2003 17:27:34 -0400 From: Cyrus Daboo To: Michael Fair , ietf-imapext@imc.org cc: Harrie Hazewinkel Subject: Re: IMAP Capability and Virtual Domains Message-ID: <1044733467.1051637254@PLATO.cyrusoft.com> In-Reply-To: <00fa01c30e21$430c6020$d1d07b43@cocacola> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Michael, --On Tuesday, April 29, 2003 12:30 AM -0700 Michael Fair wrote: | I had an offline discussion with Mark Crispin and proposed | adding the domain name as an optional parameter to CAPABILITY. | | My assumption was that the very first thing an IMAP client | is going to do (even before STARTTLS) is CAPABILITY to find | out if the server can even do STARTTLS and to figure out | what methods of authentication the server makes available. Other issues not withstanding, I do not like the idea of an optional argument to capability, or using a VHOST command before issuing capability. If you do that, how is a client to know that that is a valid thing to do with that server? The user would have to provide some configuration switch to enable it and that requires one extra step for the user that should be avoided. Here is what I propose as an alternative, assuming VHOST is going to be implemented: 1) A VHOST aware server returns VHOST as the only capability in the response code for the greeting string. This avoids the server having to advertise any capabilites before its got the VHOST. 2) A VHOST aware client that sees VHOST in the greeting capability MUST immediately issue a VHOST command with the server fqdn as a parameter. 3) The server responds to the command with a full capability response listing the capabilites now available for that virtual domain. This goes like: s: * OK [CAPABILITY imap4rev1 VHOST] c: a VHOST fqdn.example.com s: * CAPABILITY imap4rev1 starttls logindisabled auth=gssapi s: a OK I believe this approach minimises round trips and doesn't require the client to guess as to whether an extended capability command is present or not. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TKphi2009904 for ; Tue, 29 Apr 2003 13:51:43 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TKphXG009903 for ietf-imapext-bks; Tue, 29 Apr 2003 13:51:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TKpei2009897 for ; Tue, 29 Apr 2003 13:51:41 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id B92D7883D93; Tue, 29 Apr 2003 13:51:42 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 539BA8831EB; Tue, 29 Apr 2003 13:51:38 -0700 (PDT) Message-ID: <007a01c30e91$1a391060$d1d07b43@cocacola> From: "Michael Fair" To: "Philip Guenther" Cc: , "Harrie Hazewinkel" References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> Subject: Re: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 13:51:22 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-9.2 required=5.0 tests=OFFERS_ETC,QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > There are three 'issues' that the VHOST capability claims to address: > 1) the ad-hoc interpretation of authentication IDs as specifying user > and domain > 2) the ability to have domain-specific capability lists > 3) the choice of STARTTLS certificate by the server > > In my opinion, the first of these is a non-issue in practice. Indeed, > the VHOST extension leaves the client author in a sticky situation: if > it accepts the authentication ID as a single value ready for presenting > to LOGIN (or AUTHENTICATE PLAIN/CRAM-MD5/etc), then it must decide and > document how it splits that into a domain for VHOST and a username for > LOGIN. If it accepts the authentication ID as separate domain and user > values, then it must guess how to join them for non-VHOST-enabled > servers, or have another configuration parameter for _that_. The VHOST > extension would also need to specify how it affects and/or operates with > SASL mechanisms that convey the user's domain separate from their > username. The first of these is not a non-issue, but I grant is more of a minor annoyance than an issue. However, it forces administrators to dictate certain parts of customer usernames, where our preference would be to allow the customers to have complete control over that namespace. It save us and them time (and money). As for the client detecting the domain name, the client wouldn't split anything. Whatever was specified in the "IMAP server" field would be presented wholesale without modification as the FQDN for the VHOST or CAPABILITY argument to specify the targetted domain. It's a server and admin issue to make sure that whatever the client has as its server address is appropriately mapped internally. Think HTTP 1.1 and Apache Name Based Virtual Hosts if you have any experience with that. The servername is presented unmodified as part of the header to the request. > The second issue appears minor to me. Is it more than a matter of > differing domains being allowed different SASL mechanisms? Is that a > practical problem? This question is equivalent to "Why should any server ever offer a different CAPABILITY line?" Think ISP, think a 1,000 unique domains all on one IP, think 600 or more different companies all being hosted on the same machine. Each of those 1,000 domains deserves to be treated as if it had its own dedicated server. That currently requires 1,000 IP addresses. The goal here is simply to give the IMAP server the name of the server the client was trying to reach as early as possible so it can look up a config for that server and present it. Each domain should be as independantly configurable as a standalone server would be (with the exception of anything that happens on the wire before the client has a chance to speak). However, to address your direct question about the second issue, most of it surrounds SASL mechanisms, but tuning CAPABILITY based on the preferred clients in each domain is also an issue. Oftentimes the only way to get the desired behavior is to add or remove things from the CAPABILITY line. Other times, you don't want to offer certain CAPABILITY options unless you absolutely have to. For instance Outlook[ Express] only supports LOGIN. I wouldn't want to enable that except for domains that required it. > I agree that the third issue is a real problem. IMHO, STARTTLS would > have been better defined to take an "fqdn" argument that the server > could use to decide which certificate to use. An extension that did > only that---add an optional domain argument to STARTTLS---would appear > to provide most of the benefits of VHOST. I agree that STARTTLS would be better if the only issue were choosing a certificate. Perhaps the proposal should be expanded to add an argument to both CAPABILITY and STARTTLS. I chose CAPABILITY because the domain is is needed for all three issues listed, not just (3). I personally figure if you're going to bother fixing, you should look into fixing all of it not just propping up the most important piece. The cost of adding an argument is the same whether it is to STARTTLS or to CAPABILITY or to adding a new command. Things break, or you get more round trips. My goal was to get the server the info as early as possible. Not all clients issue a STARTTLS, nor should all be required to issue a STARTTLS just to get per domain information. If all clients issued a STARTTLS then I agree adding a domain argument to STARTTLS would solve the problem. However, not all clients do that. But, all clients do issue a CAPABILITY. Adding a domain argument to that would solve the problem neatly. I will address the "two round trips for failure" below. > It seems to me that the CAPABILITY command is ill-suited for such > treatment. If the client already has the server's list of capabilities > and therefore knows that the server supports the extension, then > overloading the CAPABILITY command doesn't save you anything. Right, adding a domain argument to CAPABILITY is intended to completely replace VHOST. A client would issue the extended version and fall back in the event of BAD. If this was just to figure out if the server supported the VHOST command then addidng a domain argument to CAPABILITY would be senseless. My goal with adding the domain argument to CAPABILITY is to reduce the number of round trips a client has to make. > If the > client doesn't already have the server's list of capabilities, then the > client will have to either try the extended version and fallback on BAD, > or send an unextended request with a followup if the capability is > advertised, either way requiring two roundtrips against some set of > servers. Leaving the VHOST command separate from CAPABILITY while > strengthing the recommendation that the server include a CAPABILITY > response code in the initial PREAUTH or OK response and that clients > recognize such would appear to be a simpler and cleaner approach. You seem to think that making clients issue a separate VHOST coammdn "two round trips for some set of servers". You've just inverted the set of servers that's all. I think it's fair to say that clients and servers of any proposal accepted would gravitate towards supporting it as long as it cost them very little to add (which I have explicity designed the proposal for). First, if we added a domain argument to CAPABILITY, then as my proposal suggested, servers could be modified to simply swallow it and go about their business. So supporting the argument is really trivial. It does require a code change, and it does require a release of a new server version which will take some time. So between now and then we have all the existing code that responds with "BAD" which is, and will remain, a correct response for servers that don't support the VHOST capability. In general, the clients that support this feature aren't going to be used against the servers that don't unless most future versions of clients decide they should support this (which then makes a compelling case for servers to at least swallow the argument), however there will be plenty of exceptions and for a time these clients will get a BAD response from those servers. Those exceptions will need to make two round trips, but over time those exceptions will become fewer. If you're interested in optimizing bandwidth, it quickly becomes very clear that, if accepted, the general trend of servers and clients will be to support the added domain argument to CAPABILITY (or some other proposal that provides equivalent functionality). It costs servers nothing but a little "ignore the argument" code. It costs clients some "tack the server name on" code, and if the response is "BAD" or "NO" then give up. Granted those are the bare minimums for compliance, but they are fairly trivial. But you also mentioned PREAUTH the and intitial OK. Let's talk about the initial OK for a second. This is acutally pretty cool and something I hadn't thought about. If we leave VHOST as part of the CAPABILITY announcement we can preinform a client about whether or not the server supports domain specific configs. Very cool! I'll be suggesting that in to my proposal. Originally I had intended on not doing anything with the CAPABILITY line because I wasn't thinking that a server could just announce its CAPABILITY without the client requesting it. But now we need to decide between a separate VHOST command or an argument to CAPABILITY? Here's a test case: Client shows up at the server, the server dumps a CAPABILITY line down its throat the client sees a VHOST option, or the Client shows up at the server, the server gives some kind of hello and the Client is unaware of whether or not the server supports the VHOST capability. It then ..... A) [issues a CAPABILITY and looks for VHOST (if unknown)] issues a VHOST command then issues another CAPABILITY or B) isssues a CAPABILITY with a domain argument [issues a CAPABILITY without a domain argument (if BAD)] The only other proposal that would obviate the need for a VHOST command to require a separate round trip would be if VHOST returned the same response as CAPABILITY. But now you've created two commands that do the exact same thing and for what? To protect existing servers from having to trip over a malformed CAPABILITY line that the servers are already prepared to ignore and that over time will learn to accept (even if they just ignore the argument which they are perfectly allowed to do). > ... > >As an added bonus, this also lays the groundwork for > >some future planning on replicating and scaling IMAP > >mail stores to span multiple mail stores to provide > >geograhic redundancy. Without this feature the "IP burn > >rate" jumps to 1+N addresses per domain where N is the > >number of geographically redundant mail stores. > > I don't understand how geographically redundant mail stores are helped > out any more than any set of N mail stores that offer STARTTLS. If the > problem is the requirement for separate IPs for STARTTLS, then giving > STARTTLS an optional argument would "lower the burn rate" just as much > as VHOST or "CAPABILITY domain", no? Again you are somehow assuming that every conversation with every IMAP server issues a STARTTLS. An IMAP server doesn't even have to offer STARTTLS, most do because it's a good idea, but then you've got the same optional aspect on the client side. The real point is being able to connect to an IMAP server and identify what domain context you want the conversation to occur in. If STARTTLS were as ubiquitous as CAPABILITY and EVERY SESSION issued one, then I'd agree. But it's not. I also really don't understand why you would favor STARTTLS over CAPABILITY? It makes no sense to me. STARTTLS is only issued in the context of creating a secure connection, CAPABILITY is always offered. STARTTLS is discovered post CAPABILITY, so why not do it at the first opportunity? Further, whether or not STARTTLS is even offered may depend completely on what domain the client was trying to reach. (For instance if the customer hasn't provided a security certificate to be used, then why should the server offer that domain STARTTLS functionality?) The point is to let the server switch configurations based on the targetted domain. STARTTLS doesn't give us that because it isn't gauranteed to be issued. CAPABILITY and VHOST are both gauranteed to be issued if the client supports it. An argument to STARTTLS, or an argument to CAPABILITY sounds like six of one half a dozen of the other, it's still an extra argument that gets added to something that currently doesn't take one. You've dismissed the first two benefits of the three as not needed and then based on that came up with "oh only STARTTLS is needed" where for no extra cost (since you gotta add something somewhere), if we add it to CAPABILITY we get all three. Those of us who have actually had to deal with the issue, which by your dismissal of points 1 and 2 makes it obvious you haven't seriously had to deal with it, believe 1 and 2 are important and have suggested a solution which comes out to costing the same as an argument to STARTTLS, and provides the same benefit as an argument to STARTTLS, but also provides extra benefits that an argument to STARTTLS doesn't offer us (otherwise we probably would have proposed it that way to begin with). While I will certainly agree that STARTTLS and SASL mechanisms are the primary purposes, there are other secondary gripes that get handled by doing it via a VHOST or argument to CAPABILITY. I personally think that even VHOST is a waste. It gives us nothing that an argument to CAPABILITY doesn't give us, and it mandates extra round trips. An argument to CAPABILITY only causes _one_ extra round trip during the transitional period where new clients try and access servers that haven't been updated to ignore the argument yet. If you haven't had to deal with hosting lots of domains on a limit number of IPs then please don't assume you know what the issues are and what's important and what's not. I've tried to make the proposal as simple as possible _but no simpler_ to get the information we need. I'm more than willing to explain and educate, and there is a very large list of other things that you can start doing once you have this type of functionality that I'm refraining from mentioning because I believe that giving a huge laundry list of minor nice-to-haves distracts from the core issues. For instance one "nice-to-have" is to aggregate multiple domains to act as one single domain. Why? you ask.. It doesn't matter. If you've been there you'd get it, and you haven't then you don't really need to know. All you need to know is that being able to aggregate multiple domain names together to act as a single group is useful. Not as useful as being able to make every domain its own unique entity, and certainly not something all servers are going to support, but for those people who need the functionality, they're grateful that the protocol built in a space for a few extra bytes of information where the client can announce the server it was trying to reach. I'm still assuming that people on this list are still somewhat dubious about whether or not virtual hosting multiple domains on a single IP address is even useful. If that's still the case, then I'll be more than happy to take arguments and suggestions to find some other way to solve the problem until we can all agree. Believe me when I say I'll be more than happy to listen because if there is a way around it then hopefully it can be applied to lots of protocols that lack this support, not just IMAP and the host providers of the world won't have to wait for new versions of clients and servers before they can start rolling this out. However, I'll warn you, I've been working on the problem for six years, I've worked with lots of really smart networking engineers and system administrators who have also been working on it for several years (some longer than I have), and so far, no one in the entire hosting industry has been unable to find a generally useful solution that isn't based on the protocol providing a special place where the intended server name is provided. I'll tell you what would be even more useful is just a general command where the client can pass a set of generic key value pairs to inform the server of generic session parameters where clients and servers can be modified to look for and send arbitrary info. Kind of like the "X-" headers in SMTP. That way the server name could be stuffed into one of those, and it would not require a protocol change... A simple formal registry could maintain the most useful and widely accepted options that clients and server normally adopt. However, it's not clear to me the overall usefulness of the feature, whether it should be unidriectional or bidirectional, and how complicated the command should be. So for now, I'd be more than happy with just a server name submitted by the client to the server as early as possible during the conversation. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TJ8ii2006804 for ; Tue, 29 Apr 2003 12:08:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TJ8iGp006803 for ietf-imapext-bks; Tue, 29 Apr 2003 12:08:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TJ8ai2006796 for ; Tue, 29 Apr 2003 12:08:43 -0700 (PDT) (envelope-from ned+imapext@innosoft.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KVAIFWGJSW007FVT@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Tue, 29 Apr 2003 12:08:29 -0700 (PDT) Date: Tue, 29 Apr 2003 12:06:17 -0700 (PDT) From: ned+imapext@INNOSOFT.COM Subject: Review requested: draft-siemborski-mupdate-03.txt to be published as an experimental RFC To: ietf-imapext@imc.org Cc: ned.freed@mrochek.com, hardie@qualcomm.com Message-id: <01KVAS4J29VM007FVT@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've received a request from the author to publish The MUPDATE Distributed Mailbox Database Protocol draft-siemborski-mupdate-03.txt as an experimental RFC. It is customary for area directors to ask for such documents to be reviewed by one or more working groups working in the same or related area. Accordingly, I'm asking folks involved in IMAPEXT to review this document and comment on its suitability for publication as an experimental protocol. TIA. Ned P.S. I have already sent the author some feedback on missing boilerplate and other formalities. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3THANi2001758 for ; Tue, 29 Apr 2003 10:10:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3THAN3u001757 for ietf-imapext-bks; Tue, 29 Apr 2003 10:10:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3THAMi2001752 for ; Tue, 29 Apr 2003 10:10:22 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA12428; Tue, 29 Apr 2003 13:05:55 -0400 (EDT) Date: Tue, 29 Apr 2003 13:09:24 -0400 From: Cyrus Daboo To: Timo Sirainen , Philip Guenther cc: Michael Fair , ietf-imapext@imc.org, Harrie Hazewinkel Subject: Re: IMAP Capability and Virtual Domains Message-ID: <2147483647.1051621764@[63.163.82.24]> In-Reply-To: <1051634342.26178.240.camel@hurina> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> <1051634342.26178.240.camel@hurina> X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Timo, --On Tuesday, April 29, 2003 7:39 PM +0300 Timo Sirainen wrote: | Related to 2, I've thought about giving different capability lists per | user. Couldn't both of these be solved by letting server reply with | untagged CAPABILITY reply (or resp-text-code) after login? All clients | might not update their lists, but that's better than having | extra/missing capabilities listed. rfc3501 already states that servers may send a capability response code in the tagged OK to the AUTHENTICATE command. Servers can also send the capability response code in the greeting response too. If both of those are implemented, then a client would only need to use the CAPABILITY command after STARTTLS. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TGdGi2000691 for ; Tue, 29 Apr 2003 09:39:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TGdGoS000690 for ietf-imapext-bks; Tue, 29 Apr 2003 09:39:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TGd9i2000683 for ; Tue, 29 Apr 2003 09:39:10 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 2D1245E107F8; Tue, 29 Apr 2003 19:39:03 +0300 (EEST) Subject: Re: IMAP Capability and Virtual Domains From: Timo Sirainen To: Philip Guenther Cc: Michael Fair , ietf-imapext@imc.org, Harrie Hazewinkel In-Reply-To: <200304291140.h3TBeCe23040@katroo.Sendmail.COM> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> <200304291140.h3TBeCe23040@katroo.Sendmail.COM> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051634342.26178.240.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 29 Apr 2003 19:39:03 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-04-29 at 14:36, Philip Guenther wrote: > There are three 'issues' that the VHOST capability claims to address: > 1) the ad-hoc interpretation of authentication IDs as specifying user > and domain > 2) the ability to have domain-specific capability lists > 3) the choice of STARTTLS certificate by the server Related to 2, I've thought about giving different capability lists per user. Couldn't both of these be solved by letting server reply with untagged CAPABILITY reply (or resp-text-code) after login? All clients might not update their lists, but that's better than having extra/missing capabilities listed. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBwFi2084908 for ; Tue, 29 Apr 2003 04:58:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TBwFbD084907 for ietf-imapext-bks; Tue, 29 Apr 2003 04:58:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBwEi2084900 for ; Tue, 29 Apr 2003 04:58:14 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:53665 "ehlo melkebalanse.gulbrandsen.priv.no" ident: "NO-IDENT-SERVICE[2]") by bra.gulbrandsen.priv.no with ESMTP id ; Tue, 29 Apr 2003 13:58:02 +0200 Message-Id: From: Arnt Gulbrandsen To: Philip Guenther Subject: Re: IMAP Capability and Virtual Domains Cc: Harrie Hazewinkel , IMAP Extensions WG References: <7FE40FBE-7A27-11D7-998F-0003934A5A7E@inet.it> <200304291144.h3TBiCe23346@katroo.Sendmail.COM> In-Reply-To: <200304291144.h3TBiCe23346@katroo.Sendmail.COM> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 29 Apr 2003 13:58:50 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther writes: > Arnt Gulbrandsen writes: >> As long as VHOST does not block, it can be added almost anywere. I'd >> add it in step E: "send VHOST and STARTTLS". > > Imap servers are allowed to reorder pipelined commands, so that won't work. I'd quibble... but you're effectively right. Pity. > (The tagged OK of the STARTTLS command is sent _before_ TLS > negotiation and is therefore not protected.) (The server can send an unsolicited untagged OK afterwards. ISTR having seen one do. UW, I think... but it's at least a year ago.) OK. VHOST must add another round-trip. Then I dislike it even more. How about using something like 'STARTTLS VHOST=fqdn'? --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBgYi2083770 for ; Tue, 29 Apr 2003 04:42:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TBgYFr083769 for ietf-imapext-bks; Tue, 29 Apr 2003 04:42:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBgXi2083764 for ; Tue, 29 Apr 2003 04:42:33 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3TBgUFd020554; Tue, 29 Apr 2003 04:42:30 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7/8.11.6) with ESMTP id h3TBiCe23346; Tue, 29 Apr 2003 04:44:12 -0700 (PDT) Message-Id: <200304291144.h3TBiCe23346@katroo.Sendmail.COM> To: Arnt Gulbrandsen Cc: Harrie Hazewinkel , IMAP Extensions WG From: Philip Guenther Subject: Re: IMAP Capability and Virtual Domains In-reply-to: References: <7FE40FBE-7A27-11D7-998F-0003934A5A7E@inet.it> Date: Tue, 29 Apr 2003 04:40:49 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen writes: > >Harrie Hazewinkel writes: >> In such a case I believe we could 'convert' CAPABILITY by ading >> 'VHOST' semantics when the server is before the STARTTLS and/or >> AUTH/LOGIN. > >As long as VHOST does not block, it can be added almost anywere. I'd add >it in step E: "send VHOST and STARTTLS". Imap servers are allowed to reorder pipelined commands, so that won't work. >> What I neither understand why was the response of a CAPABILITY not >> added to the response of STARTTLS for example. Allowing that would >> have reduced the extra CAPABILITY commands and the associated >> waiting. > >It is. RFC 3501 resp-code-text includes capability-data, and section >7.2.1 describes how to do it. Recent versions of UW imapd use that. rfc3501, section 6.2.1: Once [TLS] has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in- the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS. (The tagged OK of the STARTTLS command is sent _before_ TLS negotiation and is therefore not protected.) Philip Guenther guenther@sendmail.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBcci2083137 for ; Tue, 29 Apr 2003 04:38:38 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TBccct083136 for ietf-imapext-bks; Tue, 29 Apr 2003 04:38:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TBcXi2083090 for ; Tue, 29 Apr 2003 04:38:37 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3TBcUFd020175; Tue, 29 Apr 2003 04:38:31 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7/8.11.6) with ESMTP id h3TBeCe23040; Tue, 29 Apr 2003 04:40:12 -0700 (PDT) Message-Id: <200304291140.h3TBeCe23040@katroo.Sendmail.COM> To: "Michael Fair" Cc: ietf-imapext@imc.org, "Harrie Hazewinkel" Subject: Re: IMAP Capability and Virtual Domains In-reply-to: <00fa01c30e21$430c6020$d1d07b43@cocacola> References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> Date: Tue, 29 Apr 2003 04:36:50 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Michael Fair" writes: ... >Current single IP implementations pack the domain info in >the usernames and then do some magic after authentication to >create the domain specific view. How they pack the domain >info varies from site to site, but the username is the >only client submitted information that can reliably be >used to identify the targetted domain. > >The problem with this solution is that there are several >things that happen before LOGIN or AUTH where knowing the >domain would be useful. Namely STARTTLS and CAPABILITY. There are three 'issues' that the VHOST capability claims to address: 1) the ad-hoc interpretation of authentication IDs as specifying user and domain 2) the ability to have domain-specific capability lists 3) the choice of STARTTLS certificate by the server In my opinion, the first of these is a non-issue in practice. Indeed, the VHOST extension leaves the client author in a sticky situation: if it accepts the authentication ID as a single value ready for presenting to LOGIN (or AUTHENTICATE PLAIN/CRAM-MD5/etc), then it must decide and document how it splits that into a domain for VHOST and a username for LOGIN. If it accepts the authentication ID as separate domain and user values, then it must guess how to join them for non-VHOST-enabled servers, or have another configuration parameter for _that_. The VHOST extension would also need to specify how it affects and/or operates with SASL mechanisms that convey the user's domain separate from their username. The second issue appears minor to me. Is it more than a matter of differing domains being allowed different SASL mechanisms? Is that a practical problem? I agree that the third issue is a real problem. IMHO, STARTTLS would have been better defined to take an "fqdn" argument that the server could use to decide which certificate to use. An extension that did only that---add an optional domain argument to STARTTLS---would appear to provide most of the benefits of VHOST. >The current IMAP extension draft adds a "VHOST" command >to specify which virtual host the client was trying to reach. >Overall I think it's a good proposal, but I believe the >same result can be accomplished without the need for adding >a new command. > >I had an offline discussion with Mark Crispin and proposed >adding the domain name as an optional parameter to CAPABILITY. It seems to me that the CAPABILITY command is ill-suited for such treatment. If the client already has the server's list of capabilities and therefore knows that the server supports the extension, then overloading the CAPABILITY command doesn't save you anything. If the client doesn't already have the server's list of capabilities, then the client will have to either try the extended version and fallback on BAD, or send an unextended request with a followup if the capability is advertised, either way requiring two roundtrips against some set of servers. Leaving the VHOST command separate from CAPABILITY while strengthing the recommendation that the server include a CAPABILITY response code in the initial PREAUTH or OK response and that clients recognize such would appear to be a simpler and cleaner approach. ... >As an added bonus, this also lays the groundwork for >some future planning on replicating and scaling IMAP >mail stores to span multiple mail stores to provide >geograhic redundancy. Without this feature the "IP burn >rate" jumps to 1+N addresses per domain where N is the >number of geographically redundant mail stores. I don't understand how geographically redundant mail stores are helped out any more than any set of N mail stores that offer STARTTLS. If the problem is the requirement for separate IPs for STARTTLS, then giving STARTTLS an optional argument would "lower the burn rate" just as much as VHOST or "CAPABILITY domain", no? Philip Guenther guenther@sendmail.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TA1oi2076330 for ; Tue, 29 Apr 2003 03:01:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3TA1okQ076329 for ietf-imapext-bks; Tue, 29 Apr 2003 03:01:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3TA1ni2076323 for ; Tue, 29 Apr 2003 03:01:50 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:5281 "ehlo melkebalanse.gulbrandsen.priv.no" ident: "NO-IDENT-SERVICE[2]") by bra.gulbrandsen.priv.no with ESMTP id ; Tue, 29 Apr 2003 12:01:33 +0200 Message-Id: From: Arnt Gulbrandsen To: Harrie Hazewinkel Subject: Re: IMAP Capability and Virtual Domains Cc: IMAP Extensions WG References: <7FE40FBE-7A27-11D7-998F-0003934A5A7E@inet.it> In-Reply-To: <7FE40FBE-7A27-11D7-998F-0003934A5A7E@inet.it> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 29 Apr 2003 12:02:21 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Harrie Hazewinkel writes: > In such a case I believe we could 'convert' CAPABILITY by ading > 'VHOST' semantics when the server is before the STARTTLS and/or > AUTH/LOGIN. As long as VHOST does not block, it can be added almost anywere. I'd add it in step E: "send VHOST and STARTTLS". > What I neither understand why was the response of a CAPABILITY not > added to the response of STARTTLS for example. Allowing that would > have reduced the extra CAPABILITY commands and the associated > waiting. It is. RFC 3501 resp-code-text includes capability-data, and section 7.2.1 describes how to do it. Recent versions of UW imapd use that. > Adding a fifth wait is a trade-off compared to the extra functionality on > can get. Explain. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T9gxi2075536 for ; Tue, 29 Apr 2003 02:42:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3T9gxb2075534 for ietf-imapext-bks; Tue, 29 Apr 2003 02:42:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mid-1.inet.it (mid-1.inet.it [213.92.5.18]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T9gvi2075523 for ; Tue, 29 Apr 2003 02:42:58 -0700 (PDT) (envelope-from harrie@inet.it) Received: from [::ffff:213.92.1.193] by mid-1.inet.it via I-SMTP-4.4.2-442 id ::ffff:213.92.1.193+FrLnnBgUaM71; Tue, 29 Apr 2003 11:42:56 +0200 Date: Tue, 29 Apr 2003 11:46:49 +0200 Subject: Re: IMAP Capability and Virtual Domains Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Harrie Hazewinkel , IMAP Extensions WG To: Arnt Gulbrandsen From: Harrie Hazewinkel In-Reply-To: Message-Id: <7FE40FBE-7A27-11D7-998F-0003934A5A7E@inet.it> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tuesday, April 29, 2003, at 11:26 AM, Arnt Gulbrandsen wrote: > Harrie Hazewinkel writes: >> Correct me if I am wrong, but "do clients not have to wait for >> STARTTLS to finish also before a login procedure can be given??" > > A client must wait for STARTTLS, yes. Regrettable, but given the > nature of the command it's unavoidable. > > Today, with most servers, I have to > > a) connect > b) wait until I see the IMAP banner > c) send CAPABILITY > d) wait for the answer > e) send STARTTLS (or switch to port 993 and repeat from step a) > f) wait for the answer > g) do TLS negotiation > h) send CAPABILITY > i) wait for the answer > j) send AUTH or LOGIN > k) wait for the answer > > Steps d, f, i and k add up to more than enough waiting. Adding a fifth > wait is not a good idea. In such a case I believe we could 'convert' CAPABILITY by ading 'VHOST' semantics when the server is before the STARTTLS and/or AUTH/LOGIN. What I neither understand why was the response of a CAPABILITY not added to the response of STARTTLS for example. Allowing that would have reduced the extra CAPABILITY commands and the associated waiting. Adding a fifth wait is a trade-off compared to the extra functionality on can get. In this case it is easier server administration that does not directly benefit a user. :-(( Harrie Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T9Pni2075134 for ; Tue, 29 Apr 2003 02:25:49 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3T9PnbD075133 for ietf-imapext-bks; Tue, 29 Apr 2003 02:25:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T9Pmi2075128 for ; Tue, 29 Apr 2003 02:25:49 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:5025 "ehlo melkebalanse.gulbrandsen.priv.no" ident: "NO-IDENT-SERVICE[2]") by bra.gulbrandsen.priv.no with ESMTP id ; Tue, 29 Apr 2003 11:25:35 +0200 Message-Id: From: Arnt Gulbrandsen To: Harrie Hazewinkel Subject: Re: IMAP Capability and Virtual Domains Cc: IMAP Extensions WG References: <60C91510-7A22-11D7-998F-0003934A5A7E@inet.it> In-Reply-To: <60C91510-7A22-11D7-998F-0003934A5A7E@inet.it> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 29 Apr 2003 11:26:24 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Harrie Hazewinkel writes: > Correct me if I am wrong, but "do clients not have to wait for > STARTTLS to finish also before a login procedure can be given??" A client must wait for STARTTLS, yes. Regrettable, but given the nature of the command it's unavoidable. Today, with most servers, I have to a) connect b) wait until I see the IMAP banner c) send CAPABILITY d) wait for the answer e) send STARTTLS (or switch to port 993 and repeat from step a) f) wait for the answer g) do TLS negotiation h) send CAPABILITY i) wait for the answer j) send AUTH or LOGIN k) wait for the answer Steps d, f, i and k add up to more than enough waiting. Adding a fifth wait is not a good idea. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T96Ri2074277 for ; Tue, 29 Apr 2003 02:06:27 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3T96R24074276 for ietf-imapext-bks; Tue, 29 Apr 2003 02:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from hal-5.inet.it (hal-5.inet.it [213.92.5.24]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T96Pi2074268 for ; Tue, 29 Apr 2003 02:06:26 -0700 (PDT) (envelope-from harrie@inet.it) Received: from [::ffff:213.92.1.193] by hal-5.inet.it via I-SMTP-4.4.2-442 id ::ffff:213.92.1.193+K38meodH7kk0; Tue, 29 Apr 2003 11:06:17 +0200 Date: Tue, 29 Apr 2003 11:10:10 +0200 Subject: Re: IMAP Capability and Virtual Domains Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Harrie Hazewinkel , IMAP Extensions WG To: Arnt Gulbrandsen From: Harrie Hazewinkel In-Reply-To: Message-Id: <60C91510-7A22-11D7-998F-0003934A5A7E@inet.it> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tuesday, April 29, 2003, at 10:51 AM, Arnt Gulbrandsen wrote: > I don't much like VHOST. Its benefit over the current user@host hacks > seems limited to providing the right TLS certificate. But I could live > with it, provided it were simpler. > > a) Clients using VHOST should always send the IMAP server's FQDN as > argument. Nothing else. > > b) BAD should be sent only for syntax errors or command unknown. > > c) Clients should explicitly not have to wait for the answer before > proceeding with the login procedure. Correct me if I am wrong, but "do clients not have to wait for STARTTLS to finish also before a login procedure can be given??" Harrie Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T8oZi2073895 for ; Tue, 29 Apr 2003 01:50:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3T8oZid073894 for ietf-imapext-bks; Tue, 29 Apr 2003 01:50:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T8oYi2073889 for ; Tue, 29 Apr 2003 01:50:34 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:1697 "ehlo melkebalanse.gulbrandsen.priv.no" ident: "NO-IDENT-SERVICE[2]") by bra.gulbrandsen.priv.no with ESMTP id ; Tue, 29 Apr 2003 10:50:21 +0200 Message-Id: From: Arnt Gulbrandsen To: Harrie Hazewinkel , IMAP Extensions WG Subject: Re: IMAP Capability and Virtual Domains References: <019701c30dd9$d6019c80$d1d07b43@cocacola> <00fa01c30e21$430c6020$d1d07b43@cocacola> In-Reply-To: <00fa01c30e21$430c6020$d1d07b43@cocacola> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 29 Apr 2003 10:51:09 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I don't much like VHOST. Its benefit over the current user@host hacks seems limited to providing the right TLS certificate. But I could live with it, provided it were simpler. a) Clients using VHOST should always send the IMAP server's FQDN as argument. Nothing else. b) BAD should be sent only for syntax errors or command unknown. c) Clients should explicitly not have to wait for the answer before proceeding with the login procedure. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T7Uri2058555 for ; Tue, 29 Apr 2003 00:30:53 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3T7UrvG058554 for ietf-imapext-bks; Tue, 29 Apr 2003 00:30:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3T7Uni2058533 for ; Tue, 29 Apr 2003 00:30:49 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 2349F883DD6; Tue, 29 Apr 2003 00:30:49 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 9EF1D883D93; Tue, 29 Apr 2003 00:30:46 -0700 (PDT) Message-ID: <00fa01c30e21$430c6020$d1d07b43@cocacola> From: "Michael Fair" To: Cc: "Harrie Hazewinkel" References: <019701c30dd9$d6019c80$d1d07b43@cocacola> Subject: IMAP Capability and Virtual Domains Date: Tue, 29 Apr 2003 00:30:46 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-6.6 required=5.0 tests=REFERENCES version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, I understand that in general this list is not very actively interested in scaling the IMAP protocol to support lots of domains on a single IP address. Myself and I know a number of others (mainly hosting companies) are interested in this feature. Currently only HTTP 1.1 has any kind of support for this kind of scaling. I'll be brief, a quick education on the issues for those that don't understand the problem or haven't read the VHOST extension draft and then a suggestion that I believe would quite neatly solve all the issues plus a couple that none of the existing solutions offer while still maintaing compatibility with existing clients/servers and allow for a mostly gradual transition between non-virtualized and virtualized deployment. The issues: At the core of it, in most hosting for hire environments you typically get a lot of domains that only have a few users (less than 30). In a modest ISP, having to support 1,000 domains is very reasonable. The vast majority of those domains typically have less than 5 accounts, and the number with more than 30 accounts is usually countable on one or two hands. This creates a situation where you have about 10,000-20,000 accounts spread over 1,000 domains. This is easily hosted on any decent sized server and hosting this on a single machine is a very reasonable thing to do. The problem is that this ISP typically has a /21 giving it a total of 1,275 IP addresses. If this ISP was to try and give the highest quality of service at 1 IP address per domain, which the existing protocol calls for, this ISP would have 1,000 IP addresses all pointed at the same server and have 273 left over for other uses. In the case of the medium size ISP it is actually impossible to even consider offering such a service. This is especially compounded if you start to include other services like FTP. As another consideration this doesn't even touch trying to provide geographically redundant services where the data is accessible from at least two (preferably three) redundant sites that are located on completely separate IP networks. (This means at least two preferably three IPs per domain) So the short of it is that for certain very common environments there is a clear and definite need for being able to multiplex multiple domains onto a single IP address. A brief overview on the current state of trying to accomplish this: When a client shows up at the server's door all it knows is the IP address the client was trying to reach. This is completely insufficient to determine the targetted domain unless you have 1 IP per domain. In short, the server must be told directly what domain the client was trying to reach before it can access any domain specific parameters (these include shared folders, security certificates and any other parameters a server might want to modify on a per domain basis (like AUTH services)). The other need for per domain identification is to allow for bob@domain1.dom to be differentiated from bob@domain2.dom when the client only presents the username "bob". Current single IP implementations pack the domain info in the usernames and then do some magic after authentication to create the domain specific view. How they pack the domain info varies from site to site, but the username is the only client submitted information that can reliably be used to identify the targetted domain. The problem with this solution is that there are several things that happen before LOGIN or AUTH where knowing the domain would be useful. Namely STARTTLS and CAPABILITY. The current IMAP extension draft adds a "VHOST" command to specify which virtual host the client was trying to reach. Overall I think it's a good proposal, but I believe the same result can be accomplished without the need for adding a new command. I had an offline discussion with Mark Crispin and proposed adding the domain name as an optional parameter to CAPABILITY. My assumption was that the very first thing an IMAP client is going to do (even before STARTTLS) is CAPABILITY to find out if the server can even do STARTTLS and to figure out what methods of authentication the server makes available. By identifying the domain prior to any other commands, the server has the opportunity to get into a domain specific mode very early. For instance, STARTTLS could now provide a per domain certificate instead of being forced to provide a single (usually ISP specific) cert, or even worse, not offering IMAPS at all. If that assumption is wrong, then I hope that someone would correct me as it makes this suggestion rather worthless and makes the VHOST addition a more viable solution. Once a client had issued a CAPABILITY with a domain parameter, the server would go into a domain specific mode where all responses would be local to that domain's config. The main restrictions for a client would be that during a TLS session and/or while in the AUTHENTICATED state the client MUST NOT issue a CAPABILITY where that domain parameter is different. If a client were allowed to jump domains in the middle of those contexts it would be ambiguous at best, and create security holes at worst. The server is of course encouraged to take whatever steps are appropriate to ensure that the client doesn't try and jump domains in these contexts. Currently CAPABILITY accepts no parameters and it's an error to present one. Clients could try first with the domain, and then upon receiving BAD try without the domain. If a server supported the parameter, but not the requested domain, the server could either respond with NO saying that the domain isn't supported, or it could respond with YES if the server just swallows the parameter and gives the same behavior regardless of the domain. This makes the existing servers behavior remain correct, allows for servers to be compatible by simply swallowing the parameter and not doing anything with it, and future servers can implement a true virtualized hosted environment. If a client tries to jump domain contexts, the server should answer "NO" if it would have answered "NO" to an unavailable or not supported domain, or it should simply swallow the parameter or respond with "BAD" if it would have swallowed the parameter or reposnded with "BAD" before. Clients that support this need only be prepared to receive a BAD or NO when issuing a CAPABILITY and conform to not trying to jump domains when in a TLS session or AUTHENTICATED state. As an added bonus, this also lays the groundwork for some future planning on replicating and scaling IMAP mail stores to span multiple mail stores to provide geograhic redundancy. Without this feature the "IP burn rate" jumps to 1+N addresses per domain where N is the number of geographically redundant mail stores. It's true that this might solveable with a distributed file system instead of an IMAP extension protocol, but I believe it would be harmful to ignore the idea that there are those in the world who care enough about reliability to use three or four distributed machines to maintain replicas of the mail store for performance and redundancy. Thank you very much for reading and I look forward to comments and feedback. Again, I do understand that this is not a need that most people on this list consider very important so taking the time out to lend some grey matter to it is greatly appreciated. -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NC97t2014122 for ; Wed, 23 Apr 2003 05:09:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NC97nS014121 for ietf-imapext-bks; Wed, 23 Apr 2003 05:09:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NC95t2014116 for ; Wed, 23 Apr 2003 05:09:05 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 500045E017F5; Wed, 23 Apr 2003 15:09:05 +0300 (EEST) Subject: Re: Full text search and SEARCHM IMAP extention From: Timo Sirainen To: Takeshi Morishima Cc: ietf-imapext@imc.org In-Reply-To: <1955-Tue22Apr2003222857-0500-tm@onepost.net> References: <1955-Tue22Apr2003071742-0500-tm@onepost.net> <1051017925.32160.92.camel@hurina> <1955-Tue22Apr2003222857-0500-tm@onepost.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051099745.32157.157.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 23 Apr 2003 15:09:05 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2003-04-23 at 06:28, Takeshi Morishima wrote: > Will try to update the proposal modification based on the comments. I > need study LISTEXT more - don't fully understand how it's related or > can be merged. Actually, forget it. I was just thinking that since they added STATUS support there, it could be used as some generic "for each listed mailbox, do ". But it'd require replying with LIST replies, which is probably not so useful with SEARCHM. And if result has to be sorted, it's not so simple. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N3TSt2063943 for ; Tue, 22 Apr 2003 20:29:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3N3TRXr063942 for ietf-imapext-bks; Tue, 22 Apr 2003 20:29:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3N3TQt2063935 for ; Tue, 22 Apr 2003 20:29:26 -0700 (PDT) (envelope-from tm@onepost.net) Received: from sage.ml-search.com (12-207-101-182.client.attbi.com[12.207.101.182]) by rwcrmhc52.attbi.com (rwcrmhc52) with ESMTP id <2003042303291905200ntvlee>; Wed, 23 Apr 2003 03:29:21 +0000 Date: Tue, 22 Apr 2003 22:28:57 -0500 Message-Id: <1955-Tue22Apr2003222857-0500-tm@onepost.net> X-Mailer: cmail 2.62 on GNU Emacs 20.7.1 / Mule 4.1 (AOI) (via feedmail 8 I) References: <1955-Tue22Apr2003071742-0500-tm@onepost.net> <1051017925.32160.92.camel@hurina> From: tm@onepost.net (Takeshi Morishima) To: tss@iki.fi CC: ietf-imapext@imc.org In-reply-to: Timo Sirainen's message of "22 Apr 2003 16:25:25 +0300" <1051017925.32160.92.camel@hurina> Subject: Re: Full text search and SEARCHM IMAP extention 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: In message "Re: Full text search and SEARCHM IMAP extention" on 2003/04/22, Timo Sirainen writes: > One thing that I've thought that could be useful is to return the text > that matched so client could display google-like search results directly > without fetching all the messages. I'd agree that this may be useful. This would be new data type though, with mime content headers re-constructed for summary text. > I'm not sure if msgmax / msgstart is such a good idea. You > probably want it for prev/next page-like feature, but if new > matches appear between searches, you might miss some messages. My initial motivation of these options was to allow client to specify max number of messages to be returned. Client could prepare only resource that would be needed that way, thus more effcient use of resources. It also saves a bit of bandwidth of returning only 200 of top score out of total 1000 hits. Then suddenly I thought that if we limit the amount of search result by msgmax, I would need msgstart in case user is not satisfactory in the search result and want to get next block of result, since otherwise the client may end up receiving the same block of data repeatedly as it increases msgmax, which did not sound very efficient. For the issue of result changes between searches, I also thought about it, and had one idea of using the search name to identify previous search context so that the server can remember it and provide consistent output. This would require the client to use differnt search name everytime new search is performed, the server side to provide more resource, and will complicate things, which did not sound like a good idea. Since this modified searchm is intended for best effort search, I thought that dup or missing messages may not be an issue for typical case, resulted in this form. (Probably no need of msgend, just use msgstart+msgmax.) Will try to update the proposal modification based on the comments. I need study LISTEXT more - don't fully understand how it's related or can be merged. Regards, Takeshi Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MLTBt2046673 for ; Tue, 22 Apr 2003 14:29:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MLTBMh046672 for ietf-imapext-bks; Tue, 22 Apr 2003 14:29:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MLT9t2046666 for ; Tue, 22 Apr 2003 14:29:10 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:10983 "ehlo melkebalanse.gulbrandsen.priv.no") by gulbrandsen.priv.no with ESMTP id convert rfc822-to-8bit; Tue, 22 Apr 2003 23:28:50 +0200 Message-Id: <2EHMpNqCojy8RKJEFJiRCw.md5@melkebalanse.gulbrandsen.priv.no> From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: WATCH extension for IMAP Cc: IMAP Extensions WG References: In-Reply-To: Content-Transfer-Encoding: 8BIT Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 22 Apr 2003 23:28:29 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > This is in effect an IMAP interface to an ultra-lightweight > notification protocol and facility that I am working on. The IMAP > server won't do any actual "watching"; instead, it will just be a > client to the notification facility. Isn't that a natural implementation choice? > I am interested in feedback as to whether this proposed extension is > interesting or not. Yes. But as internet-draft, please. > Also, would it be better to build an extension which has extensibility > but with restraints ("ultra-lightweight") on how it can be extended, > or if it should be strictly a new mail watching facility ... If the latter, perhaps it can avoid the fate of so many similar proposals? --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MIpXt2038958 for ; Tue, 22 Apr 2003 11:51:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MIpXuh038957 for ietf-imapext-bks; Tue, 22 Apr 2003 11:51:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MIpUt2038949 for ; Tue, 22 Apr 2003 11:51:31 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:15589 "ehlo melkebalanse.gulbrandsen.priv.no") by gulbrandsen.priv.no with ESMTP id ; Tue, 22 Apr 2003 20:51:17 +0200 Message-Id: From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: WATCH extension for IMAP Cc: Cyrus Daboo , Lawrence Greenfield , IMAP Extensions WG References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 22 Apr 2003 20:50:56 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Tue, 22 Apr 2003, Arnt Gulbrandsen wrote: >> > LIST can never be more expensive than STATUS. >> I can disprove that by counterexample. >> C: b list "" * > > You are comparing apples and oranges. There is no such thing as a > wildcard STATUS. Perhaps I misunderstood. I was comparing LIST to a for loop sending STATUS for e.g. 1800 mailboxes. Seemed a fair enough comparison. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MHbSt2035634 for ; Tue, 22 Apr 2003 10:37:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MHbSNs035633 for ietf-imapext-bks; Tue, 22 Apr 2003 10:37:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MHbQt2035624 for ; Tue, 22 Apr 2003 10:37:27 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3MHbFSL029531; Tue, 22 Apr 2003 10:37:20 -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+UW03.04/8.12.1+UW02.12) with ESMTP id h3MHbF4t000995 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Apr 2003 10:37:15 -0700 Date: Tue, 22 Apr 2003 10:37:15 -0700 (Pacific Daylight Time) From: Mark Crispin To: Arnt Gulbrandsen cc: Cyrus Daboo , Lawrence Greenfield , IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: Message-ID: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> 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, 22 Apr 2003, Arnt Gulbrandsen wrote: > > LIST can never be more expensive than STATUS. > I can disprove that by counterexample. > C: b list "" * You are comparing apples and oranges. There is no such thing as a wildcard STATUS. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MGJvt2031834 for ; Tue, 22 Apr 2003 09:19:57 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MGJvjg031833 for ietf-imapext-bks; Tue, 22 Apr 2003 09:19:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MGJtt2031828 for ; Tue, 22 Apr 2003 09:19:55 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id ED57D5E017F5; Tue, 22 Apr 2003 19:19:55 +0300 (EEST) Subject: Re: Pending changes to CONDSTORE From: Timo Sirainen To: Alexey Melnikov Cc: IMAP Extensions WG In-Reply-To: <3EA4CC56.C9FE5BFA@messagingdirect.com> References: <3EA4CC56.C9FE5BFA@messagingdirect.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051028395.32159.107.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 22 Apr 2003 19:19:55 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-04-22 at 08:00, Alexey Melnikov wrote: > I haven't resolved an open issue regarding atomicity of CONDSTORE for a > message set. I am still waiting for more feedback. Yes, it could be difficult with maildir at least since you can't prevent flag changes by other clients. Is there even a reason to want atomicity? Is there a reason to return MODSEQ separately for each message with SILENT STORE? And why not return the modseq and flags directly for modified messages, wouldn't client want to ask them anyway next? Something like: a STORE 100:150 (UNCHANGEDSINCE 1) +FLAGS.SILENT ($Processed) * 101 FETCH (MODSEQ (2) FLAGS ($Processed)) * 105 FETCH (MODSEQ (2) FLAGS ($Processed)) a OK [MODSEQ 3 MODIFIED 101,105] Some flags weren't changed b STORE 100 (UNCHANGEDSINCE 1) +FLAGS.SILENT ($Processed) * 100 FETCH (MODSEQ (3) FLAGS ($Processed)) b OK [MODIFIED 100] No flags were changed c STORE 100,151 (UNCHANGEDSINCE 1) +FLAGS ($Processed) * 100 FETCH (MODSEQ (3) FLAGS ($Processed)) * 151 FETCH (MODSEQ (4) FLAGS ($Processed)) c OK [MODSEQ 4 MODIFIED 100] Some flags weren't changed Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MFMlt2029713 for ; Tue, 22 Apr 2003 08:22:47 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MFMlOp029712 for ietf-imapext-bks; Tue, 22 Apr 2003 08:22:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MFMjt2029695 for ; Tue, 22 Apr 2003 08:22:46 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: from melkebalanse.gulbrandsen.priv.no ([217.19.171.131]:25060 "ehlo melkebalanse.gulbrandsen.priv.no") by gulbrandsen.priv.no with ESMTP id ; Tue, 22 Apr 2003 17:22:29 +0200 Message-Id: From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: WATCH extension for IMAP Cc: Cyrus Daboo , Lawrence Greenfield , IMAP Extensions WG References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 22 Apr 2003 17:22:08 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > LIST can never be more expensive than STATUS. I can disprove that by counterexample. I have a crappy IMAP client (came preinstalled on a machine I bought) whose login sequence is like this when it talks to wu-imapd: C: a login arnt tnra S: a ok C: b list "" * S: ... C: (run out of memory and crash) The server's resource use is limited only by bandwidth and the client's available RAM, which is potentially far more than it would spend processing STATUS. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MDPZt2021731 for ; Tue, 22 Apr 2003 06:25:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MDPZSL021730 for ietf-imapext-bks; Tue, 22 Apr 2003 06:25:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MDPXt2021723 for ; Tue, 22 Apr 2003 06:25:33 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 043865E017F5; Tue, 22 Apr 2003 16:25:25 +0300 (EEST) Subject: Re: Full text search and SEARCHM IMAP extention From: Timo Sirainen To: Takeshi Morishima Cc: ietf-imapext@imc.org In-Reply-To: <1955-Tue22Apr2003071742-0500-tm@onepost.net> References: <1955-Tue22Apr2003071742-0500-tm@onepost.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1051017925.32160.92.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 22 Apr 2003 16:25:25 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2003-04-22 at 15:17, Takeshi Morishima wrote: > My comments and proposed modification to the current SEARCHM draft are > described in the following file: > > http://www.ml-search.com/tmpdocs/draft-leiba-imap-search-multiple-01-comment.pdf > > It proposes to allow server to ignore unsupported criteria/mailbox, > provide sorted result fragmentation, more options to control search > result, and a new HITS response to return search statistics numbers. One thing that I've thought that could be useful is to return the text that matched so client could display google-like search results directly without fetching all the messages. This would be especially useful if server supported searching inside non-text file attachments like ms word docs, pdfs, postscripts, etc. > Also, because the search will be performed outside of selected state, > I thought that returning message sequence numbers may have a problem, > and for other reasons, I'm proposing to return UIDs and UIDVALIDITY > always in the SEARCHM response. Right. Maybe remove the whole "UID SEARCHM". Some other thoughts: Sorting conflicts a bit with SORT extension. At least change "sentdate" to "date" so they're compatible. I'm not sure if msgmax / msgstart is such a good idea. You probably want it for prev/next page-like feature, but if new matches appear between searches, you might miss some messages. I think "Mailbox URL" is wrong word to describe LIST-like mailbox wildcarded names. And should this maybe be merged with LISTEXT? Returning UIDVALIDITY before UIDs would be nicer. And it doesn't have to be in paranthesis. Anyway I'd like to have this kind of non-strict text searching. Current SEARCH can be useful for client internally, but for normal searching by user it's unnecessarily slow because it's strictness really limits the optimizations that server can do. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MCIDt2019865 for ; Tue, 22 Apr 2003 05:18:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MCIDaV019864 for ietf-imapext-bks; Tue, 22 Apr 2003 05:18:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MCICt2019859 for ; Tue, 22 Apr 2003 05:18:12 -0700 (PDT) (envelope-from tm@onepost.net) Received: from sage.ml-search.com (12-207-101-182.client.attbi.com[12.207.101.182]) by rwcrmhc52.attbi.com (rwcrmhc52) with ESMTP id <2003042212180605200h32m0e>; Tue, 22 Apr 2003 12:18:06 +0000 Date: Tue, 22 Apr 2003 07:17:42 -0500 Message-Id: <1955-Tue22Apr2003071742-0500-tm@onepost.net> X-Mailer: cmail 2.62 on GNU Emacs 20.7.1 / Mule 4.1 (AOI) (via feedmail 8 I) From: tm@onepost.net (Takeshi Morishima) To: ietf-imapext@imc.org Subject: Full text search and SEARCHM IMAP extention 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: Hello there, I've been looking into implementing a full text search on a client, to provide a multiple mailbox search with search performance similar to what we can find on many www based search engines. After implementing a repeat of select and search over multiple mailboxes, I found it slow and in most cases the search result does not appear very optimal. No framework to handle something like scoring based search result sorting, for example. Looking through existing RFCs and imap extention drafts, the closest to what I can use was the SEARCHM extention draft. The current SEARCHM draft, however, does not seem to be enough for the purpose of the above type of search. I would like this to be loosely coupled, best effort and best practice search capable, instead of requiring a strict listing for house keeping of client that SEARCHM is mainly intended to. A full text search would not need to deal with something like "unseen" type of search, and can omit messages that unlikely of user interest in a search result. My comments and proposed modification to the current SEARCHM draft are described in the following file: http://www.ml-search.com/tmpdocs/draft-leiba-imap-search-multiple-01-comment.pdf It proposes to allow server to ignore unsupported criteria/mailbox, provide sorted result fragmentation, more options to control search result, and a new HITS response to return search statistics numbers. Also, because the search will be performed outside of selected state, I thought that returning message sequence numbers may have a problem, and for other reasons, I'm proposing to return UIDs and UIDVALIDITY always in the SEARCHM response. Since the purposes of SEARCHM and the modified version above slightly differ, should it be different command? Or is this something that can be incorporated into the current searchm draft. If this is not worth discussing in this WG list nor standardization, please advice where I should take this to - any comments and suggestions would be appreciated. Regards, Takeshi Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MBgmt2015540 for ; Tue, 22 Apr 2003 04:42:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3MBgmdk015539 for ietf-imapext-bks; Tue, 22 Apr 2003 04:42:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3MBgkt2015531 for ; Tue, 22 Apr 2003 04:42:47 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03297; Tue, 22 Apr 2003 07:40:02 -0400 (EDT) Message-Id: <200304221140.HAA03297@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-condstore-01.txt Date: Tue, 22 Apr 2003 07:40:02 -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. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP Extension for Conditional STORE operation Author(s) : A. Melnikov, S. Hole Filename : draft-ietf-imapext-condstore-01.txt Pages : 16 Date : 2003-4-21 Often, multiple IMAP clients need to coordinate changes to a common IMAP mailbox. Examples include different clients for the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags or annotations) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-01.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-ietf-imapext-condstore-01.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-ietf-imapext-condstore-01.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: <2003-4-21143900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-condstore-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-condstore-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-21143900.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3M5R9t2073356 for ; Mon, 21 Apr 2003 22:27:09 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3M5R9Ev073355 for ietf-imapext-bks; Mon, 21 Apr 2003 22:27:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3M5R8t2073350 for ; Mon, 21 Apr 2003 22:27:08 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust66.tnt3.edmonton.ab.da.uu.net [64.10.184.66]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3M5UhV18436; Mon, 21 Apr 2003 23:30:43 -0600 Message-ID: <3EA4CC56.C9FE5BFA@messagingdirect.com> Date: Mon, 21 Apr 2003 23:00:06 -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: IMAP Extensions WG Subject: Pending changes to CONDSTORE 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: I haven't resolved an open issue regarding atomicity of CONDSTORE for a message set. I am still waiting for more feedback. Also, I would like to propose to add a new capability if MODSEQ sort criteria is implemented with SORT. Any objections to this? Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5pJt2032072 for ; Sat, 19 Apr 2003 22:51:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K5pJCR032071 for ietf-imapext-bks; Sat, 19 Apr 2003 22:51:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5pHt2032066 for ; Sat, 19 Apr 2003 22:51:17 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust193.tnt3.edmonton.ab.da.uu.net [64.10.184.193]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3K5rBV29565; Sat, 19 Apr 2003 23:53:12 -0600 Message-ID: <3EA234E7.6F36C341@messagingdirect.com> Date: Sat, 19 Apr 2003 23:49:27 -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: IMAP Extensions WG CC: IMAP Discusson List Subject: Updated draft-ietf-imapext-condstore document Content-Type: multipart/mixed; boundary="------------6D49FEEA8037F438115381F7" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6D49FEEA8037F438115381F7 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit I've updated the document as per comments from Mark and Cyrus. New version (draft-ietf-imapext-condstore-01) should appear shortly. In the meantime, I've attached the diff for the changes. Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html I speak for myself only, not for my employer. __________________________________________ --------------6D49FEEA8037F438115381F7 Content-Type: text/plain; charset=koi8-r; name="00-01.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="00-01.diff.txt" --- draft-ietf-imapext-condstore-00.txt Thu Mar 27 00:27:06 2003 +++ draft-ietf-imapext-condstore-01.txt Fri Apr 11 23:29:42 2003 @@ -1,7 +1,7 @@ Internet Draft: IMAP Extension for Conditional STORE A. Melnikov -Document: draft-ietf-imapext-condstore-00.txt S. Hole -Expires: September 2003 ACI WorldWide/MessagingDirect - March 2003 +Document: draft-ietf-imapext-condstore-01.txt S. Hole +Expires: October 2003 ACI WorldWide/MessagingDirect + April 2003 IMAP Extension for Conditional STORE operation @@ -43,6 +43,13 @@ 0.2. Change History + Changes from draft-ietf-imapext-condstore-00 + 1. Dropped "/message" prefix in entry names as per decision in San Francisco. + 2. Fixed ABNF for SEARCH and SORT untagged responses. + 3. Changed "private" to "priv" to be consistent with ANNOTATE. + 4. MODIFIED response code is now returned in OK response, not NO. + 5. Added NOMODSEQ response code. + Changes from draft-melnikov-imap-condstore-09: 1. Some text clarifications based on suggestions by Harrie Hazewinkel 2. Added paragraph about mailbox locking and DOS when conditional STORE @@ -139,6 +146,7 @@ 4 IMAP Protocol Changes ..................................... X 4.1 New OK untagged responses for SELECT and EXAMINE ......... X 4.1.1 HIGHESTMODSEQ response code ............................ X + 4.1.2 NOMODSEQ response code ................................. X 4.2 STORE and UID STORE Commands ............................. X 4.3 MODSEQ message data item in FETCH Command ................ X 4.4 MODSEQ search criterion in SEARCH ........................ X @@ -240,13 +248,18 @@ different metadata items. If the server does so, per message mod-sequence is the highest mod-sequence of all metadata items for the specified message. + The server that supports this extention is not required to be able to store + mod-sequences for every available mailbox. Section 4.1.2 describes how + the server may act if a particular mailbox doesn't support the persistent + storage of mod-sequences. + This extension makes the following changes to the IMAP4 protocol: a) extends the syntax of the STORE command to allow STORE modifiers b) adds the MODIFIED response code which should be used with - a NO response to the STORE command + an OK response to the STORE command c) adds a new MODSEQ message data item for use with the FETCH command @@ -269,13 +282,26 @@ 4.1. New OK untagged responses for SELECT and EXAMINE + This document adds two new response codes HIGHESTMODSEQ and NOMODSEQ. + One of those response codes MUST be returned in the OK untagged + response for a successful SELECT and EXAMINE commands. + + When opening a mailbox the server must check if the mailbox supports + the persistent storage of mod-sequences. If the mailbox supports + the persistent storage of mod-sequences and mailbox open operation succeeds, + the server MUST send the OK untagged response including HIGHESTMODSEQ + response code. If the persistent storage for the mailbox is not supported, + the server MUST send the OK untagged response including NOMODSEQ response + code instead. + + 4.1.1. HIGHESTMODSEQ response code This document adds a new response code that is returned in the OK untagged response for the SELECT and EXAMINE commands. A server - supporting the CONDSTORE extension MUST send the OK untagged - response including HIGHESTMODSEQ response code with every successful - SELECT or EXAMINE command: + supporting the persistent storage of mod-sequences for the mailbox MUST + send the OK untagged response including HIGHESTMODSEQ response code with + every successful SELECT or EXAMINE command: OK [HIGHESTMODSEQ ] @@ -307,6 +333,24 @@ S: A142 OK [READ-WRITE] SELECT completed +4.1.2 NOMODSEQ response code + + A server that doesn't support the persistent storage of mod-sequences for + the mailbox MUST send the OK untagged response including NOMODSEQ response + code with every successful SELECT or EXAMINE command. + + Example: C: A142 SELECT INBOX + S: * 172 EXISTS + S: * 1 RECENT + S: * OK [UNSEEN 12] Message 12 is first unseen + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: * OK [UIDNEXT 4392] Predicted next UID + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited + S: * OK [NOMODSEQ] Sorry, this mailbox format doesn't support modsequences + S: A142 OK [READ-WRITE] SELECT completed + + 4.2. STORE and UID STORE Commands Arguments: message set @@ -328,8 +372,9 @@ UNCHANGEDSINCE If the mod-sequence of any metadata item specified in the STORE operation for any message in the message set is greater than the - specified unchangedsince value, then the command fails. - On failure, a MODIFIED response code is returned which includes + specified unchangedsince value, then the command MUST NOT change + any flags. Instead, the server replies with the OK tagged response that + includes a MODIFIED response code. The MODIFIED response code includes the message set (for STORE) or set of UIDs (for UID STORE) of all messages that failed the UNCHANGESINCE test. @@ -337,7 +382,7 @@ C: a101 STORE 7,5,9 (UNCHANGEDSINCE 20000320162338) +FLAGS.SILENT (\Deleted) - S: a101 NO [MODIFIED 7,9] Conditional STORE failed + S: a101 OK [MODIFIED 7,9] Conditional STORE failed In spite of the failure of the conditional STORE operation for message 7, the server continues to process the conditional @@ -351,7 +396,7 @@ C: a102 STORE 12 (UNCHANGEDSINCE 0) +FLAGS.SILENT ($MDNSent) - S: a102 NO [MODIFIED 12] Conditional STORE failed + S: a102 OK [MODIFIED 12] Conditional STORE failed Note: A client trying to atomically change the state of a particular flag (or a set of flags) should be prepared to deal with the case @@ -370,7 +415,7 @@ Example: C: a106 STORE 100:150 (UNCHANGEDSINCE 200212030000000) +FLAGS.SILENT ($Processed) - S: a106 NO [MODIFIED 101] Conditional STORE failed + S: a106 OK [MODIFIED 101] Conditional STORE failed the flag $Processed was set on the message 101 ... C: a107 NOOP @@ -560,15 +605,15 @@ cache. The client may also specify (name of metadata item) and (type of metadata item) before . can be one of "shared", - "private" or "all". The latter means that the server should use - the biggest value among "private" and "shared" modseqs for the + "priv" (private) or "all". The latter means that the server should use + the biggest value among "priv" and "shared" mod-sequences for the metadata item. If the server doesn't store internally separate mod-sequences for different flags and annotations, it MUST ignore and . Otherwise the server should use them to narrow down the search. For a flag the corresponding has a form - "/message/flags/" as defined in [ANNOTATE]. Note, that + "/flags/" as defined in [ANNOTATE]. Note, that the leading "\" character that denotes a system flag has to be escaped as per Section 4.3 of [IMAP4], as the uses syntax for quoted strings. @@ -580,14 +625,14 @@ See also section 4.6. Example: - C: a SEARCH MODSEQ "/message/flags/draft" all 20010320162338 - ANNOTATION "/message/comment" "value" "IMAP4" + C: a SEARCH MODSEQ "/flags/draft" all 20010320162338 + ANNOTATION "/comment" "value" "IMAP4" S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 20010917162500) S: a OK Search complete In the above example, the message numbers of any messages containing the string "IMAP4" in the "value" attribute of the - "/message/comment" entry and having a mod-sequence equal to or + "/comment" entry and having a mod-sequence equal to or greater than 20010320162338 for the "\Draft" flag are returned in the search results. @@ -684,9 +729,6 @@ status-att-req = status-att / "HIGHESTMODSEQ" - mailbox-data =/ "STATUS" SP mailbox SP "(" - [status-rsp-info *(SP status-rsp-info)] ")" - status-rsp-info = status-att SP number / "HIGHESTMODSEQ" SP mod-sequence-value @@ -713,21 +755,22 @@ search-modseq-ext = SP entry-name SP entry-type-req resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value / + "NOMODSEQ" / "MODIFIED" SP set - entry-name = '"' "/message/flags/" attr-flag '"' + entry-name = '"' "/flags/" attr-flag '"' ;; each system or user defined flag - ;; is mapped to "/message/flags/". + ;; is mapped to "/flags/". ;; ;; follows the escape rules used ;; by "quoted" string as described in Section ;; 4.3 of [IMAP4], e.g. for the flag \Seen ;; the corresponding is - ;; "/message/flags/\\seen", and for the flag + ;; "/flags/\\seen", and for the flag ;; $MDNSent, the corresponding - ;; is "/message/flags/$mdnsent". + ;; is "/flags/$mdnsent". - entry-type-resp = "private" | "shared" + entry-type-resp = "priv" | "shared" ;; metadata item type entry-type-req = entry-type-resp | "all" @@ -749,8 +792,10 @@ ;;Borrowed from IMAP4rev1 and modified accordingly: - mailbox-data =/ "SEARCH" [SP nz-number *(SP nz-number) search_sort_mod_seq] / - "SORT" [SP nz-number *(SP nz-number) search_sort_mod_seq] + mailbox-data =/ "STATUS" SP mailbox SP "(" + [status-rsp-info *(SP status-rsp-info)] ")" / + "SEARCH" [1*(SP nz-number) SP search_sort_mod_seq] / + "SORT" [1*(SP nz-number) SP search_sort_mod_seq] attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" / "\\Seen" / "\\Draft" / attr-flag-keyword / @@ -828,8 +873,8 @@ interact with ANNOTATE extension and for thorough review of the document. Authors also acknowledge the feedback provided by Cyrus Daboo, Larry - Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen and Timo - Sirainen. + Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen Timo + Sirainen and Mark Crispin. 9. Author's Addresses --------------6D49FEEA8037F438115381F7-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5cxt2031869 for ; Sat, 19 Apr 2003 22:38:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K5cxTn031868 for ietf-imapext-bks; Sat, 19 Apr 2003 22:38:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5cwt2031861 for ; Sat, 19 Apr 2003 22:38:58 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust193.tnt3.edmonton.ab.da.uu.net [64.10.184.193]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3K5gRV29510; Sat, 19 Apr 2003 23:42:28 -0600 Message-ID: <3EA22FD4.57358871@messagingdirect.com> Date: Sat, 19 Apr 2003 23:27:48 -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: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <2147483647.1050082841@[10.0.1.6]> <3EA22E31.DA45B5C@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Cyrus Daboo wrote: > > > The formal syntax for 'entry-name' should be simply defined as: > > > > entry-name = string > > > > to fall in line with ANNOTATE. > > BTW, there is no ABNF element for entry-name in ANNOTATE, there are "entry" and > "entry-match". Also, ANNOTATE SEARCH criteria uses entry-match, which allows for wildcards. CONDSTORE doesn't use wildcards. Any opinions whether the document should/should not allow for wildcards? Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5cnt2031859 for ; Sat, 19 Apr 2003 22:38:49 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K5cng9031858 for ietf-imapext-bks; Sat, 19 Apr 2003 22:38:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5clt2031853 for ; Sat, 19 Apr 2003 22:38:48 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust193.tnt3.edmonton.ab.da.uu.net [64.10.184.193]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3K5gFV29502; Sat, 19 Apr 2003 23:42:20 -0600 Message-ID: <3EA22E31.DA45B5C@messagingdirect.com> Date: Sat, 19 Apr 2003 23:20:49 -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: Cyrus Daboo CC: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <2147483647.1050082841@[10.0.1.6]> 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: Cyrus Daboo wrote: > The formal syntax for 'entry-name' should be simply defined as: > > entry-name = string > > to fall in line with ANNOTATE. BTW, there is no ABNF element for entry-name in ANNOTATE, there are "entry" and "entry-match". > There should be a comment/reference to the > annotate spec at that point. Sure. > That will also allow you to remove the comment > about escape rules at that point. There is nothing wrong with repeating obvious ;-). > Also, could be use "priv" instead of "private" for entry-type-resp just to > fall in line with the suffixes that ANNOTATE uses? So you want to use "priv" and "shared"? I've just updated the document. Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5cht2031851 for ; Sat, 19 Apr 2003 22:38:43 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3K5chbb031850 for ietf-imapext-bks; Sat, 19 Apr 2003 22:38:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3K5cft2031845 for ; Sat, 19 Apr 2003 22:38:41 -0700 (PDT) (envelope-from mel@messagingdirect.com) Received: from messagingdirect.com (1Cust193.tnt3.edmonton.ab.da.uu.net [64.10.184.193]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3K5g8V29498; Sat, 19 Apr 2003 23:42:08 -0600 Message-ID: <3EA226A8.C4AC1C0A@messagingdirect.com> Date: Sat, 19 Apr 2003 22:48:40 -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: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <2147483647.1050084387@[10.0.1.6]> <3E9793F0.A48EF7E2@messagingdirect.com> <2147483647.1050147388@[10.0.1.3]> 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: > On Sat, 12 Apr 2003, Cyrus Daboo wrote: > > | Why would one want to use MODSEQ with THREAD? > > For the same reason one would use it in the search criteria on sort: to > > have the command return results only for those messages that changed since > > the MODSEQ. I doubt this is really a useful behaviour but it has to be > > present for consistency if you are adding MODSEQ to search unless its > > explicitly stated MODSEQ can't be used in sort/thread search criteria. > > I'm hard-pressed to think of a use for MODSEQ with THREAD; and while SORT > presents some possible use I doubt that there would be much of that in > real life. I agree with Mark here. I can see a utility in MODSEQ criterion in SEARCH and MODSEQ sort order in SORT. I prefer to live it unspecified how MODSEQ search criteria can be used in THREAD. Any objections? > If you declare that MODSEQ is an additional argument to SEARCH (much as > CHARSET is) instead of a SEARCH criterion, then you avoid the issue. But > that's no good if you decide to have MODSEQ in SORT. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J0C5t2041997 for ; Fri, 18 Apr 2003 17:12:05 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3J0C5V6041996 for ietf-imapext-bks; Fri, 18 Apr 2003 17:12:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3J0C4t2041991 for ; Fri, 18 Apr 2003 17:12:04 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.4] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id UAA16017; Fri, 18 Apr 2003 20:08:37 -0400 (EDT) Date: Fri, 18 Apr 2003 20:12:06 -0400 From: Cyrus Daboo To: Ken Murchison cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP Message-ID: <2147483647.1050696726@[10.0.1.4]> In-Reply-To: <3EA04FD7.B5D87545@oceana.com> References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> <200304180824.h3I8ODe28297@katroo.Sendmail.COM> <2147483647.1050673752@[63.163.82.24]> <3EA04FD7.B5D87545@oceana.com> X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Ken, --On Friday, April 18, 2003 3:19 PM -0400 Ken Murchison wrote: |> This shows up the problem that the client still has to poll via NOOP to |> get results. Obviously, if a mailbox was selected, the client could use |> IDLE and WATCH would come back during IDLE without the need to poll. But |> how would we deal with a connection that does not have a selected |> mailbox? The client could select a 'dummy' mailbox and then use idle, |> but wouldn't it be better to allow IDLE outside of selected state if |> WATCH is present? | | IIRC, IDLE is already allowed in both the authenticated and selected | states. You're right - it is. The comment on what state its valid for is in the formal syntax and I missed it there. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IM36t2039367 for ; Fri, 18 Apr 2003 15:03:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IM36X6039366 for ietf-imapext-bks; Fri, 18 Apr 2003 15:03:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IM35t2039359 for ; Fri, 18 Apr 2003 15:03:05 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3IM2tFd014840; Fri, 18 Apr 2003 15:02:55 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7/8.11.6) with ESMTP id h3IM4Ze26467; Fri, 18 Apr 2003 15:04:35 -0700 (PDT) Message-Id: <200304182204.h3IM4Ze26467@katroo.Sendmail.COM> To: Rob Siemborski Cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-reply-to: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> <200304180824.h3I8ODe28297@katroo.Sendmail.COM> Date: Fri, 18 Apr 2003 15:03:01 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: >On Fri, 18 Apr 2003, Philip Guenther wrote: > >> It's all a matter to explaining to the execs the costs of the tradeoffs >> that they're requesting. > >Sure, but that just moves around who is looking at the cost, the fact is >that server costs aren't the ONLY ones to consider. Right; that's why I used the word 'tradeoffs' to indicate that there are costs and benefits to every choice. Anyone who hides that fact only has themselves to blame when all the costs end up on their shoulders. Writing a protocol that does the same by transfering all the costs and complexity to the server is all too easy. There are reasons why IMAP and LDAP are widely implemented and ACAP isn't. ... >Saying that a proposal can't be improved because it is already better than >what we currently have doesn't make a lot of sense. Of course, faster is always better, but 1) going from "poll-interval" to "round-trip time" is a big saving compared to going from "round-trip time" to "instantly". For updating 'background' information in a human interface (that's the use people have been talking about), I suspect the benefit to the user is all in that first big step. 2) clients *do* poll instead of opening N connections, one per-mailbox, even though the latter offers "as soon as possible" updates, so clients are willing to make a tradeoff when faced with it If WATCH BIFF is implementable on most servers with what appears to be a very short poll interval ("I always see BIFFs within a second or so") but WATCH STATUS varies server to server, sometimes appearing to be as responsive as BIFFs but other times appearing to have, say, a 30 second poll interval, how will client authors react? Always use WATCH BIFF? Always use WATCH STATUS? Always use WATCH STATUS and tell your users to yell at the authors of the slow servers? Something else? Philip Guenther Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IKcNt2037349 for ; Fri, 18 Apr 2003 13:38:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IKcNVo037348 for ietf-imapext-bks; Fri, 18 Apr 2003 13:38:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (lamarth@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IKcLt2037343 for ; Fri, 18 Apr 2003 13:38:21 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id NAA06793; Fri, 18 Apr 2003 13:38:14 -0700 (PDT) Date: Fri, 18 Apr 2003 13:34:35 -0700 (PDT) From: Mark Crispin Subject: RE: WATCH extension for IMAP To: Rob Siemborski cc: John Milan , "'Philip Guenther'" , "'IMAP Extensions WG'" 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 Fri, 18 Apr 2003 16:30:55 -0400 (EDT), Rob Siemborski wrote: > Sorry, perhaps I should have phrased it as "several people on the list > have expressed interest in following up on this", (both "WATCH=BIFF" and > "WATCH=STATUS") but certainly a WATCH extention of some type. OK. I agree that there is some concensus with that wording. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IKV0t2037177 for ; Fri, 18 Apr 2003 13:31:00 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IKUxTM037176 for ietf-imapext-bks; Fri, 18 Apr 2003 13:30:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IKUwt2037171 for ; Fri, 18 Apr 2003 13:30:58 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from UNIX45.andrew.cmu.edu (UNIX45.andrew.cmu.edu [128.2.13.175]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp7.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3IKUurh019254; Fri, 18 Apr 2003 16:30:56 -0400 Date: Fri, 18 Apr 2003 16:30:55 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: John Milan , "'Philip Guenther'" , "'IMAP Extensions WG'" Subject: RE: WATCH extension for IMAP In-Reply-To: Message-ID: References: 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, 18 Apr 2003, Mark Crispin wrote: > On Fri, 18 Apr 2003 15:52:59 -0400 (EDT), Rob Siemborski wrote: > > So, I think its pretty clear that this is a desired feature to have. > > I don't see how you came up with that conclusion, unless you mean "desire" in > terms of "asking for the moon". Sorry, perhaps I should have phrased it as "several people on the list have expressed interest in following up on this", (both "WATCH=BIFF" and "WATCH=STATUS") but certainly a WATCH extention of some type. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IKOgt2037035 for ; Fri, 18 Apr 2003 13:24:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IKOgUI037034 for ietf-imapext-bks; Fri, 18 Apr 2003 13:24:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (jtis@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IKOet2037029 for ; Fri, 18 Apr 2003 13:24:40 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id NAA06774; Fri, 18 Apr 2003 13:24:30 -0700 (PDT) Date: Fri, 18 Apr 2003 12:55:03 -0700 (PDT) From: Mark Crispin Subject: RE: WATCH extension for IMAP To: Rob Siemborski cc: John Milan , "'Philip Guenther'" , "'IMAP Extensions WG'" 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 Fri, 18 Apr 2003 15:52:59 -0400 (EDT), Rob Siemborski wrote: > So, I think its pretty clear that this is a desired feature to have. I don't see how you came up with that conclusion, unless you mean "desire" in terms of "asking for the moon". > Is there anything more formal written than what's been in this thread on > the list? There is working code. It only needs final assembly. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJrBt2036487 for ; Fri, 18 Apr 2003 12:53:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IJrB3r036486 for ietf-imapext-bks; Fri, 18 Apr 2003 12:53:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJr6t2036481 for ; Fri, 18 Apr 2003 12:53:06 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3IJqxdg004650; Fri, 18 Apr 2003 15:52:59 -0400 Date: Fri, 18 Apr 2003 15:52:59 -0400 (EDT) From: Rob Siemborski To: John Milan cc: "'Mark Crispin'" , "'Philip Guenther'" , "'IMAP Extensions WG'" Subject: RE: WATCH extension for IMAP In-Reply-To: <000201c305db$40896a30$3d02a8c0@Grant> Message-ID: References: <000201c305db$40896a30$3d02a8c0@Grant> 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, 18 Apr 2003, John Milan wrote: > Why put so much effort into half measures? If everyone acknowledges > WATCH to be an issue worth solving why not *completely* solve it in the > protocol and wait for implementations to catch up. So, I think its pretty clear that this is a desired feature to have. However, it is decidedly difficult to discuss a hypothetical protocol extention. Is there anything more formal written than what's been in this thread on the list? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJPNt2035948 for ; Fri, 18 Apr 2003 12:25:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IJPNDc035947 for ietf-imapext-bks; Fri, 18 Apr 2003 12:25:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from teamdirection.com (s173.n12.vds2000.com [66.84.12.173]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJPMt2035941 for ; Fri, 18 Apr 2003 12:25:22 -0700 (PDT) (envelope-from johnm@teamdirection.com) Received: from Grant ([64.122.96.14]) by teamdirection.com (8.12.9/8.11.2) with SMTP id h3IJP39h017674; Fri, 18 Apr 2003 15:25:04 -0400 Reply-To: From: "John Milan" To: "'Mark Crispin'" Cc: "'Rob Siemborski'" , "'Philip Guenther'" , "'IMAP Extensions WG'" Subject: RE: WATCH extension for IMAP Date: Fri, 18 Apr 2003 12:25:03 -0700 Organization: TeamDirection.com Message-ID: <000301c305e0$37f82b90$3d02a8c0@Grant> 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, Build 10.0.2627 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: >> Why put so much effort into half measures? If everyone acknowledges >> WATCH to be an issue worth solving why not *completely* solve it in >> the protocol and wait for implementations to catch up. > Sometimes, implementations never catch up. FTP is an excellent example. I think this just means that some pieces are more important than others. As a developer for commercial software I'm often surprised at how the market responds to features regardless of my level of effort. It would be hard to argue that FTP is somehow wrong simply because the marketplace hasn't clamored for full implementation. In fact, the ubiquity of FTP speaks precisely to the fact that the designers thoroughly solved a problem, and that the world at large prioritized the bare minimum needed. > On the other hand, if you do a partial solution that solves the 98% case and is available now, it will be good enough *and* > get useful work accomplished. Well, 98% is more of a nearly complete solution than a partial solution my book :) If you think this is a nearly complete solution, then you are doing the right thing by pushing it. However, I would like to see expressions be watchable as well. Maybe that falls in the missing 2%, but other people are bringing up issues as well, so there may be a few more percentage points missing. My thesis is, regardless of whether it technically feasible or not, why not create a richer implementation of WATCH that addresses as many features everyone is proposing as possible. Yeah things get more complicated, but take a look at the XML spec. Talk about complicated! But if it solves a problem, then complication is a necessary tradeoff. And as the adoption of XML shows, implementors can navigate the complexity. I just think its very useful to address as many issues in a protocol as possible, not because you want to make life hard, but because its an excellent record of what people believe is an excellent and well-thought-out solution to a difficult problem. Or, for the executive summary, the less you have to assume about a protocol the better. A bit of a soap box moment, but thems my thoughts. JM Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJOtt2035930 for ; Fri, 18 Apr 2003 12:24:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IJOtpl035929 for ietf-imapext-bks; Fri, 18 Apr 2003 12:24:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJOrt2035924 for ; Fri, 18 Apr 2003 12:24:54 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4a-b-98.buf.adelphia.net [24.51.29.98]) (authenticated bits=0) by eagle.oceana.com (8.12.9/8.12.9) with ESMTP id h3IJJnTO015791 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Fri, 18 Apr 2003 15:19:49 -0400 (EDT) Message-ID: <3EA04FD7.B5D87545@oceana.com> Date: Fri, 18 Apr 2003 15:19:51 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: WATCH extension for IMAP References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> <200304180824.h3I8ODe28297@katroo.Sendmail.COM> <2147483647.1050673752@[63.163.82.24]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > > Hi Rob, > > --On Friday, April 18, 2003 1:34 PM -0400 Rob Siemborski > wrote: > > | That said, I was imagining WATCH=STATUS to work something like: > | > | a WATCH public.folder (UNSEEN) > | a OK Watching public.folder > | b NOOP > | b OK NOOP Done > | c NOOP > | * WATCH EXISTS "public.folder" > | * WATCH EXISTS "public.folder" > | * STATUS "public.folder" (UNSEEN 3) > | c OK NOOP done > > This shows up the problem that the client still has to poll via NOOP to get > results. Obviously, if a mailbox was selected, the client could use IDLE > and WATCH would come back during IDLE without the need to poll. But how > would we deal with a connection that does not have a selected mailbox? The > client could select a 'dummy' mailbox and then use idle, but wouldn't it be > better to allow IDLE outside of selected state if WATCH is present? IIRC, IDLE is already allowed in both the authenticated and selected states. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJ1Ht2035346 for ; Fri, 18 Apr 2003 12:01:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IJ1HME035345 for ietf-imapext-bks; Fri, 18 Apr 2003 12:01:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (del@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IJ1Gt2035340 for ; Fri, 18 Apr 2003 12:01:16 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id MAA06653; Fri, 18 Apr 2003 12:01:07 -0700 (PDT) Date: Fri, 18 Apr 2003 11:52:06 -0700 (PDT) From: Mark Crispin Subject: RE: WATCH extension for IMAP To: johnm@teamdirection.com cc: "'Rob Siemborski'" , "'Philip Guenther'" , "'IMAP Extensions WG'" In-Reply-To: <000201c305db$40896a30$3d02a8c0@Grant> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 18 Apr 2003 11:49:31 -0700, John Milan wrote: > Why put so much effort into half measures? If everyone acknowledges > WATCH to be an issue worth solving why not *completely* solve it in the > protocol and wait for implementations to catch up. Sometimes, implementations never catch up. FTP is an excellent example. > On the other hand, if you do a partial solution, then when it becomes > technically feasible or economically viable, the protocol will not be > correct and will splinter. On the other hand, if you do a partial solution that solves the 98% case and is available now, it will be good enough *and* get useful work accomplished. We'd still be arguing IMP-IMP protocol if we refused to do anything before we solved the last 2%. Notifications are not a new idea. The idea been bandied about for years. Nothing has gotten done because people have refused to make the necessary compromises necessary to accomplish results. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IInqt2035129 for ; Fri, 18 Apr 2003 11:49:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IInquu035128 for ietf-imapext-bks; Fri, 18 Apr 2003 11:49:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from teamdirection.com (s173.n12.vds2000.com [66.84.12.173]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IInkt2035117 for ; Fri, 18 Apr 2003 11:49:47 -0700 (PDT) (envelope-from johnm@teamdirection.com) Received: from Grant ([64.122.96.14]) by teamdirection.com (8.12.9/8.11.2) with SMTP id h3IInUIg026727; Fri, 18 Apr 2003 14:49:31 -0400 Reply-To: From: "John Milan" To: "'Mark Crispin'" , "'Rob Siemborski'" Cc: "'Philip Guenther'" , "'IMAP Extensions WG'" Subject: RE: WATCH extension for IMAP Date: Fri, 18 Apr 2003 11:49:31 -0700 Organization: TeamDirection.com Message-ID: <000201c305db$40896a30$3d02a8c0@Grant> 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, Build 10.0.2627 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: > After many years, the Cyrus server still does not implement the RENAME command correctly because it is technically infeasible > for it to do it right. >> Saying that a proposal can't be improved because it is already better >> than what we currently have doesn't make a lot of sense. >It makes perfect sense if the "improvement" precludes the entire thing from being implemented. The history of Internet > protocols is littered with specifications that weren't implemented because someone would not take "no" for an answer. > Sometimes if you refuse an offer as inadequate, you end up with nothing. Why put so much effort into half measures? If everyone acknowledges WATCH to be an issue worth solving why not *completely* solve it in the protocol and wait for implementations to catch up. For instance, not implementing the RENAME command correctly hasn't stopped the progress of Cyrus' IMAP server. And if the RENAME command is correct, then when it becomes technically feasible to do it right, the protocol will survive because it was correct. On the other hand, if you do a partial solution, then when it becomes technically feasible or economically viable, the protocol will not be correct and will splinter. I see no reason why the IMAP protocol can't fully define a WATCH extension and leave server vendors to figure out what pieces they can and can't support today. John Milan Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIh6t2035013 for ; Fri, 18 Apr 2003 11:43:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IIh5NO035012 for ietf-imapext-bks; Fri, 18 Apr 2003 11:43:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (clane@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIh4t2035007 for ; Fri, 18 Apr 2003 11:43:04 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA06628; Fri, 18 Apr 2003 11:42:04 -0700 (PDT) Date: Fri, 18 Apr 2003 11:39:14 -0700 (PDT) From: Mark Crispin Subject: re: WATCH: changes to mailboxes being watched To: Cyrus Daboo cc: IMAP Extensions WG In-Reply-To: <2147483647.1050676527@[63.163.82.24]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 18 Apr 2003 14:35:27 -0400, Cyrus Daboo wrote: > How should WATCH deal with changes to mailboxes being watched? The ultra-lightweight facility that I am offering has no provisions to deal with this. All it will do is deliver an event which matches. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIZPt2034658 for ; Fri, 18 Apr 2003 11:35:25 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IIZOl8034657 for ietf-imapext-bks; Fri, 18 Apr 2003 11:35:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIZNt2034652 for ; Fri, 18 Apr 2003 11:35:23 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA14260 for ; Fri, 18 Apr 2003 14:31:58 -0400 (EDT) Date: Fri, 18 Apr 2003 14:35:27 -0400 From: Cyrus Daboo To: IMAP Extensions WG Subject: WATCH: changes to mailboxes being watched Message-ID: <2147483647.1050676527@[63.163.82.24]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: How should WATCH deal with changes to mailboxes being watched? e.g.: what happens if a watched mailbox is deleted by some other client? Should the watched connection send back a response to indicate that the watched mailbox is now gone and there will be no more watch responses for that mailbox? What about renaming a mailbox? Does the watch state 'follow' a mailbox as it is renamed? Does the watched connection send a response indicating a name change by some other client? -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIUot2034487 for ; Fri, 18 Apr 2003 11:30:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IIUo4m034485 for ietf-imapext-bks; Fri, 18 Apr 2003 11:30:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIUnt2034479 for ; Fri, 18 Apr 2003 11:30:49 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA14238; Fri, 18 Apr 2003 14:27:12 -0400 (EDT) Date: Fri, 18 Apr 2003 14:30:40 -0400 From: Cyrus Daboo To: Pete Resnick cc: Rob Siemborski , Philip Guenther , IMAP Extensions WG Subject: Re: WATCH extension for IMAP Message-ID: <2147483647.1050676240@[63.163.82.24]> In-Reply-To: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> <200304180824.h3I8ODe28297@katroo.Sendmail.COM> <2147483647.1050673752@[63.163.82.24]> X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Pete, --On Friday, April 18, 2003 1:06 PM -0500 Pete Resnick wrote: |> This shows up the problem that the client still has to poll via NOOP |> to get results. | | Why? Isn't the WATCH response going to come in as unilateral server data? If WATCH is written to require idle-like behaviour ithout a command in progress that would be fine. But the implications of that for clients needs to be spelled out. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIKmt2034038 for ; Fri, 18 Apr 2003 11:20:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IIKmTI034037 for ietf-imapext-bks; Fri, 18 Apr 2003 11:20:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (btik@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IIKkt2034032 for ; Fri, 18 Apr 2003 11:20:46 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA06604; Fri, 18 Apr 2003 11:20:36 -0700 (PDT) Date: Fri, 18 Apr 2003 10:51:54 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Rob Siemborski cc: Philip Guenther , IMAP Extensions WG 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 Fri, 18 Apr 2003 13:34:19 -0400 (EDT), Rob Siemborski wrote: > Sure, but that just moves around who is looking at the cost, the fact is > that server costs aren't the ONLY ones to consider. Nevertheless, server costs can not be disregarded. After many years, the Cyrus server still does not implement the RENAME command correctly because it is technically infeasible for it to do it right. Real implementation concerns can not be disregarded just because it may be less of a concern in a particular implementation. There has to be compromise, and respect for the compromise. That is what interoperability is all about. > Saying that a proposal can't be improved because it is already better than > what we currently have doesn't make a lot of sense. It makes perfect sense if the "improvement" precludes the entire thing from being implemented. The history of Internet protocols is littered with specifications that weren't implemented because someone would not take "no" for an answer. Sometimes if you refuse an offer as inadequate, you end up with nothing. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3II6Ut2032585 for ; Fri, 18 Apr 2003 11:06:30 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3II6U7h032584 for ietf-imapext-bks; Fri, 18 Apr 2003 11:06:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3II6St2032565 for ; Fri, 18 Apr 2003 11:06:29 -0700 (PDT) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.1b1); Fri, 18 Apr 2003 13:06:30 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <2147483647.1050673752@[63.163.82.24]> References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> <200304180824.h3I8ODe28297@katroo.Sendmail.COM> <2147483647.1050673752@[63.163.82.24]> X-Mailer: Eudora [Macintosh version 6.0a15] Date: Fri, 18 Apr 2003 13:06:24 -0500 To: Cyrus Daboo From: Pete Resnick Subject: Re: WATCH extension for IMAP Cc: Rob Siemborski , Philip Guenther , IMAP Extensions WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 4/18/03 at 1:49 PM -0400, Cyrus Daboo wrote: >This shows up the problem that the client still has to poll via NOOP >to get results. Why? Isn't the WATCH response going to come in as unilateral server data? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IHnGt2031741 for ; Fri, 18 Apr 2003 10:49:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IHnG2H031740 for ietf-imapext-bks; Fri, 18 Apr 2003 10:49:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IHnFt2031733 for ; Fri, 18 Apr 2003 10:49:15 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA13855; Fri, 18 Apr 2003 13:45:44 -0400 (EDT) Date: Fri, 18 Apr 2003 13:49:12 -0400 From: Cyrus Daboo To: Rob Siemborski , Philip Guenther cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP Message-ID: <2147483647.1050673752@[63.163.82.24]> In-Reply-To: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> <200304180824.h3I8ODe28297@katroo.Sendmail.COM> X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Friday, April 18, 2003 1:34 PM -0400 Rob Siemborski wrote: | That said, I was imagining WATCH=STATUS to work something like: | | a WATCH public.folder (UNSEEN) | a OK Watching public.folder | b NOOP | b OK NOOP Done | c NOOP | * WATCH EXISTS "public.folder" | * WATCH EXISTS "public.folder" | * STATUS "public.folder" (UNSEEN 3) | c OK NOOP done This shows up the problem that the client still has to poll via NOOP to get results. Obviously, if a mailbox was selected, the client could use IDLE and WATCH would come back during IDLE without the need to poll. But how would we deal with a connection that does not have a selected mailbox? The client could select a 'dummy' mailbox and then use idle, but wouldn't it be better to allow IDLE outside of selected state if WATCH is present? -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IHYMt2031493 for ; Fri, 18 Apr 2003 10:34:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3IHYMqr031492 for ietf-imapext-bks; Fri, 18 Apr 2003 10:34:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3IHYKt2031485 for ; Fri, 18 Apr 2003 10:34:21 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp7.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3IHYKrh009071; Fri, 18 Apr 2003 13:34:20 -0400 Date: Fri, 18 Apr 2003 13:34:19 -0400 (EDT) From: Rob Siemborski To: Philip Guenther cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: <200304180824.h3I8ODe28297@katroo.Sendmail.COM> Message-ID: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> <200304180824.h3I8ODe28297@katroo.Sendmail.COM> 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, 18 Apr 2003, Philip Guenther wrote: > It's all a matter to explaining to the execs the costs of the tradeoffs > that they're requesting. Sure, but that just moves around who is looking at the cost, the fact is that server costs aren't the ONLY ones to consider. > Also, complaining about round-trips seems unfair, given that *right now* > the client has to poll. Unless your round-trip is on the same order as > your poll interval, Mark's lightweight proposal has a lower latency than > polling, period. Client that want STATUS information can throw a normal > STATUS command into their command pipe and still end up ahead of those > that just poll. Indeed, the client can sanely implement the batching > you proposed: "after receiving a notification, wait until N seconds have > passed *without* receiving a notification for that same mailbox, but no > more than M seconds total, before sending a STATUS command for the > mailbox". Saying that a proposal can't be improved because it is already better than what we currently have doesn't make a lot of sense. That said, I was imagining WATCH=STATUS to work something like: a WATCH public.folder (UNSEEN) a OK Watching public.folder b NOOP b OK NOOP Done c NOOP * WATCH EXISTS "public.folder" * WATCH EXISTS "public.folder" * STATUS "public.folder" (UNSEEN 3) c OK NOOP done (you could, in this case, just drop the "WATCH" responses, I have them there just to indicate more than one message arrived). But the idea was that you wouldn't queue them up based on a time interval, you'd send the status as soon as there was new mail, within the same response that would cover just the first message. Maybe the looser requirements of the POLL command are good enough, I'd like to hear from a client author though. Certainly, it is an improvement of having the client POLL explicitly though. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3I8Mjt2002990 for ; Fri, 18 Apr 2003 01:22:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3I8Mje7002989 for ietf-imapext-bks; Fri, 18 Apr 2003 01:22:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3I8Met2002983 for ; Fri, 18 Apr 2003 01:22:45 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3I8MXFd028771; Fri, 18 Apr 2003 01:22:33 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7/8.11.6) with ESMTP id h3I8ODe28297; Fri, 18 Apr 2003 01:24:13 -0700 (PDT) Message-Id: <200304180824.h3I8ODe28297@katroo.Sendmail.COM> To: Rob Siemborski Cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-reply-to: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> Date: Fri, 18 Apr 2003 01:22:45 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: >On Thu, 17 Apr 2003, Mark Crispin wrote: >>> Or how about this: Suppose any time >>> your users had to wait for the server cost you $5. >> >> This is also nonsense. Customers pay their service providers, not the >> other way around. > >Sure, but ISPs aren't the only ones providing IMAP service. IT >departments in corporations likely can't easily say to their VP, >Presidents, or CEOs "screw you, our server resources are worth more than >your time". Sure they can: "enabling that feature will result in increased server costs on the order of N thousand dollars per-year. In the best judgement of our staff, the ROI of such an expenditure is worse than that of the following other items. If you tell us to, we can, of course, move it up on our priority list, but please be aware that something else will have to give." When I was sysadmin at a college in Minnesota, we pushed back on "orders from on high" all the time. Sometimes our VP agreed with our judgement/reasoning and relaxed the mandate, other times we were told that the benefits were more than we thought (publicity, inter-department deals, prestige of the VP, whatever) and so we were the ones to give. It's all a matter to explaining to the execs the costs of the tradeoffs that they're requesting. ... ... >All that said, there is NO REASON, that a WATCH extention can not be >extensible enough serve both the "ultra-lightweight" people and the "I >want to STATUS every folder on every message arrival" people, without >requiring additional round trips. Using the same name for different actions isn't a step forward. You've already suggested that a WATCH STATUS should batch responses, while Mark has mentioned dropping notifications if the queue overflows. Those are significantly different behaviors and I would expect some servers to implement them with completely different backend mechanisms with completely different efficiencies and latencies. Calling them the same thing encourages clients to treat them the same, which skews the tradeoffs. Also, complaining about round-trips seems unfair, given that *right now* the client has to poll. Unless your round-trip is on the same order as your poll interval, Mark's lightweight proposal has a lower latency than polling, period. Client that want STATUS information can throw a normal STATUS command into their command pipe and still end up ahead of those that just poll. Indeed, the client can sanely implement the batching you proposed: "after receiving a notification, wait until N seconds have passed *without* receiving a notification for that same mailbox, but no more than M seconds total, before sending a STATUS command for the mailbox". Is that a 90% solution? If not and what client authors really want is a batched STATUS update, then perhaps we should be discussing a 'POLL' extension, say, something like: POLL Command Arguments: max-period STATUS command arguments Responses: untagged STATUS Result: OK - initial data returned, command will be performed as requested NO - too many POLLs requested or max-period too small BAD - command unknown or arguments invalid The POLL command requests that the IMAP server immediately perform the specified STATUS command and return its response. After the tagged OK, the server will continue to monitor the mailbox and unilaterally send updated STATUS responses for that mailbox. The server SHOULD NOT send an update unless the mailbox has actually been changed, though it MAY send an update for a mailbox that has change in ways not reflected in the STATUS response. [Alternatively, we could simply require it to track what it last sent and never send the exact same response twice in a row, even when the value changed but returned to their previous value before it composed the updated response.] If an update is to be sent, the server MAY delay sending it (e.g., so that the server can consolidate multiple changes into a single STATUS response), but MUST send it no later than if the server had received the specified STATUS command directly from the client 'max-period' seconds after the actual update occured. [Blech. How to phrase it that the server can't have any greater latency than a client that polled every 'max-period' seconds?] The server may limit the number of POLL commands that it will support on a single IMAP connection and may require the max-period to be no smaller than a give value. Those limits will be advertised in the capability string, blah blah blah. [What are the minimum requirements to comply? 20 concurrent POLLs, supporting a max-period of 20 seconds or more?] If a client issues a SELECT or EXAMINE command for a mailbox for which it previously issued a POLL command on the same connection, the server SHOULD suppress all STATUS updates for that mailbox for as long as the client has it selected. Example: C: A042 POLL 30 STATUS "Lists/imapext" (UNSEEN) S: * STATUS "Lists/imapext" (UNSEEN 3) S: A042 OK POLL started ...time passes; new mail arrives S: * STATUS "Lists/imapext" (UNSEEN 10) ... I tried to write the above to allow both implementations that would simply poll at the requested rate and those that would be truly notification triggered, while hopefully making the result compelling for clients either way. Philip Guenther Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLv8t2064075 for ; Thu, 17 Apr 2003 14:57:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HLv8hH064074 for ietf-imapext-bks; Thu, 17 Apr 2003 14:57:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLv7t2064069 for ; Thu, 17 Apr 2003 14:57:07 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp7.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3HLuwrh030873; Thu, 17 Apr 2003 17:56:58 -0400 Date: Thu, 17 Apr 2003 17:56:58 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Lawrence Greenfield , Cyrus Daboo , IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: Message-ID: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> 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, 17 Apr 2003, Mark Crispin wrote: > > Or how about this: Suppose any time > > your users had to wait for the server cost you $5. > > This is also nonsense. Customers pay their service providers, not the > other way around. Sure, but ISPs aren't the only ones providing IMAP service. IT departments in corporations likely can't easily say to their VP, Presidents, or CEOs "screw you, our server resources are worth more than your time". > Wait a second. You are implying that it is "frequent" that people will be > reading mail with more than one computer simultaneously. > > Once again, how frequent? Well, for me (using pine), all the time, actually. In fact, I'll often find myself with several pine sessions on the same machine. > How frequent is it that a user is distraught that one of his simultaneous > running clients isn't showing a new mail messages that he has already read > on his other simultaneously running client? If I accidently leave pine connected to a folder at work (happens almost every day, to various folders), then go home, pine at home won't notice that new mail has arrived in that folder when I hit "tab" to scan through my incoming folders, because the \Recent flags are being unset by the session at work. I haven't actually read (or even been notified of) the new messages. Sure "doctor, it hurts when I do this!", but it's an example of a very real problem with \Recent semantics. > The minimum definition of "interesting" in this context is defined in the > specification. RFC3501>>> \Marked The mailbox has been marked "interesting" by the server; the mailbox probably contains messages that have been added since the last time the mailbox was selected. <<< I don't see a minimum requirement. I see, at best, a suggestion of what "interesting" might mean. > > With this sort of specification, it is not surprising that clients > > choose not to use \Marked for anything. > > I claim that it's because of lazy programmers who only use fast > connections . Nevermind the fact that servers are allowed to not return \Marked or \Unmarked at all, if they feel like it, making the feature basically useless in the general case anyway. All that said, there is NO REASON, that a WATCH extention can not be extensible enough serve both the "ultra-lightweight" people and the "I want to STATUS every folder on every message arrival" people, without requiring additional round trips. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLXvt2063150 for ; Thu, 17 Apr 2003 14:33:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HLXvF6063149 for ietf-imapext-bks; Thu, 17 Apr 2003 14:33:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HLXut2063144 for ; Thu, 17 Apr 2003 14:33:56 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3HLXsTc024869; Thu, 17 Apr 2003 14:33:54 -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+UW03.04/8.12.1+UW02.12) with ESMTP id h3HLXs8H029788 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Apr 2003 14:33:54 -0700 Date: Thu, 17 Apr 2003 14:33:54 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lawrence Greenfield cc: Cyrus Daboo , IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> Message-ID: References: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> 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 Thu, 17 Apr 2003, Lawrence Greenfield wrote: > Suppose your ISP had a charging system such that LIST was free, but each > STATUS cost $.05 (.05 Euros, 5 yen, take your pick...). Would you do things > differently? > Suppose your ISP had a charging system such that LIST responses were > 0.05 cents and STATUS was free. That's nonsense. LIST can never be more expensive than STATUS. I remind you; ISPs are disabling SEARCH in IMAP because they think it is too expensive. > Or how about this: Suppose any time > your users had to wait for the server cost you $5. This is also nonsense. Customers pay their service providers, not the other way around. > And this is one of the reasons that we're making LISTEXT be able to > return STATUS responses. Which I feel to be a serious mistake. Tell me, when is Cyrus going to implement RENAME according to the specification and remove its bogus NO_ATOMIC_RENAME capability? > True, the multiple clients connected to the same mailbox case is a problem. > But is that the 99% case? > 99% case? Of course not. A very frequent thing? Yes. How much is "very frequent"? 1% of the time? .001% of the time? > Many people read > e-mail with more than one computer. Will it become more frequent? I > hope so---and many many people have cell phones. Wait a second. You are implying that it is "frequent" that people will be reading mail with more than one computer simultaneously. Once again, how frequent? How frequent is it that a user is distraught that one of his simultaneous running clients isn't showing a new mail messages that he has already read on his other simultaneously running client? The day that email spam hits cell phones en masse will be the day that we see an end to that particular silliness, particularly in the US with its "cell phone user always pays" pricing model and carriers which can't even provide reliable service in the middle of a city. > Since LIST \Marked isn't required and isn't even well specified. (My > server could consider any message containing the word "penguin" > interesting---not very useful to anyone but me, but _I_ find those > messages "interesting".) The minimum definition of "interesting" in this context is defined in the specification. It is not implausible that there might be an IMAP extension to add "containing the word penguin" to the definition of "interesting". > With this sort of specification, it is not surprising that clients > choose not to use \Marked for anything. I claim that it's because of lazy programmers who only use fast connections . -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HKHRt2059840 for ; Thu, 17 Apr 2003 13:17:27 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HKHRHf059839 for ietf-imapext-bks; Thu, 17 Apr 2003 13:17:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HKHPt2059833 for ; Thu, 17 Apr 2003 13:17:25 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id AD6C75E017F5; Thu, 17 Apr 2003 23:17:26 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: IMAP Extensions WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050610646.16342.229.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 23:17:26 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 21:54, Mark Crispin wrote: > On 17 Apr 2003 21:46:18 +0300, Timo Sirainen wrote: > > I haven't actually thought of a single good usage of \Marked flag. It > > pretty much means that there's probably \Recent messages in the mailbox. > > Consider this thought exercise. > > Suppose your ISP had a charging system such that LIST was free, but each > STATUS cost $.05 (.05 Euros, 5 yen, take your pick...). Would you do things > differently? Maybe. But since it currently doesn't cost more than server resources, good user interface is more important to me as a user (and as admin for server with only a couple of users). > Wouldn't you do a LIST to determine whether or not you should do a STATUS? > After all, you can do a wildcard with the LIST. > > True, the multiple clients connected to the same mailbox case is a problem. > But is that the 99% case? I think that's one of the best features in IMAP. I use it, so checking only \Marked mailboxes wouldn't be enough for me. If the choice is between using more server resources and not necessarily seeing new message for hours or even days after it's received, I choose the resource consumption any time. Of course, client could do LIST often and ask STATUS for \Marked folders immediately, but still ask STATUS for non-marked folders at least once every n minutes. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJwEt2059276 for ; Thu, 17 Apr 2003 12:58:14 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HJwEjJ059274 for ietf-imapext-bks; Thu, 17 Apr 2003 12:58:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJwCt2059242 for ; Thu, 17 Apr 2003 12:58:12 -0700 (PDT) (envelope-from leg+@andrew.cmu.edu) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp6.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3HJw4df008659; Thu, 17 Apr 2003 15:58:04 -0400 Date: Thu, 17 Apr 2003 15:58:04 -0400 Message-Id: <200304171958.h3HJw4df008659@smtp6.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Cyrus Daboo , Mark Crispin Cc: IMAP Extensions WG , Mark Crispin In-reply-to: Subject: Re: WATCH extension for IMAP References: User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Thu, 17 Apr 2003 11:54:55 -0700 (PDT) From: Mark Crispin [...] Suppose your ISP had a charging system such that LIST was free, but each STATUS cost $.05 (.05 Euros, 5 yen, take your pick...). Would you do things differently? Suppose your ISP had a charging system such that LIST responses were 0.05 cents and STATUS was free. Or how about this: Suppose any time your users had to wait for the server cost you $5. Wouldn't you prefetch as much data as possible? Wouldn't you do a LIST to determine whether or not you should do a STATUS? After all, you can do a wildcard with the LIST. And this is one of the reasons that we're making LISTEXT be able to return STATUS responses. True, the multiple clients connected to the same mailbox case is a problem. But is that the 99% case? 99% case? Of course not. A very frequent thing? Yes. Many people read e-mail with more than one computer. Will it become more frequent? I hope so---and many many people have cell phones. On Thu, 17 Apr 2003 21:01:25 +0200, Simon Josefsson wrote: > Some clients like to only display the mailbox that have unread > messages on the screen. So to find out which of the 1800 mailboxes to > display, the client sends STATUS for all of them. Such a client should use the LIST \Marked flag and not STATUS. Since LIST \Marked isn't required and isn't even well specified. (My server could consider any message containing the word "penguin" interesting---not very useful to anyone but me, but _I_ find those messages "interesting".) With this sort of specification, it is not surprising that clients choose not to use \Marked for anything. It is important that any notification mechanism ("light weight" or not) has well defined semantics that actually match what clients are interested in. Larry Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJawt2058699 for ; Thu, 17 Apr 2003 12:36:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HJaw3u058698 for ietf-imapext-bks; Thu, 17 Apr 2003 12:36:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJaut2058692 for ; Thu, 17 Apr 2003 12:36:56 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3HJanXK031775 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Apr 2003 21:36:50 +0200 To: Mark Crispin Cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP X-Payment: hashcash 1.2 0:030417:MRC@CAC.Washington.EDU:33dd8351ec3be070 X-Hashcash: 0:030417:MRC@CAC.Washington.EDU:33dd8351ec3be070 X-Payment: hashcash 1.2 0:030417:ietf-imapext@imc.org:46c44f70318a08f7 X-Hashcash: 0:030417:ietf-imapext@imc.org:46c44f70318a08f7 From: Simon Josefsson Date: Thu, 17 Apr 2003 21:36:49 +0200 In-Reply-To: (Mark Crispin's message of "Thu, 17 Apr 2003 11:54:55 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Thu, 17 Apr 2003 21:01:25 +0200, Simon Josefsson wrote: >> Some clients like to only display the mailbox that have unread >> messages on the screen. So to find out which of the 1800 mailboxes to >> display, the client sends STATUS for all of them. > > Such a client should use the LIST \Marked flag and not STATUS. No, LIST \Marked means the mailbox contain "interesting" messages. "Interesting" (recent) and unread are not the same thing, and some users prefer to display only mailboxes with unread messages, so the client must send STATUS for all of them. See RFC 3501: The LIST command SHOULD return its data quickly, without undue delay. For example, it SHOULD NOT go to excess trouble to calculate the \Marked or \Unmarked status or perform other processing; if each name requires 1 second of processing, then a list of 1200 names would take 20 minutes! ... \Marked The mailbox has been marked "interesting" by the server; the mailbox probably contains messages that have been added since the last time the mailbox was selected. ... If it is not feasible for the server to determine whether or not the mailbox is "interesting", or if the name is a \Noselect name, the server SHOULD NOT send either \Marked or \Unmarked. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJ9kt2057920 for ; Thu, 17 Apr 2003 12:09:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HJ9kCS057919 for ietf-imapext-bks; Thu, 17 Apr 2003 12:09:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (mtk@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJ9it2057914 for ; Thu, 17 Apr 2003 12:09:45 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id MAA04514; Thu, 17 Apr 2003 12:09:38 -0700 (PDT) Date: Thu, 17 Apr 2003 11:54:55 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Cyrus Daboo cc: Mark Crispin , IMAP Extensions WG In-Reply-To: <2147483647.1050590644@[63.163.82.24]> 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, 17 Apr 2003 14:44:04 -0400, Cyrus Daboo wrote: > \Marked is useful for finding out which mailboxes have new mail at the > start of a session (i.e. when LIST is done) but to keep that information up > to date, the client would have to do some form of LIST polling, at which > point you might just as well use status. On 17 Apr 2003 21:46:18 +0300, Timo Sirainen wrote: > I haven't actually thought of a single good usage of \Marked flag. It > pretty much means that there's probably \Recent messages in the mailbox. Consider this thought exercise. Suppose your ISP had a charging system such that LIST was free, but each STATUS cost $.05 (.05 Euros, 5 yen, take your pick...). Would you do things differently? Wouldn't you do a LIST to determine whether or not you should do a STATUS? After all, you can do a wildcard with the LIST. True, the multiple clients connected to the same mailbox case is a problem. But is that the 99% case? I suspect that the 99.99% case of multiple clients connected to the same mailbox is the *same* client with multiple sessions to the same mailbox. In that case, the client is perfectly capable of resolving the confusion itself. On Thu, 17 Apr 2003 21:01:25 +0200, Simon Josefsson wrote: > Some clients like to only display the mailbox that have unread > messages on the screen. So to find out which of the 1800 mailboxes to > display, the client sends STATUS for all of them. Such a client should use the LIST \Marked flag and not STATUS. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJ5It2057809 for ; Thu, 17 Apr 2003 12:05:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HJ5IaB057808 for ietf-imapext-bks; Thu, 17 Apr 2003 12:05:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJ5Gt2057803 for ; Thu, 17 Apr 2003 12:05:17 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3HJ58XK031114 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Apr 2003 21:05:09 +0200 To: Mark Crispin Cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP X-Payment: hashcash 1.2 0:030417:mrc@CAC.Washington.EDU:263af9c1b5e0faf9 X-Hashcash: 0:030417:mrc@CAC.Washington.EDU:263af9c1b5e0faf9 X-Payment: hashcash 1.2 0:030417:ietf-imapext@imc.org:f3ea133182faec6a X-Hashcash: 0:030417:ietf-imapext@imc.org:f3ea133182faec6a From: Simon Josefsson Date: Thu, 17 Apr 2003 21:05:08 +0200 In-Reply-To: (Mark Crispin's message of "Thu, 17 Apr 2003 09:39:53 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > The question is: > > If there was an ultra-lightweight notification mechanism available very > soon, would you use it? > OR > Do you say, "No, I can not make use of an ultra-lightweight notification > facility. I'd rather wait until LEMONADE finishes its work, and then wait > for that work to be implemented. Until then, I'd rather have nothing at > all." The charter for LEMONADE does not make it clear (to me, at least) that the message notification protocol they will develop is an IMAP extension. A notification protocol is not mentioned in the milestones of the group either. And no drafts. > I'm trying to ascertain if it's worth the effort. Personally, I believe > that while it isn't ideal, it's good enough. Since it appears (at best) unclear (to me) that LEMONADE will ever specify a IMAP notification facility with the bells and whistles I'd want, I don't think an effort in this direction would hurt. If if you changed your proposal into also providing (at least) the uidvalidity of the mailbox and uid of the new message, I'm positively for it. It doesn't appear like it would cost much to implement this change. If LEMONADE is on track towards creating a feature rich notification IMAP extension, I think it is a mistake to push your proposal now as it would result in two only slightly different solutions to the same problem. Just my .2 SEK. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJ1st2057659 for ; Thu, 17 Apr 2003 12:01:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HJ1scn057658 for ietf-imapext-bks; Thu, 17 Apr 2003 12:01:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HJ1qt2057652 for ; Thu, 17 Apr 2003 12:01:53 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3HJ1PXK031006 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Apr 2003 21:01:28 +0200 To: Mark Crispin Cc: Cyrus Daboo , Timo Sirainen , Rob Siemborski , IMAP Extensions WG Subject: Re: WATCH extension for IMAP X-Payment: hashcash 1.2 0:030417:MRC@CAC.Washington.EDU:acff93aeeba95b3c X-Hashcash: 0:030417:MRC@CAC.Washington.EDU:acff93aeeba95b3c X-Payment: hashcash 1.2 0:030417:daboo@cyrusoft.com:e2265727f847a7e5 X-Hashcash: 0:030417:daboo@cyrusoft.com:e2265727f847a7e5 X-Payment: hashcash 1.2 0:030417:tss@iki.fi:8f275944499686e6 X-Hashcash: 0:030417:tss@iki.fi:8f275944499686e6 X-Payment: hashcash 1.2 0:030417:rjs3@andrew.cmu.edu:23a2a44a31328c00 X-Hashcash: 0:030417:rjs3@andrew.cmu.edu:23a2a44a31328c00 X-Payment: hashcash 1.2 0:030417:ietf-imapext@imc.org:acffedc72037dbdd X-Hashcash: 0:030417:ietf-imapext@imc.org:acffedc72037dbdd From: Simon Josefsson Date: Thu, 17 Apr 2003 21:01:25 +0200 In-Reply-To: (Mark Crispin's message of "Thu, 17 Apr 2003 11:26:02 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Thu, 17 Apr 2003 14:15:10 -0400, Cyrus Daboo wrote: >> STATUS is often used to show a count of the total number of messages and >> number of unseen messages in a 'closed' mailbox. > > I understand why people want/like that. But why do STATUS of 1800 mailboxes > when only 20 are currently visible on the screen? Some clients like to only display the mailbox that have unread messages on the screen. So to find out which of the 1800 mailboxes to display, the client sends STATUS for all of them. The client could also be a batch client, that slurps in all information it could possibly need, in order to be fast once it gotten past the slow startup, instead of being slightly slow (depending on the server) all the time. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HItCt2057364 for ; Thu, 17 Apr 2003 11:55:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HItCtH057363 for ietf-imapext-bks; Thu, 17 Apr 2003 11:55:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (mccabe@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HItAt2057358 for ; Thu, 17 Apr 2003 11:55:10 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA04484; Thu, 17 Apr 2003 11:54:45 -0700 (PDT) Date: Thu, 17 Apr 2003 11:42:41 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Cyrus Daboo cc: Rob Siemborski , IMAP Extensions WG In-Reply-To: <2147483647.1050590421@[63.163.82.24]> 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, 17 Apr 2003 14:40:21 -0400, Cyrus Daboo wrote: > You need to think about GUI clients that may have multiple views on screen > at the same time, all being updated and maintained as server state changes. I mentioned that possibility. On the other hand, there's only so much screen real estate. Most users do not have a screen large enough to display the message counts for 1800 mailboxes, and display an index of messages, a message being read, and a message being composed. Unfortunately, I see clients behave as if this is the user's display environment, the client has unlimited network bandwidth to the server, and the server has unlimited resources to respond to client demands. I see clients behave this way when the user is on a dialup IP connection from a laptop with a 14" screen. Much of the "IMAP is chatty" and "IMAP is slow" and "IMAP is resource intensive" folklore comes out of such experience. I'm not saying that Mulberry does this. But there are clients which do so. One of my ways of judging a "quality IMAP client" is the user experience and how much it costs to read your mail over roaming CDPD (at $.05/kilobyte!). LEMONADE should be an eye-opener. A lot about LEMONADE frightens me, but overall I think that it is a good thing that LEMONADE has happened. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIojt2057163 for ; Thu, 17 Apr 2003 11:50:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIojGQ057162 for ietf-imapext-bks; Thu, 17 Apr 2003 11:50:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIoit2057143 for ; Thu, 17 Apr 2003 11:50:44 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.9/8.12.9) with ESMTP id h3HInxTN020943; Thu, 17 Apr 2003 14:49:59 -0400 (EDT) Message-ID: <3E9EF813.5A0C0F39@oceana.com> Date: Thu, 17 Apr 2003 14:53:07 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Crispin CC: Rob Siemborski , Timo Sirainen , Cyrus Daboo , IMAP Extensions WG Subject: Re: WATCH extension for IMAP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > > On Thu, 17 Apr 2003 14:01:32 -0400 (EDT), Rob Siemborski wrote: > > Of course, if the user has recieved new mail in 1800 separate mailboxes, > > in a notification period, I'd say the server is under a pretty high load > > already. > > I wasn't talking about. I was talking about client startup. > > Does the client do 1800 STATUS commands when the user first goes into the list > of mailboxes? If so, I think that client has a problem. > > > I'm not sure if its better for the client to say on per session basis > > "tell me about mailboxes x, y, z, a, b, c" or just let the client say > > "tell me about my subscribed mailboxes". I think I like the former, > > actually. > > So do we! > > Originally, that was what subscribed mailboxes were supposed to do, but the > abuse of the subscription feature by certain other clients put an end to that > idea. > > In effect, it is a type of subscription; it's just kept in client > configuration instead of by the server. That keeps it safe from the > aforementioned certain other clients, but on the other hand other clients > won't inherit that information either. This might be a good mailbox annotation, eg: /mailbox/{}/watch (or whatever the syntax ends up being) -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIoYt2057141 for ; Thu, 17 Apr 2003 11:50:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIoYY6057140 for ietf-imapext-bks; Thu, 17 Apr 2003 11:50:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIoVt2057135 for ; Thu, 17 Apr 2003 11:50:32 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id D598F5E017F5; Thu, 17 Apr 2003 21:50:32 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: Rob Siemborski , Cyrus Daboo , IMAP Extensions WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050605432.16343.194.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 21:50:32 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 21:36, Mark Crispin wrote: > What I see is neither of the above. > > I see clients doing LIST "" * followed by STATUS of each returned name, at > startup. I see this repeated at periodic (obviously polling) intervals. > > The resulting experience is not good for the server or the user. Yeah, most IMAP clients suck. BTW. I wrote this some weeks ago: http://dovecot.procontrol.fi/imap-client-coding-howto.html Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HInCt2057071 for ; Thu, 17 Apr 2003 11:49:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HInC9Z057070 for ietf-imapext-bks; Thu, 17 Apr 2003 11:49:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from teamdirection.com (s173.n12.vds2000.com [66.84.12.173]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HInAt2057062 for ; Thu, 17 Apr 2003 11:49:11 -0700 (PDT) (envelope-from johnm@teamdirection.com) Received: from grendel (12-228-90-244.client.attbi.com [12.228.90.244]) by teamdirection.com (8.12.9/8.11.2) with SMTP id h3HIn0d8030689; Thu, 17 Apr 2003 14:49:00 -0400 From: "John Milan" To: "Mark Crispin" Cc: "IMAP Extensions WG" Subject: RE: WATCH extension for IMAP Date: Thu, 17 Apr 2003 11:57:37 -0700 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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > That is, in your "WATCH new mail where from = myboss@company.com" example, you > would get all new mail events, and locally filter out the ones that are not > from "myboss@company.com". Hmmm... But I thought one of the features of the IMAP protocol was 'smart' remote access. For instance, if I'm on a slow connection, I don't necessarily have to get all my mail messages. It seems to me that if I am in a connection speed challeged environment, I'd rather have the server filter out the messages I'm watching for than have to download all new messages and filter locally. Especially if I have a hotmail account with lots of spam. Such an environment might have a powerful server, but many remote access users, perhaps each using a dialup connection-- like the travelling salesman in his hotel room. They might be very interested in what their boss has to say, but not the funny movies their friends sent to them. I suppose just filtering off the message headers takes care of the above example, but then you can never really do content evaluation-- to costly to send everything across the wire. This just seems like building a problem into the protocol, especially when mail clients 'expect' this behavior in the future. John Milan Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIkJt2056984 for ; Thu, 17 Apr 2003 11:46:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIkJJY056983 for ietf-imapext-bks; Thu, 17 Apr 2003 11:46:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIkHt2056976 for ; Thu, 17 Apr 2003 11:46:18 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id CCBCD5E017F5; Thu, 17 Apr 2003 21:46:18 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: Cyrus Daboo , Rob Siemborski , IMAP Extensions WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050605178.16343.188.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 21:46:18 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 21:26, Mark Crispin wrote: > > Just indicating which have > > new mail is not enough - after all that is what \Marked does in LIST and > > very few implementations have bothered to use it. > > I never understood why this is the case. I haven't actually thought of a single good usage of \Marked flag. It pretty much means that there's probably \Recent messages in the mailbox. Those are another thing which I haven't found very useful. In single client case I guess it works well enough, but as soon as you have multiple clients connected to same mailbox, the behaviour gets pretty much random. Just because the client at work office noticed the mail before the client at home, doesn't mean that I wouldn't want to get notification of it when I'm at home. \Marked flag tells only that there's a folder where you very likely find new mail, but a client can't make any assumption if non-marked folders have new mail. So it ends up sending STATUS for all of them anyway. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIi5t2056862 for ; Thu, 17 Apr 2003 11:44:05 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIi59Q056861 for ietf-imapext-bks; Thu, 17 Apr 2003 11:44:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIi3t2056856 for ; Thu, 17 Apr 2003 11:44:04 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA06185; Thu, 17 Apr 2003 14:40:35 -0400 (EDT) Date: Thu, 17 Apr 2003 14:44:04 -0400 From: Cyrus Daboo To: Mark Crispin cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP Message-ID: <2147483647.1050590644@[63.163.82.24]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Thursday, April 17, 2003 11:26 AM -0700 Mark Crispin wrote: |> Just indicating which have |> new mail is not enough - after all that is what \Marked does in LIST and |> very few implementations have bothered to use it. | | I never understood why this is the case. \Marked is useful for finding out which mailboxes have new mail at the start of a session (i.e. when LIST is done) but to keep that information up to date, the client would have to do some form of LIST polling, at which point you might just as well use status. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIgkt2056832 for ; Thu, 17 Apr 2003 11:42:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIgkoh056831 for ietf-imapext-bks; Thu, 17 Apr 2003 11:42:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (lamarth@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIgjt2056824 for ; Thu, 17 Apr 2003 11:42:45 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA04465; Thu, 17 Apr 2003 11:42:34 -0700 (PDT) Date: Thu, 17 Apr 2003 11:36:58 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Rob Siemborski cc: Timo Sirainen , Cyrus Daboo , IMAP Extensions WG 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 Thu, 17 Apr 2003 14:31:10 -0400 (EDT), Rob Siemborski wrote: > I suppose that depends on your goal. If you assume STATUS is going to > take a long time, then from a user experience perspective it makes sense > to do them when the network connection is otherwise idle. > > If, on the other hand, you are solely concerned with overall server > performance, then you probably want this to be as lazy as possible. What I see is neither of the above. I see clients doing LIST "" * followed by STATUS of each returned name, at startup. I see this repeated at periodic (obviously polling) intervals. The resulting experience is not good for the server or the user. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIeNt2056775 for ; Thu, 17 Apr 2003 11:40:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIeN3l056774 for ietf-imapext-bks; Thu, 17 Apr 2003 11:40:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIeMt2056769 for ; Thu, 17 Apr 2003 11:40:22 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA06137; Thu, 17 Apr 2003 14:36:52 -0400 (EDT) Date: Thu, 17 Apr 2003 14:40:21 -0400 From: Cyrus Daboo To: Mark Crispin , Rob Siemborski cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP Message-ID: <2147483647.1050590421@[63.163.82.24]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Thursday, April 17, 2003 11:03 AM -0700 Mark Crispin wrote: |> Of course, if the user has recieved new mail in 1800 separate mailboxes, |> in a notification period, I'd say the server is under a pretty high load |> already. | | I wasn't talking about. I was talking about client startup. | | Does the client do 1800 STATUS commands when the user first goes into the | list of mailboxes? If so, I think that client has a problem. That depends on how the client is implemented. We do all STATUS work via a background thread so it won't interfere with the user. And yes, the user could easily set things up so that they do 1800 STATUS commands. We have many users that like to have message counts on their entire personal hierarchy appear on startup - so those can all get checked once, and then a different (smaller) set checked at varying intervals after that. |> I'm not sure if its better for the client to say on per session basis |> "tell me about mailboxes x, y, z, a, b, c" or just let the client say |> "tell me about my subscribed mailboxes". I think I like the former, |> actually. | | So do we! | | Originally, that was what subscribed mailboxes were supposed to do, but | the abuse of the subscription feature by certain other clients put an end | to that idea. | | In effect, it is a type of subscription; it's just kept in client | configuration instead of by the server. That keeps it safe from the | aforementioned certain other clients, but on the other hand other clients | won't inherit that information either. Yes - subscribe has been abused :-( Note that ANNOTATEMORE does have an annotation that's meant to be used to indicate which mailboxes should be checked for new mail, so hopefully co-operating clients can use that once its implemented. |> But if the client author knows they are going to do a status for every |> notification anyway (or every set of notifications on a mailbox), then |> why cost them the additional round trip? | | Perhaps to discourage clients from doing that? Perhaps to encourage | innovative thinking that would avoid unnecessary STATUS commands? | | One very obvious thing would be to defer doing a STATUS command until the | user is in the list of mailboxes screen. It's rather silly to do 50 | STATUS commands on a mailbox while the user's screen is busy in composing | a message. | | This wouldn't hold for a client that always shows a list of mailboxes, | but the general idea still applies. If the data isn't visible on the | user's screen (the client is in a different mode, or that particular data | is scrolled out of the visible view, or even if another window overlaps), | then there's no need to update it until it becomes visible. | You need to think about GUI clients that may have multiple views on screen at the same time, all being updated and maintained as server state changes. All that can be done in the background without interfering with the user's current focus. Plus, whether the mailbox is on screen or not is not relevant as the new mail check might bring it on screen if it has new mail or require some other form of notification that does not depend on the visibility of the mailbox itself (e.g. an audible text-to-speech alert that reads the name of the mailbox and the number of new messages). All of this is very much a client implementation issue. Providing a way to get status automatically will benefit a number of clients that are already doing expensive (polled) status calls. For low volume status changes, WATCH=STATUS will be a big win. For the high volume case, we need to have recommendations or limits on what should be done. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIcMt2056703 for ; Thu, 17 Apr 2003 11:38:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIcLLI056702 for ietf-imapext-bks; Thu, 17 Apr 2003 11:38:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIcKt2056694 for ; Thu, 17 Apr 2003 11:38:21 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA06117; Thu, 17 Apr 2003 14:32:53 -0400 (EDT) Date: Thu, 17 Apr 2003 14:36:22 -0400 From: Cyrus Daboo To: Rob Siemborski , John Milan cc: Mark Crispin , IMAP Extensions WG Subject: RE: WATCH extension for IMAP Message-ID: <2147483647.1050590182@[63.163.82.24]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Thursday, April 17, 2003 2:22 PM -0400 Rob Siemborski wrote: |> I'm thinking of a WATCH much like mail filtering. | | I suspect it would be possible to use the sieve notify extention to feed | this in some way. Indeed we could define WATCH=SIEVENOTIFY and have * WATCH responses that return the sieve data. However, this would require a WATCH command without a mailbox argument since sieve notifications are not tied to mailboxes. Using the empty string as an argument to WATCH in that case would make sense (and would mirror the syntax of server vs mailbox annotations in the next ANNOTATEMORE draft). | I think I'd rather see the IMAP side of this stay simple (but | extensible, if more features are desired later). Agreed - WATCH=XXX allows us to do that. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIaot2056588 for ; Thu, 17 Apr 2003 11:36:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIao0n056587 for ietf-imapext-bks; Thu, 17 Apr 2003 11:36:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (jzs@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIamt2056581 for ; Thu, 17 Apr 2003 11:36:48 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA04455; Thu, 17 Apr 2003 11:36:36 -0700 (PDT) Date: Thu, 17 Apr 2003 11:26:02 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Cyrus Daboo cc: Timo Sirainen , Rob Siemborski , IMAP Extensions WG In-Reply-To: <2147483647.1050588910@[63.163.82.24]> 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, 17 Apr 2003 14:15:10 -0400, Cyrus Daboo wrote: > STATUS is often used to show a count of the total number of messages and > number of unseen messages in a 'closed' mailbox. I understand why people want/like that. But why do STATUS of 1800 mailboxes when only 20 are currently visible on the screen? > Just indicating which have > new mail is not enough - after all that is what \Marked does in LIST and > very few implementations have bothered to use it. I never understood why this is the case. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIZSt2056542 for ; Thu, 17 Apr 2003 11:35:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIZSPD056541 for ietf-imapext-bks; Thu, 17 Apr 2003 11:35:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIZQt2056534 for ; Thu, 17 Apr 2003 11:35:27 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id D97D25E017F5; Thu, 17 Apr 2003 21:35:27 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: Rob Siemborski , Cyrus Daboo , IMAP Extensions WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050604527.16342.180.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 21:35:27 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 21:03, Mark Crispin wrote: > On Thu, 17 Apr 2003 14:01:32 -0400 (EDT), Rob Siemborski wrote: > > Of course, if the user has recieved new mail in 1800 separate mailboxes, > > in a notification period, I'd say the server is under a pretty high load > > already. > > I wasn't talking about. I was talking about client startup. > > Does the client do 1800 STATUS commands when the user first goes into the list > of mailboxes? If so, I think that client has a problem. Optimally it would send STATUS only for those mailboxes that are visible in screen. Good enough solution would be to check only the mailboxes that can become visible by scrolling (similiar to LIST "" % usage). Currently Evolution seems to do it for all subscribed folders if "check mail in all folders" flag is set. I'm not sure if it does it for all folders if I uncheck "show only subscribed folders" flag. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIVOt2056301 for ; Thu, 17 Apr 2003 11:31:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIVOGp056300 for ietf-imapext-bks; Thu, 17 Apr 2003 11:31:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIVNt2056290 for ; Thu, 17 Apr 2003 11:31:23 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp7.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3HIVArh015329; Thu, 17 Apr 2003 14:31:10 -0400 Date: Thu, 17 Apr 2003 14:31:10 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Timo Sirainen , Cyrus Daboo , IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: Message-ID: References: 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, 17 Apr 2003, Mark Crispin wrote: > One very obvious thing would be to defer doing a STATUS command until > the user is in the list of mailboxes screen. It's rather silly to do 50 > STATUS commands on a mailbox while the user's screen is busy in > composing a message. I suppose that depends on your goal. If you assume STATUS is going to take a long time, then from a user experience perspective it makes sense to do them when the network connection is otherwise idle. If, on the other hand, you are solely concerned with overall server performance, then you probably want this to be as lazy as possible. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIMSt2056083 for ; Thu, 17 Apr 2003 11:22:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIMS0h056082 for ietf-imapext-bks; Thu, 17 Apr 2003 11:22:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIMQt2056072 for ; Thu, 17 Apr 2003 11:22:27 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3HIMNfg005851; Thu, 17 Apr 2003 14:22:23 -0400 Date: Thu, 17 Apr 2003 14:22:22 -0400 (EDT) From: Rob Siemborski To: John Milan cc: Mark Crispin , IMAP Extensions WG Subject: RE: WATCH extension for IMAP In-Reply-To: Message-ID: References: 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, 17 Apr 2003, John Milan wrote: > Taking advantage of at least the RFC headers as watchable data. That way, no > matter how many folders I might have, I'll get that important message from > the boss. More aggressive implementations could probably extend the > expression matching to the message body. > > I'm thinking of a WATCH much like mail filtering. I suspect it would be possible to use the sieve notify extention to feed this in some way. I think I'd rather see the IMAP side of this stay simple (but extensible, if more features are desired later). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIFLt2055956 for ; Thu, 17 Apr 2003 11:15:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HIFLil055955 for ietf-imapext-bks; Thu, 17 Apr 2003 11:15:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HIFKt2055950 for ; Thu, 17 Apr 2003 11:15:20 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA06010; Thu, 17 Apr 2003 14:11:42 -0400 (EDT) Date: Thu, 17 Apr 2003 14:15:10 -0400 From: Cyrus Daboo To: Mark Crispin , Timo Sirainen cc: Rob Siemborski , IMAP Extensions WG Subject: Re: WATCH extension for IMAP Message-ID: <2147483647.1050588910@[63.163.82.24]> In-Reply-To: References: <1050545570.16338.112.camel@hurina> <1806305761.1050575601@[63.163.82.24]> <1050597813.16342.153.camel@hurina> X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Thursday, April 17, 2003 9:47 AM -0700 Mark Crispin wrote: | After all, what's the point of STATUS, other than to see if there is new | messages in the mailbox? In this case, we *know* that that are new | messages! STATUS is often used to show a count of the total number of messages and number of unseen messages in a 'closed' mailbox. Just indicating which have new mail is not enough - after all that is what \Marked does in LIST and very few implementations have bothered to use it. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HID9t2055905 for ; Thu, 17 Apr 2003 11:13:09 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HID9kB055904 for ietf-imapext-bks; Thu, 17 Apr 2003 11:13:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (jgr@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HID7t2055899 for ; Thu, 17 Apr 2003 11:13:08 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA04436; Thu, 17 Apr 2003 11:12:57 -0700 (PDT) Date: Thu, 17 Apr 2003 11:03:29 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Rob Siemborski cc: Timo Sirainen , Cyrus Daboo , IMAP Extensions WG 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 Thu, 17 Apr 2003 14:01:32 -0400 (EDT), Rob Siemborski wrote: > Of course, if the user has recieved new mail in 1800 separate mailboxes, > in a notification period, I'd say the server is under a pretty high load > already. I wasn't talking about. I was talking about client startup. Does the client do 1800 STATUS commands when the user first goes into the list of mailboxes? If so, I think that client has a problem. > I'm not sure if its better for the client to say on per session basis > "tell me about mailboxes x, y, z, a, b, c" or just let the client say > "tell me about my subscribed mailboxes". I think I like the former, > actually. So do we! Originally, that was what subscribed mailboxes were supposed to do, but the abuse of the subscription feature by certain other clients put an end to that idea. In effect, it is a type of subscription; it's just kept in client configuration instead of by the server. That keeps it safe from the aforementioned certain other clients, but on the other hand other clients won't inherit that information either. > But if the client author knows they are going to do a status for every > notification anyway (or every set of notifications on a mailbox), then why > cost them the additional round trip? Perhaps to discourage clients from doing that? Perhaps to encourage innovative thinking that would avoid unnecessary STATUS commands? One very obvious thing would be to defer doing a STATUS command until the user is in the list of mailboxes screen. It's rather silly to do 50 STATUS commands on a mailbox while the user's screen is busy in composing a message. This wouldn't hold for a client that always shows a list of mailboxes, but the general idea still applies. If the data isn't visible on the user's screen (the client is in a different mode, or that particular data is scrolled out of the visible view, or even if another window overlaps), then there's no need to update it until it becomes visible. > (though I > could see WATCH=BIFF as just being WATCH=STATUS with no status fields > being returned). I agree with this observation. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HI3Yt2055605 for ; Thu, 17 Apr 2003 11:03:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HI3YiK055604 for ietf-imapext-bks; Thu, 17 Apr 2003 11:03:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (hik@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HI3St2055596 for ; Thu, 17 Apr 2003 11:03:33 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA04427; Thu, 17 Apr 2003 11:03:23 -0700 (PDT) Date: Thu, 17 Apr 2003 10:52:57 -0700 (PDT) From: Mark Crispin Subject: RE: WATCH extension for IMAP To: John Milan cc: IMAP Extensions WG 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: The underlying protocol has the potential for such a capability. It deals in terms of "object identifiers", so anything can be an object identifier. However, in the ultra-lightweight version, there's only exact match of object identifiers. So, in the case of a new mail event, you would have to receive events for everything that matches the object, and use data in the event payload to determine whether to do anything with the event or discard it. That is, in your "WATCH new mail where from = myboss@company.com" example, you would get all new mail events, and locally filter out the ones that are not from "myboss@company.com". The ultra-lightweight version also has a further restriction; what the payload can carry is limited. Only the SMTP return-path (which may not necessarily be the from) is available from mail delivery, and mail delivered via IMAP COPY or APPEND wouldn't even have that. It is possible to envision future versions in which the event generator (mail delivery or IMAP server) would parse the RFC 2822 headers and deliver such information as From, Subject, etc. In fact, that is absolutely part of the design; we're going to need that! But it isn't going to be in version 1. -- Mark -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HI1gt2055539 for ; Thu, 17 Apr 2003 11:01:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HI1gLW055538 for ietf-imapext-bks; Thu, 17 Apr 2003 11:01:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HI1ft2055531 for ; Thu, 17 Apr 2003 11:01:41 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from GOBO.andrew.cmu.edu (GOBO.andrew.cmu.edu [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp7.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3HI1Wrh012804; Thu, 17 Apr 2003 14:01:32 -0400 Date: Thu, 17 Apr 2003 14:01:32 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Timo Sirainen , Cyrus Daboo , IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: Message-ID: References: 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, 17 Apr 2003, Mark Crispin wrote: > On 17 Apr 2003 20:05:17 +0300, Timo Sirainen wrote: > > Well, my client has a list of around 20 mailboxes which show the number > > of unread messages after the mailbox name. I like this behaviour, I can > > leave some messages unread if they require some action that I didn't > > want to do immediately. > > I understand why you like this behavior. > > On the other hand, suppose the user has 1800 mailboxes. Do you do the same > thing? What if STATUS takes a second or so of real time on that server? It's > going to take a while to do 1800 STATUS commands even if the mail store has > fast STATUS metadata. Of course, if the user has recieved new mail in 1800 separate mailboxes, in a notification period, I'd say the server is under a pretty high load already. > Do you require that the user identify 20 mailboxes of particular interest, and > only do it for those 20 mailboxes? I'm not sure if its better for the client to say on per session basis "tell me about mailboxes x, y, z, a, b, c" or just let the client say "tell me about my subscribed mailboxes". I think I like the former, actually. > > I don't think it would be considered very good behaviour to select the > > mailbox immediately and fetch the new messages. I don't necessarily want > > to read them, and I may delete them using another client. > > I agree with that. I personally would like the marker, then a command that I > could give to get the current count. That way, a STATUS isn't done unless I > do it. But if the client author knows they are going to do a status for every notification anyway (or every set of notifications on a mailbox), then why cost them the additional round trip? I do like Cyrus's idea of WATCH=BIFF and WATCH=STATUS, etc (though I could see WATCH=BIFF as just being WATCH=STATUS with no status fields being returned). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHkdt2055132 for ; Thu, 17 Apr 2003 10:46:39 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HHkdbk055131 for ietf-imapext-bks; Thu, 17 Apr 2003 10:46:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (gle@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHkZt2055122 for ; Thu, 17 Apr 2003 10:46:37 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id KAA04393; Thu, 17 Apr 2003 10:46:20 -0700 (PDT) Date: Thu, 17 Apr 2003 10:25:44 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Timo Sirainen cc: Rob Siemborski , Cyrus Daboo , IMAP Extensions WG In-Reply-To: <1050599117.16342.168.camel@hurina> 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 17 Apr 2003 20:05:17 +0300, Timo Sirainen wrote: > Well, my client has a list of around 20 mailboxes which show the number > of unread messages after the mailbox name. I like this behaviour, I can > leave some messages unread if they require some action that I didn't > want to do immediately. I understand why you like this behavior. On the other hand, suppose the user has 1800 mailboxes. Do you do the same thing? What if STATUS takes a second or so of real time on that server? It's going to take a while to do 1800 STATUS commands even if the mail store has fast STATUS metadata. Do you require that the user identify 20 mailboxes of particular interest, and only do it for those 20 mailboxes? In my lightweight notification system, the only cost of watching 1800 mailboxes instead of 20 is that the notification server will have to keep some number of bytes per watch request. > Maybe it would be enough for some people to just see some kind of marker > that there's new mail in the mailbox. I hope that this is enough for many people. > I don't think it would be considered very good behaviour to select the > mailbox immediately and fetch the new messages. I don't necessarily want > to read them, and I may delete them using another client. I agree with that. I personally would like the marker, then a command that I could give to get the current count. That way, a STATUS isn't done unless I do it. I use CDPD a lot. I don't like it when my client decides to do something under the covers automatically. I recognize that sometimes it has no choice. The behavior of "just spawn another connection" makes things worse on CDPD. When your CDPD modem gets into channel scanning, the more that such a client does that, the longer the recovery time. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHfYt2054536 for ; Thu, 17 Apr 2003 10:41:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HHfYIM054535 for ietf-imapext-bks; Thu, 17 Apr 2003 10:41:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from teamdirection.com (s173.n12.vds2000.com [66.84.12.173]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HHfWt2054523 for ; Thu, 17 Apr 2003 10:41:33 -0700 (PDT) (envelope-from johnm@teamdirection.com) Received: from grendel (12-228-90-244.client.attbi.com [12.228.90.244]) by teamdirection.com (8.12.9/8.11.2) with SMTP id h3HHfJxN008488; Thu, 17 Apr 2003 13:41:19 -0400 From: "John Milan" To: "Mark Crispin" , "IMAP Extensions WG" Subject: RE: WATCH extension for IMAP Date: Thu, 17 Apr 2003 10:49:56 -0700 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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Are the event types predefined? Such as you might have the following event types: new mail deleted mail flag changes Or can you WATCH an expression? For instance, could say (pardon the SQLness) WATCH new mail where from = myboss@company.com Taking advantage of at least the RFC headers as watchable data. That way, no matter how many folders I might have, I'll get that important message from the boss. More aggressive implementations could probably extend the expression matching to the message body. I'm thinking of a WATCH much like mail filtering. John Milan -----Original Message----- From: owner-ietf-imapext@mail.imc.org [mailto:owner-ietf-imapext@mail.imc.org]On Behalf Of Mark Crispin Sent: Wednesday, April 16, 2003 6:37 PM To: IMAP Extensions WG Subject: WATCH extension for IMAP I've been thinking about defining a WATCH extension to IMAP which would allow an IMAP client to watch for certain events happening to a non-selected mailbox. Once a WATCH is set, it remains in effect until that IMAP session is logged out, and untagged WATCH events for the watched mailbox(es) can be returned at any time. The command will be something like: tag WATCH mailbox event-list and the responses will be something like * WATCH mailbox event-pair-list where an event-pair contains an event type and event data. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HH5Jt2053335 for ; Thu, 17 Apr 2003 10:05:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HH5JQO053334 for ietf-imapext-bks; Thu, 17 Apr 2003 10:05:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HH5Gt2053328 for ; Thu, 17 Apr 2003 10:05:17 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id C0BDB5E017F5; Thu, 17 Apr 2003 20:05:17 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: Rob Siemborski , Cyrus Daboo , IMAP Extensions WG In-Reply-To: References: <1050545570.16338.112.camel@hurina> <1806305761.1050575601@[63.163.82.24]> <1050597813.16342.153.camel@hurina> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050599117.16342.168.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 20:05:17 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 19:47, Mark Crispin wrote: > On Thu, 17 Apr 2003, Timo Sirainen wrote: > > I think it's more likely that clients will be abusive with "new mail in > > mailbox xyz" notification. They'd probably just request STATUS every > > time they receive that. > > A client that does that will quickly have its notification queue filled > and notifications will get dropped. Wouldn't the same thing happen if server did it automatically? > I question why a client would want to issue a STATUS if notified about new > mail in such-and-such mailbox, as opposed to noting that that mailbox has > new mail and/or opening it. > > After all, what's the point of STATUS, other than to see if there is new > messages in the mailbox? In this case, we *know* that that are new > messages! Well, my client has a list of around 20 mailboxes which show the number of unread messages after the mailbox name. I like this behaviour, I can leave some messages unread if they require some action that I didn't want to do immediately. So, once in a while I look at the list and see if there's anything interesting in there. Not just new mail, but also those mails that I left unread. I may have marked some of them as read elsewhere, that pretty much requires STATUS (UNSEEN). Maybe it would be enough for some people to just see some kind of marker that there's new mail in the mailbox. I don't think it would be considered very good behaviour to select the mailbox immediately and fetch the new messages. I don't necessarily want to read them, and I may delete them using another client. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGlst2052734 for ; Thu, 17 Apr 2003 09:47:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HGlrfN052733 for ietf-imapext-bks; Thu, 17 Apr 2003 09:47:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGlqt2052728 for ; Thu, 17 Apr 2003 09:47:52 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3HGllSL032355; Thu, 17 Apr 2003 09:47:47 -0700 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3HGll8H000761 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 17 Apr 2003 09:47:47 -0700 Date: Thu, 17 Apr 2003 09:47:47 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: Rob Siemborski , Cyrus Daboo , IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: <1050597813.16342.153.camel@hurina> Message-ID: References: <1050545570.16338.112.camel@hurina> <1806305761.1050575601@[63.163.82.24]> <1050597813.16342.153.camel@hurina> Organization: Networks and 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 Thu, 17 Apr 2003, Timo Sirainen wrote: > I think it's more likely that clients will be abusive with "new mail in > mailbox xyz" notification. They'd probably just request STATUS every > time they receive that. A client that does that will quickly have its notification queue filled and notifications will get dropped. I question why a client would want to issue a STATUS if notified about new mail in such-and-such mailbox, as opposed to noting that that mailbox has new mail and/or opening it. After all, what's the point of STATUS, other than to see if there is new messages in the mailbox? In this case, we *know* that that are new messages! -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGhYt2052583 for ; Thu, 17 Apr 2003 09:43:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HGhYHB052582 for ietf-imapext-bks; Thu, 17 Apr 2003 09:43:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGhWt2052576 for ; Thu, 17 Apr 2003 09:43:33 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id AC4FA5E017F5; Thu, 17 Apr 2003 19:43:33 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: Rob Siemborski , Cyrus Daboo , IMAP Extensions WG In-Reply-To: References: <1050545570.16338.112.camel@hurina> <1806305761.1050575601@[63.163.82.24]> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050597813.16342.153.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 19:43:33 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 19:20, Mark Crispin wrote: > It's technically easy (trivial even) to do an automatic STATUS, and > perhaps a subscription type mechanism will suffice to avoid the problem. > However, the architecture has to be carefully designed to minimize the > likelihood of abusive client implementations. I think it's more likely that clients will be abusive with "new mail in mailbox xyz" notification. They'd probably just request STATUS every time they receive that. If server sends the STATUS replies directly, it can at least force some "max. n seconds between STATUS notifications" limit. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGe1t2052515 for ; Thu, 17 Apr 2003 09:40:01 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HGe1Mi052514 for ietf-imapext-bks; Thu, 17 Apr 2003 09:40:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HGe0t2052506 for ; Thu, 17 Apr 2003 09:40:00 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3HGdsSL030713; Thu, 17 Apr 2003 09:39:54 -0700 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3HGdr8H032373 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 17 Apr 2003 09:39:54 -0700 Date: Thu, 17 Apr 2003 09:39:53 -0700 (PDT) From: Mark Crispin To: Simon Josefsson cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: Message-ID: References: Organization: Networks and 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 Thu, 17 Apr 2003, Simon Josefsson wrote: > If the extension isn't IMAP aware, my initial reaction is that it > should be a vendor specific capability. I.e., your server can > announce a WATCH capability that enables the command you propose. Vendor-specific is not useful. To be useful, it has to be something that is generally adopted. This does NOT preclude a separate, more heavyweight notification facility. It certainly does not compete with a heavyweight facility. The question is: If there was an ultra-lightweight notification mechanism available very soon, would you use it? OR Do you say, "No, I can not make use of an ultra-lightweight notification facility. I'd rather wait until LEMONADE finishes its work, and then wait for that work to be implemented. Until then, I'd rather have nothing at all." LEMONADE is working on the specification for a heavyweight notification facility. I am not competing with that effort. The LEMONADE charter says that they will have that effort done by summer. You can decide for yourself whether you believe that will happen. I know that everybody would like to have a heavyweight notification facility, with lots of bells and whistles. This is not such a facility. I have a prototype ultra-lightweight notification system which I wrote and demonstrated a year ago. All that needs to be done is to stitch it in. It is not likely to provoke server managers into turning it off either. I'm trying to ascertain if it's worth the effort. Personally, I believe that while it isn't ideal, it's good enough. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HG8rt2051592 for ; Thu, 17 Apr 2003 09:08:53 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HG8r8P051591 for ietf-imapext-bks; Thu, 17 Apr 2003 09:08:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HG8qt2051579 for ; Thu, 17 Apr 2003 09:08:52 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from ASG1.WEB.cmu.edu (ASG1.WEB.cmu.edu [128.2.11.38]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h3HG8gfg027559; Thu, 17 Apr 2003 12:08:42 -0400 Date: Thu, 17 Apr 2003 12:08:42 -0400 (EDT) From: Rob Siemborski X-X-Sender: rjs3@asg1.web.cmu.edu To: Mark Crispin cc: Cyrus Daboo , Timo Sirainen , IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: Message-ID: References: <1050545570.16338.112.camel@hurina> <1806305761.1050575601@[63.163.82.24]> 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, 17 Apr 2003, Mark Crispin wrote: > What if there is a mail bomb, and multiple messages/second are arriving? > STATUS is not necessarily an inexpensive operation (and the specification > specifically says as much). True, but perhaps multiple notifications for a folder could be aggregated into a single STATUS reply as well? > Nor is it certain that every client would want to do a STATUS. Perhaps it > just wants to note that the mailbox has new messages, and let the user > decide to SELECT it. This is why I'd want to see clients able to subscribe to the particular information that comes back with the notifications. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HG8qt2051582 for ; Thu, 17 Apr 2003 09:08:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HG8q30051580 for ietf-imapext-bks; Thu, 17 Apr 2003 09:08:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HG8pt2051574 for ; Thu, 17 Apr 2003 09:08:51 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3HG8hTc025909; Thu, 17 Apr 2003 09:08:48 -0700 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3HG8h8H029176 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 17 Apr 2003 09:08:43 -0700 Date: Thu, 17 Apr 2003 09:08:43 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: <1050587458.16341.138.camel@hurina> Message-ID: References: <1050545570.16338.112.camel@hurina> <1050587458.16341.138.camel@hurina> Organization: Networks and 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 Thu, 17 Apr 2003, Timo Sirainen wrote: > How are you going to send the notification to IMAP server? Some signal? > Socket? Currently, it would be a TCP connection from the IMAP server to the notification system. There's a good effort being made to avoid dropping notifications (of course, if a drop has to happen, it will happen). The notification system itself does not require that a client receiving notifications be on the same system as the notification system. Generating notifications is currently also done by TCP, but it is likely to move to a datagram type mechanism. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HEXVt2046913 for ; Thu, 17 Apr 2003 07:33:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HEXV6m046912 for ietf-imapext-bks; Thu, 17 Apr 2003 07:33:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HEXTt2046907 for ; Thu, 17 Apr 2003 07:33:30 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id KAA04419; Thu, 17 Apr 2003 10:29:53 -0400 (EDT) Date: Thu, 17 Apr 2003 10:33:21 -0400 From: Cyrus Daboo To: Mark Crispin , Timo Sirainen cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP Message-ID: <1806305761.1050575601@[63.163.82.24]> In-Reply-To: References: <1050545570.16338.112.camel@hurina> X-Mailer: Mulberry/3.1.0b1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Wednesday, April 16, 2003 7:43 PM -0700 Mark Crispin wrote: |> I think most of the clients would be just interested in getting |> automatic updates for "STATUS (MESSAGES UNSEEN)", maybe UIDVALIDITY and |> UIDNEXT too. For those it'd be easier if untagged STATUS replies were |> received directly. Maybe "WATCH mailbox (STATUS ())" | | I agree with your observation; this would be nice. Unfortunately, this | functionality is outside of the scope of ultra-lightweight notification. | The notification protocol can support this; however, the current set of | event generators (the mail delivery agents) can not. | | The mail delivery agents merely append to the mailbox file; they have no | concept of "number of messages", "number of unseen messages", | "UIDVALIDITY", "UIDNEXT", or any other STATUS-type metadata. The only | thing they know is "appended a string purported to be a new mail message | to such-and-such mailbox name, with return-path of such-and such". Well, the server will know which mailbox is being watched and when the event for that is seen, why can't the server do an implicit STATUS (with client provided parameters) and return that? i.e. the server does what the client would otherwise do - issue a status for that mailbox. I think for this to be useful within IMAP it has to return STATUS information - that's what clients will want - but I don't see that as being a problem or as interfering with the way the outside notification works. I think it does also have to handle COPY/APPEND changes to the mailbox as well. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HDp1t2045344 for ; Thu, 17 Apr 2003 06:51:01 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HDp1B7045343 for ietf-imapext-bks; Thu, 17 Apr 2003 06:51:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HDowt2045328 for ; Thu, 17 Apr 2003 06:50:59 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id 166225E017F5; Thu, 17 Apr 2003 16:50:59 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: IMAP Extensions WG In-Reply-To: References: <1050545570.16338.112.camel@hurina> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050587458.16341.138.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 16:50:58 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 05:43, Mark Crispin wrote: > I agree with your observation; this would be nice. Unfortunately, this > functionality is outside of the scope of ultra-lightweight notification. > The notification protocol can support this; however, the current set of > event generators (the mail delivery agents) can not. How are you going to send the notification to IMAP server? Some signal? Socket? I've been thinking about using Linux's dnotify and BSD's kqueue() for this. They should be quite lightweight as well, and they notice all changes in mailbox file/directory. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HASVt2031980 for ; Thu, 17 Apr 2003 03:28:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HASVLK031979 for ietf-imapext-bks; Thu, 17 Apr 2003 03:28:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HASSt2031973 for ; Thu, 17 Apr 2003 03:28:29 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3HASAXK018099 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Apr 2003 12:28:11 +0200 To: Mark Crispin Cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP X-Payment: hashcash 1.2 0:030417:mrc@CAC.Washington.EDU:b40979cfe9315a21 X-Hashcash: 0:030417:mrc@CAC.Washington.EDU:b40979cfe9315a21 X-Payment: hashcash 1.2 0:030417:ietf-imapext@imc.org:888596dcd84ca2bf X-Hashcash: 0:030417:ietf-imapext@imc.org:888596dcd84ca2bf From: Simon Josefsson Date: Thu, 17 Apr 2003 12:28:10 +0200 In-Reply-To: (Mark Crispin's message of "Wed, 16 Apr 2003 18:36:56 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > The single most important event type will be new mail, with the event data > being the SMTP return-path of the message. So, in effect, this will be > "biff for IMAP". Yay! This would be very useful, at least for my client. I concur with Timo's observation, it is much more useful if the WATCH extension responded with requested information (i.e., one of the STATUS parameters, or possibly even a FETCH parameter -- imagine receiving BODY and immediately being able to display information about the new message) instead of just a maybe-there-is-new-mail-over-here type of indication. The latter kind of notification is sufficient in a non-IMAP notification protocol, like zephyr (which the client can support already), but if the feature is built into the IMAP protocol I think it should be IMAP-aware instead of simply a external notification protocol tunneled through IMAP. If the extension isn't IMAP aware, my initial reaction is that it should be a vendor specific capability. I.e., your server can announce a WATCH capability that enables the command you propose. A real IMAP-aware NOTIFICATION extension would be of separate utility, and could be defined in parallel with the WATCH capability. Then a server supporting WATCH can decide if it wants to do a STATUS internally in order to be able to support NOTIFICATION too, and clients can decide which kind of notification they are most helped by and decide accordingly. Thoughts? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H4kst2091131 for ; Wed, 16 Apr 2003 21:46:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H4ksTX091129 for ietf-imapext-bks; Wed, 16 Apr 2003 21:46:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (chince@panda.com [206.124.149.114]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H4kqt2091123 for ; Wed, 16 Apr 2003 21:46:53 -0700 (PDT) (envelope-from MRC@Panda.COM) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id VAA03284; Wed, 16 Apr 2003 21:46:51 -0700 (PDT) Date: Wed, 16 Apr 2003 21:23:59 -0700 (PDT) From: Mark Crispin Subject: Re: WATCH extension for IMAP To: Philip Guenther cc: IMAP Extensions WG In-Reply-To: <200304170424.h3H4OKe15727@katroo.Sendmail.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: On Wed, 16 Apr 2003 21:23:04 -0700, Philip Guenther wrote: > Does the IMAP server generate "new mail" notifications when it performs > APPEND and COPY operations? This could be done within the "ultra-lightweight" framework, although perhaps it should be a different type of event than new mail. Is this something that people would like to have/find useful? In the case of multiple-message COPY and multiple APPEND, it would most likely generate a single event and not an event per-message. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H4Mxt2090819 for ; Wed, 16 Apr 2003 21:22:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H4Mxkv090818 for ietf-imapext-bks; Wed, 16 Apr 2003 21:22:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H4Mst2090807 for ; Wed, 16 Apr 2003 21:22:58 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h3H4MfFd022522; Wed, 16 Apr 2003 21:22:41 -0700 (PDT) Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.7/8.11.6) with ESMTP id h3H4OKe15727; Wed, 16 Apr 2003 21:24:20 -0700 (PDT) Message-Id: <200304170424.h3H4OKe15727@katroo.Sendmail.COM> To: Mark Crispin Cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-reply-to: References: Date: Wed, 16 Apr 2003 21:23:04 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: ... >I am interested in feedback as to whether this proposed extension is >interesting or not. Also, would it be better to build an extension which >has extensibility but with restraints ("ultra-lightweight") on how it can >be extended, or if it should be strictly a new mail watching facility and >leave the possibility of other types of notifications to a different >facilty (such as what is being discussed in LEMONADE). Does the IMAP server generate "new mail" notifications when it performs APPEND and COPY operations? Philip Guenther Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H2hBt2085826 for ; Wed, 16 Apr 2003 19:43:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H2hB51085825 for ietf-imapext-bks; Wed, 16 Apr 2003 19:43:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H2hAt2085818 for ; Wed, 16 Apr 2003 19:43:10 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3H2h4t7020640; Wed, 16 Apr 2003 19:43:09 -0700 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3H2h38H005777 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 16 Apr 2003 19:43:03 -0700 Date: Wed, 16 Apr 2003 19:43:03 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: IMAP Extensions WG Subject: Re: WATCH extension for IMAP In-Reply-To: <1050545570.16338.112.camel@hurina> Message-ID: References: <1050545570.16338.112.camel@hurina> Organization: Networks and 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 Wed, 17 Apr 2003, Timo Sirainen wrote: > I think most of the clients would be just interested in getting > automatic updates for "STATUS (MESSAGES UNSEEN)", maybe UIDVALIDITY and > UIDNEXT too. For those it'd be easier if untagged STATUS replies were > received directly. Maybe "WATCH mailbox (STATUS ())" I agree with your observation; this would be nice. Unfortunately, this functionality is outside of the scope of ultra-lightweight notification. The notification protocol can support this; however, the current set of event generators (the mail delivery agents) can not. The mail delivery agents merely append to the mailbox file; they have no concept of "number of messages", "number of unseen messages", "UIDVALIDITY", "UIDNEXT", or any other STATUS-type metadata. The only thing they know is "appended a string purported to be a new mail message to such-and-such mailbox name, with return-path of such-and such". So, to rephase my original question. Would it be useful to receive, from the IMAP server, a notification that a mail delivery agent appended what purports to be new mail to such-and-such mailbox name with return-path of such-and-such? You could, in reaction to this notification, then do a STATUS. What this buys you is that you could react much faster if a mailbox gets new mail. Also, you won't have to issue STATUS (at least not as often) to poll for new messages. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H2Cut2085196 for ; Wed, 16 Apr 2003 19:12:56 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H2Cuvl085195 for ietf-imapext-bks; Wed, 16 Apr 2003 19:12:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H2Crt2085188 for ; Wed, 16 Apr 2003 19:12:54 -0700 (PDT) (envelope-from tss@iki.fi) Received: by oma.irssi.org (Postfix, from userid 1000) id D6F415E017F5; Thu, 17 Apr 2003 05:12:50 +0300 (EEST) Subject: Re: WATCH extension for IMAP From: Timo Sirainen To: Mark Crispin Cc: IMAP Extensions WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050545570.16338.112.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 Apr 2003 05:12:50 +0300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2003-04-17 at 04:36, Mark Crispin wrote: > I've been thinking about defining a WATCH extension to IMAP which would > allow an IMAP client to watch for certain events happening to a > non-selected mailbox. Once a WATCH is set, it remains in effect until > that IMAP session is logged out, and untagged WATCH events for the watched > mailbox(es) can be returned at any time. > > The command will be something like: > tag WATCH mailbox event-list > and the responses will be something like > * WATCH mailbox event-pair-list > where an event-pair contains an event type and event data. I think most of the clients would be just interested in getting automatic updates for "STATUS (MESSAGES UNSEEN)", maybe UIDVALIDITY and UIDNEXT too. For those it'd be easier if untagged STATUS replies were received directly. Maybe "WATCH mailbox (STATUS ())" Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H1b1t2084366 for ; Wed, 16 Apr 2003 18:37:01 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H1b1n6084365 for ietf-imapext-bks; Wed, 16 Apr 2003 18:37:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H1axt2084359 for ; Wed, 16 Apr 2003 18:37:00 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3H1aug9006788 for ; Wed, 16 Apr 2003 18:37:02 -0700 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3H1au8H003884 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 16 Apr 2003 18:36:56 -0700 Date: Wed, 16 Apr 2003 18:36:56 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG Subject: WATCH extension for IMAP Message-ID: Organization: Networks and 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: I've been thinking about defining a WATCH extension to IMAP which would allow an IMAP client to watch for certain events happening to a non-selected mailbox. Once a WATCH is set, it remains in effect until that IMAP session is logged out, and untagged WATCH events for the watched mailbox(es) can be returned at any time. The command will be something like: tag WATCH mailbox event-list and the responses will be something like * WATCH mailbox event-pair-list where an event-pair contains an event type and event data. The single most important event type will be new mail, with the event data being the SMTP return-path of the message. So, in effect, this will be "biff for IMAP". We have talked about other event types, such as "message flags changed" or "mailbox expunged", but it isn't clear how well this will scale (it's one thing to generate an event when delivering a new mail message, it's quite another to do so every time some flag gets altered!). This is in effect an IMAP interface to an ultra-lightweight notification protocol and facility that I am working on. The IMAP server won't do any actual "watching"; instead, it will just be a client to the notification facility. I need to emphasize the "ultra-lightweight" nature of this facility. Although the underlying notification protocol is completely extensible, a foremost consideration has been lightweight and low-cost (hence the tenative nature of the flags/expunge event types). That is also why the SMTP return-path is in the new-mail notification, because many mail delivery agents only know that. Last but not least, this is something that can be made available Real Soon. Much of the code already exists. I know that LEMONADE has a fairly aggressive schedule for its notification facility, but I suspect that schedule will slip. I am interested in feedback as to whether this proposed extension is interesting or not. Also, would it be better to build an extension which has extensibility but with restraints ("ultra-lightweight") on how it can be extended, or if it should be strictly a new mail watching facility and leave the possibility of other types of notifications to a different facilty (such as what is being discussed in LEMONADE). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3DNdAes008581 for ; Sun, 13 Apr 2003 16:39:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3DNdATx008580 for ietf-imapext-bks; Sun, 13 Apr 2003 16:39:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3DNd9es008571 for ; Sun, 13 Apr 2003 16:39:09 -0700 (PDT) (envelope-from phoffman@imc.org) Received: from localhost (phoffman@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) with ESMTP id h3DNd9n7008568 for ; Sun, 13 Apr 2003 16:39:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: phoffman owned process doing -bs Date: Sun, 13 Apr 2003 16:39:09 -0700 (PDT) From: Paul Hoffman X-X-Sender: phoffman@above.proper.com To: ietf-imapext@imc.org Subject: ADMINISTRIVIA: fighting with the new mail server Message-ID: <20030413163842.U8537@above.proper.com> 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 just changed the OS for the mail server, and am not convinced that I got all the bugs worked out. So I'm inflicting this on you. :-) Hopefully, you'll only see this once. --Paul Hoffman Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3DNZLes008459 for ; Sun, 13 Apr 2003 16:35:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3DNZLcZ008458 for ietf-imapext-bks; Sun, 13 Apr 2003 16:35:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3DNZKes008453 for ; Sun, 13 Apr 2003 16:35:20 -0700 (PDT) (envelope-from phoffman@imc.org) Received: from localhost (phoffman@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) with ESMTP id h3DNZK1t008450 for ; Sun, 13 Apr 2003 16:35:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: phoffman owned process doing -bs Date: Sun, 13 Apr 2003 16:35:20 -0700 (PDT) From: Paul Hoffman X-X-Sender: phoffman@above.proper.com To: ietf-imapext@imc.org Subject: ADMINISTRIVIA: testing the mail server Message-ID: <20030413163458.Q8122@above.proper.com> 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 just changed the OS for the mail server, and am not convinced that I got all the bugs worked out. So I'm inflicting this on you. :-) Hopefully, you'll only see this once. --Paul Hoffman Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3DNXSes008294 for ; Sun, 13 Apr 2003 16:33:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3DNXSff008293 for ietf-imapext-bks; Sun, 13 Apr 2003 16:33:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3DNXRes008288 for ; Sun, 13 Apr 2003 16:33:27 -0700 (PDT) (envelope-from phoffman@imc.org) Received: from localhost (phoffman@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) with ESMTP id h3DNXR62008285 for ; Sun, 13 Apr 2003 16:33:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: phoffman owned process doing -bs Date: Sun, 13 Apr 2003 16:33:27 -0700 (PDT) From: Paul Hoffman X-X-Sender: phoffman@above.proper.com To: ietf-imapext@imc.org Subject: ADMINISTRIVIA: testing out the new mail server setup Message-ID: <20030413163301.L8122@above.proper.com> 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 just changed the OS for the mail server, and am not convinced that I got all the bugs worked out. So I'm inflicting this on you. :-) Hopefully, you'll only see this once. --Paul Hoffman Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CHGIJM016818 for ; Sat, 12 Apr 2003 10:16:18 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3CHGInw016816 for ietf-imapext-bks; Sat, 12 Apr 2003 10:16:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CHGEJM016772 for ; Sat, 12 Apr 2003 10:16:14 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3CHG7RG013691; Sat, 12 Apr 2003 10:16:07 -0700 Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by smtp.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3CHG78H010538 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 12 Apr 2003 10:16:07 -0700 Date: Sat, 12 Apr 2003 10:16:07 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo cc: Alexey Melnikov , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt In-Reply-To: <2147483647.1050147388@[10.0.1.3]> Message-ID: References: <2147483647.1050084387@[10.0.1.6]> <3E9793F0.A48EF7E2@messagingdirect.com> <2147483647.1050147388@[10.0.1.3]> Organization: Networks and 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 Sat, 12 Apr 2003, Cyrus Daboo wrote: > | Why would one want to use MODSEQ with THREAD? > For the same reason one would use it in the search criteria on sort: to > have the command return results only for those messages that changed since > the MODSEQ. I doubt this is really a useful behaviour but it has to be > present for consistency if you are adding MODSEQ to search unless its > explicitly stated MODSEQ can't be used in sort/thread search criteria. I'm hard-pressed to think of a use for MODSEQ with THREAD; and while SORT presents some possible use I doubt that there would be much of that in real life. If you declare that MODSEQ is an additional argument to SEARCH (much as CHARSET is) instead of a SEARCH criterion, then you avoid the issue. But that's no good if you decide to have MODSEQ in SORT. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CFkfJM012900 for ; Sat, 12 Apr 2003 08:46:41 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3CFkfbv012899 for ietf-imapext-bks; Sat, 12 Apr 2003 08:46:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CFkdJM012895 for ; Sat, 12 Apr 2003 08:46:40 -0700 (PDT) Received: from [10.0.1.3] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA24019; Sat, 12 Apr 2003 11:43:12 -0400 (EDT) Date: Sat, 12 Apr 2003 11:46:39 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt Message-ID: <2147483647.1050147999@[10.0.1.3]> In-Reply-To: <3E9796E8.6B6F4187@messagingdirect.com> References: <2147483647.1050082018@[10.0.1.6]> <3E9796E8.6B6F4187@messagingdirect.com> X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Friday, April 11, 2003 10:32 PM -0600 Alexey Melnikov wrote: |> You need to change the annotation entry names to exclude the "/message" |> prefix. We agreed to eliminate the /message and /body entry name prefixes |> at the last meeting. I'm hoping to get an updated annotation document out |> in the next week with that and other changes. | | Is the \Seen flag now "/flags/\\seen" or "flags/\\seen"? "/flags/\\seen" - i.e. / prefix is still present. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CFaVJM012350 for ; Sat, 12 Apr 2003 08:36:31 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3CFaVAi012349 for ietf-imapext-bks; Sat, 12 Apr 2003 08:36:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3CFaUJM012342 for ; Sat, 12 Apr 2003 08:36:30 -0700 (PDT) Received: from [10.0.1.3] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA23981; Sat, 12 Apr 2003 11:33:02 -0400 (EDT) Date: Sat, 12 Apr 2003 11:36:28 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt Message-ID: <2147483647.1050147388@[10.0.1.3]> In-Reply-To: <3E9793F0.A48EF7E2@messagingdirect.com> References: <2147483647.1050084387@[10.0.1.6]> <3E9793F0.A48EF7E2@messagingdirect.com> X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Friday, April 11, 2003 10:20 PM -0600 Alexey Melnikov wrote: |> Interaction with SORT and THREAD - note that both SORT and THREAD take |> search criteria as arguments. Right now the draft only discusses SORT but |> it needs to include THREAD as well (an example for a thread response with |> MODSEQ would be good too). | | Why would one want to use MODSEQ with THREAD? For the same reason one would use it in the search criteria on sort: to have the command return results only for those messages that changed since the MODSEQ. I doubt this is really a useful behaviour but it has to be present for consistency if you are adding MODSEQ to search unless its explicitly stated MODSEQ can't be used in sort/thread search criteria. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C5W7JM011312 for ; Fri, 11 Apr 2003 22:32:07 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3C5W7tx011311 for ietf-imapext-bks; Fri, 11 Apr 2003 22:32:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C5W4JM011304 for ; Fri, 11 Apr 2003 22:32:06 -0700 (PDT) Received: from messagingdirect.com (1Cust203.tnt3.edmonton.ab.da.uu.net [64.10.184.203]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3C5Z7V15312; Fri, 11 Apr 2003 23:35:08 -0600 Message-ID: <3E97A4B1.5FD5F41B@messagingdirect.com> Date: Fri, 11 Apr 2003 23:31:29 -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: Cyrus Daboo CC: Mark Crispin , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <2147483647.1050081221@[10.0.1.6]> <3E97374C.7048A812@messagingdirect.com> <2147483647.1050083541@[10.0.1.6]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > |> I have no problems with the last suggested change (i.e. HIGHESTMODSEQ > |> with 0). > |> Alternatively, we can say that if no HIGHESTMODSEQ is returned on SELECT, > |> then CONDSTORE is not supported for the mailbox? This is probably better. > | > | Either way works for me. I think though that an affirmative statement is > | better than the absence of one; so HIGHESTMODSEQ 0 or NOMODSEQ seems > | better than a missing HIGHESTMODSEQ on SELECT. > > Agreed, and I would favour NOMODSEQ for clarity as well. Ok, I've added NOMODSEQ to the document. Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C4oJJM010248 for ; Fri, 11 Apr 2003 21:50:19 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3C4oJv7010247 for ietf-imapext-bks; Fri, 11 Apr 2003 21:50:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C4oFJM010243 for ; Fri, 11 Apr 2003 21:50:18 -0700 (PDT) Received: from messagingdirect.com (1Cust203.tnt3.edmonton.ab.da.uu.net [64.10.184.203]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3C4rMV15153; Fri, 11 Apr 2003 22:53:22 -0600 Message-ID: <3E979AEB.308DAE93@messagingdirect.com> Date: Fri, 11 Apr 2003 22:49:47 -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 , Chris Newman , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <3E9738BB.DBAD97E3@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Mark Crispin wrote: > > > . STORE should NEVER reply NO; instead, the untagged FETCH response > > should be relied upon to indicate what happened > > > > I disapprove of the idea of NO with the MODIFIED status code. This > > introduces, for the first time, an instance where the server replied NO > > but something happened anyway. Actually, nothing happened. This is not much different from [removed] "NEWNAME" response code. But I don't really care whether MODIFIED is returned with OK or NO. Does anybody else have any preferences? > The command succeeded and did what was > > requested; therefore OK should be returned (with the MODIFIED status > > code). > > This is fine with me. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C4X9JM009974 for ; Fri, 11 Apr 2003 21:33:09 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3C4X9n5009973 for ietf-imapext-bks; Fri, 11 Apr 2003 21:33:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C4X8JM009969 for ; Fri, 11 Apr 2003 21:33:08 -0700 (PDT) Received: from messagingdirect.com (1Cust203.tnt3.edmonton.ab.da.uu.net [64.10.184.203]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3C4aNV15103; Fri, 11 Apr 2003 22:36:23 -0600 Message-ID: <3E9796E8.6B6F4187@messagingdirect.com> Date: Fri, 11 Apr 2003 22:32:40 -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: Cyrus Daboo CC: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <2147483647.1050082018@[10.0.1.6]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > You need to change the annotation entry names to exclude the "/message" > prefix. We agreed to eliminate the /message and /body entry name prefixes > at the last meeting. I'm hoping to get an updated annotation document out > in the next week with that and other changes. Is the \Seen flag now "/flags/\\seen" or "flags/\\seen"? Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C4H3JM009747 for ; Fri, 11 Apr 2003 21:17:03 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3C4H2kp009746 for ietf-imapext-bks; Fri, 11 Apr 2003 21:17:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3C4GxJM009742 for ; Fri, 11 Apr 2003 21:17:01 -0700 (PDT) Received: from messagingdirect.com (1Cust203.tnt3.edmonton.ab.da.uu.net [64.10.184.203]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3C4KGV15056; Fri, 11 Apr 2003 22:20:17 -0600 Message-ID: <3E9793F0.A48EF7E2@messagingdirect.com> Date: Fri, 11 Apr 2003 22: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: Cyrus Daboo CC: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <2147483647.1050084387@[10.0.1.6]> 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: Cyrus Daboo wrote: > Interaction with SORT and THREAD - note that both SORT and THREAD take > search criteria as arguments. Right now the draft only discusses SORT but > it needs to include THREAD as well (an example for a thread response with > MODSEQ would be good too). Why would one want to use MODSEQ with THREAD? > Also the formal syntax for the search and sort responses is slightly wrong > (missing SP) Thank you. > and should have thread added: > > mailbox-data =/ > "SEARCH" [1*(SP nz-number) SP search_sort_mod_seq] / > "SORT" [1*(SP nz-number) SP search_sort_mod_seq] / > "THREAD" [SP 1*thread-list SP search_sort_mod_seq] Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BM6TJM021650 for ; Fri, 11 Apr 2003 15:06:29 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BM6TL8021649 for ietf-imapext-bks; Fri, 11 Apr 2003 15:06:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BM6RJM021641 for ; Fri, 11 Apr 2003 15:06:28 -0700 (PDT) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id SAA19206 for ; Fri, 11 Apr 2003 18:03:03 -0400 (EDT) Date: Fri, 11 Apr 2003 18:06:27 -0400 From: Cyrus Daboo To: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt Message-ID: <2147483647.1050084387@[10.0.1.6]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Interaction with SORT and THREAD - note that both SORT and THREAD take search criteria as arguments. Right now the draft only discusses SORT but it needs to include THREAD as well (an example for a thread response with MODSEQ would be good too). Also the formal syntax for the search and sort responses is slightly wrong (missing SP) and should have thread added: mailbox-data =/ "SEARCH" [1*(SP nz-number) SP search_sort_mod_seq] / "SORT" [1*(SP nz-number) SP search_sort_mod_seq] / "THREAD" [SP 1*thread-list SP search_sort_mod_seq] -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLqRJM020242 for ; Fri, 11 Apr 2003 14:52:27 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLqRjZ020241 for ietf-imapext-bks; Fri, 11 Apr 2003 14:52:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLqPJM020236 for ; Fri, 11 Apr 2003 14:52:26 -0700 (PDT) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA19139; Fri, 11 Apr 2003 17:48:56 -0400 (EDT) Date: Fri, 11 Apr 2003 17:52:21 -0400 From: Cyrus Daboo To: Mark Crispin , Alexey Melnikov cc: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt Message-ID: <2147483647.1050083541@[10.0.1.6]> In-Reply-To: References: <2147483647.1050081221@[10.0.1.6]> <3E97374C.7048A812@messagingdirect.com> X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Friday, April 11, 2003 2:45 PM -0700 Mark Crispin wrote: |> I have no problems with the last suggested change (i.e. HIGHESTMODSEQ |> with 0). |> Alternatively, we can say that if no HIGHESTMODSEQ is returned on SELECT, |> then CONDSTORE is not supported for the mailbox? This is probably better. | | Either way works for me. I think though that an affirmative statement is | better than the absence of one; so HIGHESTMODSEQ 0 or NOMODSEQ seems | better than a missing HIGHESTMODSEQ on SELECT. Agreed, and I would favour NOMODSEQ for clarity as well. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLlNJM020110 for ; Fri, 11 Apr 2003 14:47:23 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLlNaw020109 for ietf-imapext-bks; Fri, 11 Apr 2003 14:47:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLlMJM020105 for ; Fri, 11 Apr 2003 14:47:22 -0700 (PDT) Received: from messagingdirect.com (dhcp198-169.esys.ca [198.161.92.169]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3BLopV13187; Fri, 11 Apr 2003 15:50:51 -0600 Message-ID: <3E9738BB.DBAD97E3@messagingdirect.com> Date: Fri, 11 Apr 2003 15:50:51 -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: Chris Newman , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt 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: > Comments: > > A document in Last Call should not have open issues. Resolve them one way > or another. I recommend that: > . it NOT be required that conditional STORE be atomic across the message > set Actually I was in favor of this (i.e. not atomic across the message set) for a long time. It might be just to complex for some servers to add transaction support. Chris? > . STORE should NEVER reply NO; instead, the untagged FETCH response > should be relied upon to indicate what happened > > I disapprove of the idea of NO with the MODIFIED status code. This > introduces, for the first time, an instance where the server replied NO > but something happened anyway. The command succeeded and did what was > requested; therefore OK should be returned (with the MODIFIED status > code). This is fine with me. > Otherwise, the document seems technically fine to me. I think that we > should be kind to the RFC Editor and edit it into a shape that's somewhat > closer to publication status. Yep. Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLjBJM019989 for ; Fri, 11 Apr 2003 14:45:11 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLjAMC019988 for ietf-imapext-bks; Fri, 11 Apr 2003 14:45:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLj7JM019984 for ; Fri, 11 Apr 2003 14:45:07 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3BLj6RG021446; Fri, 11 Apr 2003 14:45:07 -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+UW03.04/8.12.1+UW02.12) with ESMTP id h3BLj68H013436 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Apr 2003 14:45:06 -0700 Date: Fri, 11 Apr 2003 14:45:06 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov cc: Cyrus Daboo , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt In-Reply-To: <3E97374C.7048A812@messagingdirect.com> Message-ID: References: <2147483647.1050081221@[10.0.1.6]> <3E97374C.7048A812@messagingdirect.com> 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, 11 Apr 2003, Alexey Melnikov wrote: > I have no problems with the last suggested change (i.e. HIGHESTMODSEQ with > 0). > Alternatively, we can say that if no HIGHESTMODSEQ is returned on SELECT, > then CONDSTORE is not supported for the mailbox? This is probably better. Either way works for me. I think though that an affirmative statement is better than the absence of one; so HIGHESTMODSEQ 0 or NOMODSEQ seems better than a missing HIGHESTMODSEQ on SELECT. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLfSJM019859 for ; Fri, 11 Apr 2003 14:41:29 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLfSrP019858 for ietf-imapext-bks; Fri, 11 Apr 2003 14:41:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLfRJM019853 for ; Fri, 11 Apr 2003 14:41:27 -0700 (PDT) Received: from messagingdirect.com (dhcp198-169.esys.ca [198.161.92.169]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h3BLioV13136; Fri, 11 Apr 2003 15:44:50 -0600 Message-ID: <3E97374C.7048A812@messagingdirect.com> Date: Fri, 11 Apr 2003 15:44:44 -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: Cyrus Daboo CC: Mark Crispin , ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt References: <2147483647.1050081221@[10.0.1.6]> 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: Cyrus Daboo wrote: > Hi Mark, > > --On Friday, April 11, 2003 1:58 PM -0700 Mark Crispin > wrote: > > | I know that this is rather late, but is there a recommended way for a > | server which has CONDSTORE to operate with a mail store that does not > | support it (e.g. always return 0)? > | > | I could offer CONDSTORE much faster in my server if I don't have to > | support in in all possible mailbox formats. > > I guess that could be done by either allowing 0 or having an untagged > response as part of SELECT to indicate CONDSTORE is not supported on the > mailbox being selected, even though the capability is present. The later > would be better because clients could then not use the extended commands > for that mailbox. Perhaps the HIGHESTMODSEQ response with value '0' could > be used as an indication of this? I have no problems with the last suggested change (i.e. HIGHESTMODSEQ with 0). Alternatively, we can say that if no HIGHESTMODSEQ is returned on SELECT, then CONDSTORE is not supported for the mailbox? This is probably better. Anybody else? Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLegJM019835 for ; Fri, 11 Apr 2003 14:40:42 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLegmC019834 for ietf-imapext-bks; Fri, 11 Apr 2003 14:40:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLefJM019830 for ; Fri, 11 Apr 2003 14:40:41 -0700 (PDT) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA19045 for ; Fri, 11 Apr 2003 17:37:17 -0400 (EDT) Date: Fri, 11 Apr 2003 17:40:41 -0400 From: Cyrus Daboo To: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt Message-ID: <2147483647.1050082841@[10.0.1.6]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The formal syntax for 'entry-name' should be simply defined as: entry-name = string to fall in line with ANNOTATE. There should be a comment/reference to the annotate spec at that point. That will also allow you to remove the comment about escape rules at that point. Also, could be use "priv" instead of "private" for entry-type-resp just to fall in line with the suffixes that ANNOTATE uses? -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLR0JM019302 for ; Fri, 11 Apr 2003 14:27:01 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLR0sf019301 for ietf-imapext-bks; Fri, 11 Apr 2003 14:27:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLQxJM019296 for ; Fri, 11 Apr 2003 14:26:59 -0700 (PDT) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA18969 for ; Fri, 11 Apr 2003 17:23:34 -0400 (EDT) Date: Fri, 11 Apr 2003 17:26:58 -0400 From: Cyrus Daboo To: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt Message-ID: <2147483647.1050082018@[10.0.1.6]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: You need to change the annotation entry names to exclude the "/message" prefix. We agreed to eliminate the /message and /body entry name prefixes at the last meeting. I'm hoping to get an updated annotation document out in the next week with that and other changes. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLEXJM018905 for ; Fri, 11 Apr 2003 14:14:33 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BLEXgo018904 for ietf-imapext-bks; Fri, 11 Apr 2003 14:14:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BLEVJM018900 for ; Fri, 11 Apr 2003 14:14:31 -0700 (PDT) Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA18862; Fri, 11 Apr 2003 17:10:18 -0400 (EDT) Date: Fri, 11 Apr 2003 17:13:41 -0400 From: Cyrus Daboo To: Mark Crispin , Pete Resnick cc: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt Message-ID: <2147483647.1050081221@[10.0.1.6]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Friday, April 11, 2003 1:58 PM -0700 Mark Crispin wrote: | I know that this is rather late, but is there a recommended way for a | server which has CONDSTORE to operate with a mail store that does not | support it (e.g. always return 0)? | | I could offer CONDSTORE much faster in my server if I don't have to | support in in all possible mailbox formats. I guess that could be done by either allowing 0 or having an untagged response as part of SELECT to indicate CONDSTORE is not supported on the mailbox being selected, even though the capability is present. The later would be better because clients could then not use the extended commands for that mailbox. Perhaps the HIGHESTMODSEQ response with value '0' could be used as an indication of this? -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKwmJM018067 for ; Fri, 11 Apr 2003 13:58:48 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BKwmnm018066 for ietf-imapext-bks; Fri, 11 Apr 2003 13:58:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKwlJM018062 for ; Fri, 11 Apr 2003 13:58:47 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3BKwiSL023706; Fri, 11 Apr 2003 13:58:49 -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+UW03.04/8.12.1+UW02.12) with ESMTP id h3BKwh8H009689 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Apr 2003 13:58:44 -0700 Date: Fri, 11 Apr 2003 13:58:43 -0700 (Pacific Daylight Time) From: Mark Crispin To: Pete Resnick cc: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt In-Reply-To: Message-ID: References: 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: One last thing... I know that this is rather late, but is there a recommended way for a server which has CONDSTORE to operate with a mail store that does not support it (e.g. always return 0)? I could offer CONDSTORE much faster in my server if I don't have to support in in all possible mailbox formats. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKliJM017487 for ; Fri, 11 Apr 2003 13:47:44 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BKlhlN017486 for ietf-imapext-bks; Fri, 11 Apr 2003 13:47:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BKlgJM017482 for ; Fri, 11 Apr 2003 13:47:42 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h3BKldt7028983; Fri, 11 Apr 2003 13:47:44 -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+UW03.04/8.12.1+UW02.12) with ESMTP id h3BKld8H008742 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Apr 2003 13:47:39 -0700 Date: Fri, 11 Apr 2003 13:47:38 -0700 (Pacific Daylight Time) From: Mark Crispin To: Pete Resnick cc: ietf-imapext@imc.org Subject: Re: WG last call on draft-ietf-imapext-condstore-00.txt In-Reply-To: Message-ID: References: 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: Comments: A document in Last Call should not have open issues. Resolve them one way or another. I recommend that: . it NOT be required that conditional STORE be atomic across the message set . STORE should NEVER reply NO; instead, the untagged FETCH response should be relied upon to indicate what happened I disapprove of the idea of NO with the MODIFIED status code. This introduces, for the first time, an instance where the server replied NO but something happened anyway. The command succeeded and did what was requested; therefore OK should be returned (with the MODIFIED status code). Otherwise, the document seems technically fine to me. I think that we should be kind to the RFC Editor and edit it into a shape that's somewhat closer to publication status. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BHYZJM006262 for ; Fri, 11 Apr 2003 10:34:35 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BHYZgd006261 for ietf-imapext-bks; Fri, 11 Apr 2003 10:34:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BHYXJM006257 for ; Fri, 11 Apr 2003 10:34:34 -0700 (PDT) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2b6) for ; Fri, 11 Apr 2003 12:34:34 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.0a8] Date: Fri, 11 Apr 2003 12:34:24 -0500 To: ietf-imapext@imc.org From: Pete Resnick Subject: WG last call on draft-ietf-imapext-condstore-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey has submitted the latest version of conditional store as a WG draft. We've all had plenty of time with it, so this is a WG last call on it. Please see: http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-00.txt Please post affirmative comments as well as any problems you might have. I'd like to submit this for IETF last call ASAP. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37GUeJM015196 for ; Mon, 7 Apr 2003 09:30:40 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37GUe39015195 for ietf-imapext-bks; Mon, 7 Apr 2003 09:30:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37GUcJM015191 for ; Mon, 7 Apr 2003 09:30:38 -0700 (PDT) Received: from messagingdirect.com (dhcp198-169.esys.ca [198.161.92.169]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h37GY3V06248; Mon, 7 Apr 2003 10:34:03 -0600 Message-ID: <3E910145.26596199@messagingdirect.com> Date: Sun, 06 Apr 2003 22:40:37 -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: Cyrus Daboo CC: Mark Crispin , IMAP Extensions WG , IMAP Discusson List Subject: Re: 'Label' flags 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: > On Sun, 06 Apr 2003 23:02:24 -0400, Cyrus Daboo wrote: > > I've seen 'in the wild' keywords such as $Label1, $Label2 etc Since I'm in > > the process of adding keyword support and want to have a fixed set of > > 'labels' that a user can define > ^^^^ client > > I think that my correction is important. > > If you want "labels" that a user can defined, that's keywords. > > What you are asking about is a set of fixed names which has a different > meaning on a per-client basis. I agree. Regarding the original question: I think we should standardize used client labels, but $Label1/$Label2/... should not be standardized, because they have no associated meaning. I've only seen $Label1/... being implemented in Mozilla. Mozilla allows a user to set on a message one of 5 mutually exclusive labels and a user can modify the meaning of these labels (i.e. their text description is editable). This is wrong, as there is no way to share what $Label1 means for different clients, and it is possible to have unpredictable results as two Mozillas can be configured differently. Cheers, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h373ZbJM003718 for ; Sun, 6 Apr 2003 20:35:37 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h373ZbGC003717 for ietf-imapext-bks; Sun, 6 Apr 2003 20:35:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (mhmcg@panda.com [206.124.149.114]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h373ZZJM003713 for ; Sun, 6 Apr 2003 20:35:36 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id UAA13646; Sun, 6 Apr 2003 20:35:33 -0700 (PDT) Date: Sun, 6 Apr 2003 20:31:27 -0700 (PDT) From: Mark Crispin Subject: re: 'Label' flags To: Cyrus Daboo cc: IMAP Extensions WG , IMAP Discusson List In-Reply-To: <2147483647.1049670144@[10.0.1.6]> 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, 06 Apr 2003 23:02:24 -0400, Cyrus Daboo wrote: > I've seen 'in the wild' keywords such as $Label1, $Label2 etc Since I'm in > the process of adding keyword support and want to have a fixed set of > 'labels' that a user can define ^^^^ client I think that my correction is important. If you want "labels" that a user can defined, that's keywords. What you are asking about is a set of fixed names which has a different meaning on a per-client basis. > I'm interested in knowing whether this is > something that should be 'standardised' behaviour to promote interop > between clients. I certainly hope not. But I'm not going to oppose it either. I am somewhat perplexed as to how this would be useful; but I don't see particular harm either. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3732PJM002807 for ; Sun, 6 Apr 2003 20:02:25 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3732Phl002806 for ietf-imapext-bks; Sun, 6 Apr 2003 20:02:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3732NJM002798 for ; Sun, 6 Apr 2003 20:02:24 -0700 (PDT) Received: from [10.0.1.6] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id WAA05980; Sun, 6 Apr 2003 22:59:00 -0400 (EDT) Date: Sun, 06 Apr 2003 23:02:24 -0400 From: Cyrus Daboo To: IMAP Extensions WG , IMAP Discusson List Subject: 'Label' flags Message-ID: <2147483647.1049670144@[10.0.1.6]> X-Mailer: Mulberry/3.0.3 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've seen 'in the wild' keywords such as $Label1, $Label2 etc Since I'm in the process of adding keyword support and want to have a fixed set of 'labels' that a user can define I'm interested in knowing whether this is something that should be 'standardised' behaviour to promote interop between clients. -- Cyrus Daboo