From lemonade-bounces@ietf.org Thu Jun 01 04:54:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlixC-0005hF-HM; Thu, 01 Jun 2006 04:54:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlixC-0005fi-2f for lemonade@ietf.org; Thu, 01 Jun 2006 04:54:54 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlixA-0005QG-JQ for lemonade@ietf.org; Thu, 01 Jun 2006 04:54:54 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k518snU0030701; Thu, 1 Jun 2006 11:54:50 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 11:54:22 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 11:54:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] OMA Presentation on Lemonade Date: Thu, 1 Jun 2006 11:54:10 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446572BB310@esebe199.NOE.Nokia.com> In-Reply-To: <20060531080049406.00000005884@smaes-lap3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] OMA Presentation on Lemonade Thread-Index: AcaEw33AzUasZUSdTgWJr3I7rUozBQAlVWTQ From: To: , , X-OriginalArrivalTime: 01 Jun 2006 08:54:23.0034 (UTC) FILETIME=[FA5839A0:01C68558] X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Will there be an LS for this? There is an OMA meeting in June (Osaka/Japan) where the LS could be = discussed and actions assigned. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh at nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext Stephane H. Maes [mailto:stephane.maes@oracle.com]=20 Sent: 31 May, 2006 18:01 To: Burger, Eric; Enhancements to Internet emailto support diverse = serviceenivronments Subject: RE: [lemonade] OMA Presentation on Lemonade It would be good if OMA can do. Montreal may be too early for them. We = should ask them to do (when they can) and we will see... I don't mind it during or outside WG time. We should in any way have a = short WG discussion after the session. So if the session is not the WG = session, it should be before the last WG session... Thanks Stephane=20 _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, = Oracle. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) = or stephane.maes@gmail.com (Google) -----Original Message----- From: Burger, Eric [mailto:eburger@cantata.com] Sent: Wednesday, May 31, 2006 7:34 AM To: Enhancements to Internet email to support diverse = serviceenivronments Subject: [lemonade] OMA Presentation on Lemonade Do we want to use meeting time in Montreal for a presentation from the = OMA on how they will use the lemonade RFC's to realize mobile e-mail? The chairs are leaning towards having face-to-face, non-meeting time in = Montreal. Of course, the OMA MEM may not be ready in time for Montreal = to give us a presentation, so this may be mute. Please send your thoughts to the list. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 04:56:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fliz6-0007hX-3r; Thu, 01 Jun 2006 04:56:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fliz4-0007hR-Cs for lemonade@ietf.org; Thu, 01 Jun 2006 04:56:50 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fliz2-0005Wl-TV for lemonade@ietf.org; Thu, 01 Jun 2006 04:56:50 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k518uQbw031680; Thu, 1 Jun 2006 11:56:29 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 11:56:02 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 11:56:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] COMPRESS Thoughts Date: Thu, 1 Jun 2006 11:55:48 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446572BB319@esebe199.NOE.Nokia.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702F6D036@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] COMPRESS Thoughts Thread-Index: AcaE6IcwSbuZnYNoR36SjY1FK4h+ngAcI0ZA From: To: , X-OriginalArrivalTime: 01 Jun 2006 08:56:01.0621 (UTC) FILETIME=[351B6850:01C68559] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Does (2) mean that when the client sends email it cannot compress it? Thank You.=20 Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh at nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext Burger, Eric [mailto:eburger@cantata.com]=20 Sent: 31 May, 2006 22:29 To: Enhancements to Internet email to support diverse = serviceenivronments Subject: [lemonade] COMPRESS Thoughts (1) Going back to COMPRESS in its own document (not CONVERT) (2) Consensus that compression is directional, i.e., downstream = compressed, upstream uncompressed. This is because IMAP upstream = commands may be real short (meaning compression actually adds CPU *and* = bits used), while content may be real long. (3) Basis for COMPRESS document is Arnt's imap-deflate-02 = [compress=3Ddeflate]. We will call the new document draft-ietf-lemonade-compress-04 (delete existing compress text) (4) Protocol allows for client to turn it on or off at will (not per = body part, but point in time in session) (5) review SASL mechanism for handling glare: server is busy streaming = down compressed content, and the client says, "stop compressing". Right = now looks like server will continue until finished with IMAP = transaction. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 05:44:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fljj4-0007Yw-4H; Thu, 01 Jun 2006 05:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fljj2-0007Vj-D8 for lemonade@ietf.org; Thu, 01 Jun 2006 05:44:20 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fljiy-0003qh-UN for lemonade@ietf.org; Thu, 01 Jun 2006 05:44:20 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id B2C6E4AC50; Thu, 1 Jun 2006 11:44:15 +0200 (CEST) Message-Id: Date: Thu, 1 Jun 2006 11:44:52 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] COMPRESS Thoughts Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > As I say, though, actually compressing does reduce the octet count, > and compressed blocks don't have the overhead - I'm not clear if a > new block needs to be started for a Z_SYNC_FLUSH or not, in fact. > I've never seen compression actually expand data. I have, for exactly one IMAP command. I think it was the very first "select inbox" after "compress deflate". All subsequent commands compress, and most compress well. Remember that most IMAP clients tend to send the same few commands again and again with only numbers changing. For example, one of the MUAs my wife uses sends " FETCH : (UID FLAGS INTERNALDATE FC822.SIZE BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO REPLY-TO LINES LIST-POST X-LABEL)])" every time it receives an EXISTS. After compression, that 200-byte command is a ten-byte command. After compression and TLS, it's a 16-byte one (or 17?). I bet Polymer constructs its IMAP commands cleverly and uses short tags, which gives more variety, and that's why you see only 50% compression on the upstream. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 06:30:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlkRF-0004Zj-7g; Thu, 01 Jun 2006 06:30:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlkRD-0004ZV-SW for lemonade@ietf.org; Thu, 01 Jun 2006 06:29:59 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlkRC-0008J4-DX for lemonade@ietf.org; Thu, 01 Jun 2006 06:29:59 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 550054AC50 for ; Thu, 1 Jun 2006 12:29:57 +0200 (CEST) Message-Id: Date: Thu, 1 Jun 2006 12:30:33 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] COMPRESS Thoughts References: <330A23D8336C0346B5C1A5BB1966664702F6D036@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702F6D036@ATLANTIS.Brooktrout.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Burger writes: > (4) Protocol allows for client to turn it on or off at will (not per > body part, but point in time in session) There's a performance gotcha to this, I realized while changing my daughter's nappies at 6am this morning. The compression library likes to read in big chunks. Everyone likes to do I/O in big chunks. Reading network input one byte at a time is such a performance drag. If the client tells the server that starting with the next command, its commands are uncompressed, the server's compression library has to stop reading at the right byte. It can't simply read all it can eat. Ditto for responses. This should fix it: 1. The client cannot send any other commands until the server has sent a tagged OK for the 'disable upstream compression' command. 2. The server disables compression after sending the tagged OK for that command (including the CRLF). 3. The server cannot send any unsolicited responses after sending that tagged OK and before receiving the next command. The last introduces a new server mode and gets in the way of extending IDLE... right now, I think that server mode is more trouble than it's worth. What is the problem if compression stays on once it's turned on? I can't recall any relevant problems with STARTTLS, which behaves that way. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 08:00:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fllqx-0006Fj-Md; Thu, 01 Jun 2006 08:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fllqv-00069B-BM for lemonade@ietf.org; Thu, 01 Jun 2006 08:00:37 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fllqt-00021s-Sn for lemonade@ietf.org; Thu, 01 Jun 2006 08:00:37 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k51C0XQX003964; Thu, 1 Jun 2006 15:00:34 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 15:00:01 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 15:00:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Thu, 1 Jun 2006 14:59:48 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446572BB5DF@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Thread-Index: AcaE6IxS9ZanIPeBRZWKCWkr0tisxgAiYE3g From: To: , X-OriginalArrivalTime: 01 Jun 2006 12:00:01.0167 (UTC) FILETIME=[E93071F0:01C68572] X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >> - "a vfolder should appear to function as a regular mailbox"=20 >> Question: Can one create a VFOLDER based on a VFOLDER? > The draft says this is supported. =20 Could You point out where? I must have missed it. Thank You. If I create a view chain like this: //Inbox/Mails from Joseph/Today only/New mails only/ And I delete the "Today only" view, what will happen? I understand the = draft describes the case when the mailbox is deleted/moved, but not the = case when a VFOLDER is deleted from a chain. Weird case I know, but I = would like to know what happens in this case. Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh at nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 Sent: 31 May, 2006 22:21 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); lemonade@ietf.org Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt At 1:02 PM +0300 5/31/06, wrote: > - what is a "potentially large or high velocity mailbox" I thought this was amusing wording. I suppose "high velocity"=20 mailbox is one that resides on a mobile device that has been hurtled at = high speed towards someone or something? (I assume the intent is one = whose contents change frequently.) > - "a vfolder should appear to function as a regular mailbox"=20 > Question: Can one create a VFOLDER based on a VFOLDER? The draft says this is supported. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Nine out of 10 = doctors agree that 1 out of 10 doctors is an idiot. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 08:26:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlmGJ-0003HM-Le; Thu, 01 Jun 2006 08:26:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlmGI-0003H9-LQ for lemonade@ietf.org; Thu, 01 Jun 2006 08:26:50 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlmGG-0003Yh-BA for lemonade@ietf.org; Thu, 01 Jun 2006 08:26:50 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FlmGF-0001tp-KV; Thu, 01 Jun 2006 12:26:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 1EAB1498008; Thu, 1 Jun 2006 13:30:19 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27419-09; Thu, 1 Jun 2006 13:30:10 +0100 (BST) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:4ced:24e9:6906:374c]) by turner.dave.cridland.net (Postfix) with ESMTP id 6335C498006; Thu, 1 Jun 2006 13:30:10 +0100 (BST) Date: Thu, 01 Jun 2006 13:25:59 +0100 Subject: RE: [lemonade] COMPRESS Thoughts References: <0FA975F2D8295A448BE3ADC1612446572BB319@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC1612446572BB319@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <3564.1149164759.944000@JOHN> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Jun 01 09:55:48 2006, Zoltan.Ordogh@nokia.com wrote: > Does (2) mean that when the client sends email it cannot compress > it? > Thank You. > No, but the lack of point 6 means that sending email isn't compressed - which is why we need to define a similar extension for Submission. I'll reiterate that you do see compression for data sent from the client, I've just found this to be less effective, and I can believe that the resources required for compression may outweigh the benefits on some clients. (Again, I doubt this is the case for mobile handsets, or when encryption is active). Where no compression is performed, there is a per-block overhead of 5 octets, and those blocks can't be streamed. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 08:26:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlmGO-0003J2-QL; Thu, 01 Jun 2006 08:26:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlmGN-0003If-EI for lemonade@ietf.org; Thu, 01 Jun 2006 08:26:55 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlmGM-0003Yu-4O for lemonade@ietf.org; Thu, 01 Jun 2006 08:26:55 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FlmGL-0001xX-L2; Thu, 01 Jun 2006 12:26:53 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 0EA4E498006; Thu, 1 Jun 2006 13:30:25 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27551-01; Thu, 1 Jun 2006 13:30:17 +0100 (BST) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:4ced:24e9:6906:374c]) by turner.dave.cridland.net (Postfix) with ESMTP id D1D73498007; Thu, 1 Jun 2006 13:30:16 +0100 (BST) Date: Thu, 01 Jun 2006 13:26:05 +0100 Subject: Re: [lemonade] COMPRESS Thoughts References: In-Reply-To: MIME-Version: 1.0 Message-Id: <3564.1149164766.394000@JOHN> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Jun 01 10:44:52 2006, Arnt Gulbrandsen wrote: > Dave Cridland writes: >> As I say, though, actually compressing does reduce the octet >> count, and compressed blocks don't have the overhead - I'm not >> clear if a new block needs to be started for a Z_SYNC_FLUSH or >> not, in fact. I've never seen compression actually expand data. > > I have, for exactly one IMAP command. I think it was the very first > "select inbox" after "compress deflate". All subsequent commands > compress, and most compress well. > > Ah, I don't see that, because I send "compress deflate" prior to an "authenticate digest-md5" using the SASL-IR extension, meaning there's base64 encoded data, which usually compresses. > I bet Polymer constructs its IMAP commands cleverly and uses short > tags, which gives more variety, and that's why you see only 50% > compression on the upstream. Well, I'm really hoping that any client intending to be deployed over low-bandwidth (or usage-billed) links would do at least the same. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 08:27:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlmGj-0003PY-1I; Thu, 01 Jun 2006 08:27:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlmGi-0003PQ-DB for lemonade@ietf.org; Thu, 01 Jun 2006 08:27:16 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlmGg-0003Za-W6 for lemonade@ietf.org; Thu, 01 Jun 2006 08:27:16 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FlmGf-0003fY-OF; Thu, 01 Jun 2006 12:27:13 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 5928C498006; Thu, 1 Jun 2006 13:30:45 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27556-02; Thu, 1 Jun 2006 13:30:37 +0100 (BST) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:4ced:24e9:6906:374c]) by turner.dave.cridland.net (Postfix) with ESMTP id 93110498008; Thu, 1 Jun 2006 13:30:29 +0100 (BST) Date: Thu, 01 Jun 2006 13:26:18 +0100 Subject: Re: [lemonade] COMPRESS Thoughts References: <330A23D8336C0346B5C1A5BB1966664702F6D036@ATLANTIS.Brooktrout.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <3564.1149164779.132000@JOHN> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Jun 01 11:30:33 2006, Arnt Gulbrandsen wrote: > Eric Burger writes: >> (4) Protocol allows for client to turn it on or off at will (not >> per body part, but point in time in session) > > There's a performance gotcha to this, I realized while changing my > daughter's nappies at 6am this morning. > > Ah, well while changing my daughter's nappy just now, I decided that it's not such a big issue. > The compression library likes to read in big chunks. Everyone likes > to do I/O in big chunks. Reading network input one byte at a time > is such a performance drag. If the client tells the server that > starting with the next command, its commands are uncompressed, the > server's compression library has to stop reading at the right byte. > It can't simply read all it can eat. Ditto for responses. > > Ah, but in the case of zlib at least, it knows when the deflate stream has ended and doesn't consume any further octets, so you can extract the data back from the z_stream structure. > What is the problem if compression stays on once it's turned on? I > can't recall any relevant problems with STARTTLS, which behaves > that way. You can turn encryption off within TLS, however. (Or compression). There is a minor point that nobody ever does this, however, the facility is there if required. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 08:44:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlmXX-0006cX-DN; Thu, 01 Jun 2006 08:44:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlmXW-0006Yh-Hz for lemonade@ietf.org; Thu, 01 Jun 2006 08:44:38 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlmXT-0005Q9-4e for lemonade@ietf.org; Thu, 01 Jun 2006 08:44:38 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 78B474AC50; Thu, 1 Jun 2006 14:44:33 +0200 (CEST) Message-Id: <81xfQjwmxy+v6vmlaq66fg.md5@libertango.oryx.com> Date: Thu, 1 Jun 2006 14:45:10 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] COMPRESS Thoughts References: <330A23D8336C0346B5C1A5BB1966664702F6D036@ATLANTIS.Brooktrout.com> <3564.1149164779.132000@JOHN> In-Reply-To: <3564.1149164779.132000@JOHN> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > Ah, but in the case of zlib at least, it knows when the deflate stream > has ended and doesn't consume any further octets, so you can extract > the data back from the z_stream structure. Much like the medicine men can extract the pills you shouldn't have eaten back from your belly, provided you haven't digested them yet. It's just not pleasant. Much better to avoid the whole situation. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 09:04:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flmqp-0000sC-K8; Thu, 01 Jun 2006 09:04:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flmqo-0000rr-Al for lemonade@ietf.org; Thu, 01 Jun 2006 09:04:34 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flmnh-0007Ps-8q for lemonade@ietf.org; Thu, 01 Jun 2006 09:01:21 -0400 X-IronPort-AV: i="4.05,197,1146456000"; d="scan'208"; a="33525884:sNHT35069820" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jun 2006 09:01:17 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Minutes, Interim Day 1 Thread-Index: AcaFe3is1NqaXGHWSq+1TTpsveq3cA== From: "Burger, Eric" To: "Enhancements to Internet email to support diverse serviceenivronments" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Subject: [lemonade] Draft Minutes, Interim Day 1 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Posted to http://www3.ietf.org/proceedings/06jul/minutes/lemonade.txt Draft Minutes, lemonade Interim Meeting 65,5 31 May 2006 Chairs: Eric Burger Glenn Parsons Attendees: Alexey Melnikov Arnt Gulbrandsen Ray Cromwell Dave Cridland Greg Vaudreuil Mike Parsel Ken Murcheson Jerry Shih Stephane Maes Jabber Logs 31 May 2006: = http://www3.ietf.org/meetings/ietf-logs/lemonade/2006-05-31.html Meeting Goal: Get updates to documents by 19 June 2006 in time for WGLC = before or at IETF 66 in Montreal. Draft Discussions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RECONNECT --------- Issue: Do we need to mandate a minimum number of outstanding sessions a = server must support? Discussion: Could make clients easier to implement if they knew that a = server would have at least so many sessions available. Rejoinder: No matter what, another client can consume sessions, so the = client must have code to deal with exhaustion of session resources. = Thus there is no benefit of having a preset minimum number of sessions = available for reconnect. Result: Be silent on a minimum number of sessions. Issue: Do we need server-side RECONNECT? Discussion: RECONNECT authors realized the tokens being passed to let = the server know which session was being reconnected was identical to the = state the server needed to know to re-establish state. Thus it is = possible for the server to be stateless. This follows IETF practice of avoiding fate sharing. The client holds = the state, and if the client fails, it doesn't care the state is lost, = as it lost the state anyway. The proposal does not add any burden on = clients, as the client needed to store the same information with the = server-driven scheme. Rejoinder: Server-driven document is already written; do we want to = delay? Result: Create new document centered around client-driven RECONNECT. It = will be a work group document: draft-ietf-lemonade-reconnect-client; we = are confident in its status as only about 2 paragraphs change. After = the new draft is issued and the old draft is updated (there are some = ABNF issues, etc. that need to be addressed), we will preferably chose = one document and kill the other. Alternately, we will chose one, = reference it in Profile-bis, and release the other as Experimental. = Worst-case is both documents progress. IMAP URL (2192-bis) ------------------- Issue: Alexey needs Mark's input to decide what goes into 2192-bis = versus URLAUTH. Resolution: Alexey will e-mail Mark directly. Issue: Should 2192-bis include examples of extensions from BINARY, = URLFETCH, imap-search-ret? Resolution: If those drafts are stable, then yes, otherwise, no. Alexey = will send note to list if he doesn't get a response, then he will assume = the drafts are not stable. CONVERT ------- Issue: ISO-8859-n has 16 values for n. Which one(s) do we mandate? Resolution: All of them (?). Clearly at least ISO-8859-1 (trivially = easy) and ISO-8859-5 (in honor of Alexey) will be mandatory to = implement. Issue: The original draft had a bunch of conversions that are now not = mandatory. Resolution: Leave the text, but change RFC 2119 language from = MUST/SHOULD to MAY. Note that OMA will impose relevant = mandatory-to-implement conversions. We will ensure the protocol can = handle them, but will not mandate any particular conversions outside of = ISO-8859-n to UTF-8. COMPRESS -------- Note: There are some very interesting results discussed in the Jabber = log , = around the 12:20 time mark, about compression experiment results for TLS = and compress=3Ddeflate. The short of it is that traffic with a moderate = amount of attachments gets 70% compression using TLS; traffic with lots = of attachments gets better compression with compress=3Ddeflate. Issue: How to disambiguate Content-Transfer-Encoding from Content-Type? Discussion: VPIM experience is the C-T-E is not well supported. One = proposal is to use magic MIME types. Rejoinder: Only a C-T-E knowledgeable client will request compression = from a C-T-E knowledgeable server. Moreover, using C-T-E is a correct = protocol thing to do, as in "say what we mean." Reminder: The server is in the best position to decide whether or not to = compress (if compression accepted by the client). The client-driven use = case, where the client wants to save CPU at the expense of radio power, = does not match the physics of the situation.=20 Discussion: Propose compress=3Ddeflate (draft-arnt-imap-deflate-02). = Unquestionable desire to NOT have the mechanism be on a = request-per-body-part basis. However, there is also a desire to have = the mechanism be controllable (on or off) at client-requested point in = the session. Discussion: Although deflate is the compression algorithm of gzip, and = the proposed lemonade mechanism was called gzip, we are NOT discussing = using gzip anymore. This means that the stream will not include the = actual MIME type or file name (as would happen if we used the entire = gzip structure). Discussion: Clear win for downstream (server->client) compression. = However, compression could be a cost for upstream messages, as the = protocol messages are often smaller than the PDU of the compressed = block. Discussion: What, if in the middle of a transaction, the client says, = "stop compressing"? That isn't a problem, because the IMAP transaction = model says the current transaction completes. Resolution: Move compress out of convert document. Use = compress=3Ddeflate. Ensure the method is controllable. Ensure the = method can be asymmetric (compress one way and not the other). Arnt is to be lead author. Special note: we will re-use the name draft-ietf-lemonade-compress-04, = but the contents will be entirely deleted and the new content will = substantially come from draft-arnt-imap-deflate-02. ENCRYPT ------- Issue: Still not clear what the business / use case is for this feature. = Needs to be clear and distinct. Discussion: Classic industry problem: if we don't do it, someone less = knowledgeable will do it. Resolution: new draft coming. WITHIN ------ Issue: Second recalculation is way too much of a server burden. Discussion: We are not trying to replicate instant messaging. Daily is = enough. Hourly is OK. Resolution: Hourly it is. Issue: Should we give guidance on recomputing views? Resolution: Yes, put in an informative section into the document. VFOLDER ----=AC--- Issue: Anonymous users creating VFOLDERs can be a DoS attack. Resolution: Anonymous users cannot create a VFOLDER, but they can read = them. Issue: Legacy clients might duplicate messages since they don't know the = messages are virtual. Reminder: In Dallas (and on the list) we said that only lemonade clients = could use VFOLDERs. Discussion: Would be very useful for legacy clients to see VFOLDERs. Resolution: Allow VFOLDER only for lemonade clients for now. Issue: What happens if one renames a folder a VFOLDER depends on? Discussion: Original proposal is to delete the VFOLDER. Rejoinder: That would be a customer service nightmare - all of my = folders disappeared?!?! Resolution: VFOLDER calculations get updated when one renames an = underlying VFOLDER. Issue: Can we have a VFOLDER that is the set of messages that are not = selected by any other VFOLDER? Resolution: Submit text. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 09:48:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlnXI-0007y8-QE; Thu, 01 Jun 2006 09:48:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlnXH-0007y0-G5 for lemonade@ietf.org; Thu, 01 Jun 2006 09:48:27 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlnXF-000472-TY for lemonade@ietf.org; Thu, 01 Jun 2006 09:48:27 -0400 Received: from [192.168.0.9] ([62.3.217.253]) by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 1 Jun 2006 14:48:18 +0100 Message-ID: <447EEFCF.1050600@isode.com> Date: Thu, 01 Jun 2006 14:46:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "Burger, Eric" Subject: Re: [lemonade] Draft Minutes, Interim Day 1 References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Encoded: Changed encoding from 8bit for 7bit transmission X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Burger, Eric wrote: >Posted to http://www3.ietf.org/proceedings/06jul/minutes/lemonade.txt > >Draft Minutes, lemonade Interim Meeting 65,5 >31 May 2006 > Some minor additions/corrections. >IMAP URL (2192-bis) >------------------- >Issue: Alexey needs Mark's input to decide what goes into 2192-bis versus = URLAUTH. >Resolution: Alexey will e-mail Mark directly. > I also need some help with sections talking about listing content of a = server and mailbox naming scope. I think Dave has volunteered for that. >Issue: Should 2192-bis include examples of extensions from BINARY, URLFETC= H, imap-search-ret? >Resolution: If those drafts are stable, then yes, otherwise, no. Alexey w= ill send note to list if he doesn't get a response, then he will assume the= drafts are not stable. > [...] >ENCRYPT >------- >Issue: Still not clear what the business / use case is for this feature. = Needs to be clear and distinct. >Discussion: Classic industry problem: if we don't do it, someone less know= ledgeable will do it. >Resolution: new draft coming. > = > But this is not going to be included in Lemonade Phase 2. (If my memory = doesn't fail me) >VFOLDER >----=AC--- >Issue: Anonymous users creating VFOLDERs can be a DoS attack. >Resolution: Anonymous users cannot create a VFOLDER, but they can read the= m. > >Issue: Legacy clients might duplicate messages since they don't know the m= essages are virtual. >Reminder: In Dallas (and on the list) we said that only lemonade clients c= ould use VFOLDERs. >Discussion: Would be very useful for legacy clients to see VFOLDERs. >Resolution: Allow VFOLDER only for lemonade clients for now. > >Issue: What happens if one renames a folder a VFOLDER depends on? >Discussion: Original proposal is to delete the VFOLDER. >Rejoinder: That would be a customer service nightmare - all of my folders = disappeared?!?! >Resolution: VFOLDER calculations get updated when one renames an underlyin= g VFOLDER. > "when one renames an underlying mailbox" >Issue: Can we have a VFOLDER that is the set of messages that are not sele= cted by any other VFOLDER? >Resolution: Submit text. > = > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 10:08:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlnqD-0002sj-K6; Thu, 01 Jun 2006 10:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlnqC-0002sd-7z for lemonade@ietf.org; Thu, 01 Jun 2006 10:08:00 -0400 Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flnq9-0005yJ-S7 for lemonade@ietf.org; Thu, 01 Jun 2006 10:08:00 -0400 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k51E7twV031078 for ; Thu, 1 Jun 2006 09:07:55 -0500 Received: from us.oracle.com (dhcp-amer-rmdc-csvpn-gw4-141-144-99-221.vpn.oracle.com [141.144.99.221]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k51E7qnO001931 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 1 Jun 2006 08:07:54 -0600 From: "Stephane H. Maes" To: "lemonade@ietf.org" Subject: [Lemonade] Discussion items from thsimorning on VFOLDER and WITHIN Date: Thu, 1 Jun 2006 07:07:49 -0700 Organization: Oracle Message-ID: <20060601070749343.00000000428@smaes-lap3> X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8010) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Spam-Score: 0.5 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org = Here are the items that were discussed. = Stephane = PS: = = At todays FtF, there were some issues in VFOLDER discussed that we would ap= preciate some feedback in guidance from the WG on. After the merge of VFOLDER and VIEW there are several parts of the draft wh= ich now offer optional behavior. Many members seem to think this is not des= ired and that Lemonade specs should offer clear and mandatory behavior to r= educe client complexity. Assuming you agree with this, we need to decide wh= ich of the optional behaviors we want to be MUSTs and which to disallow. I = will list them below: 1) RENAME - if a backing mailbox is renamed, what happens to views which ar= e linked to this mailbox? Draft currently offers two options: a) acts just like a DELETE of the backing mailbox, as far as what happens t= o vfolders dependent on that backing mailbox. Client/user must recreate vfo= lder and resync. b) nothing happens. That is, the server handles updating all of the linked = vfolders to use point to the renamed mailbox. Randy put this as Windows (95) Shortcut semantics vs Mac Alias semantics. := ) The FtF group seemed to lean towards the second option as it would reduce= user confusion, lower customer support calls, and seems to be what people = would want anyway. Anyone have any serious reasons why we should not mandat= e behavior b) ? 2) APPEND/COPY support for VFOLDER. Current merged draft says server can de= cide to reject an APPEND, or allow it. There were arguments that perhaps it should be mandated to allow appends ex= cept in cases where ACL prevents it. Arnt proposed a case where a client mi= ght APPEND something, but the new message may not may any search criteria o= f the view, and thus some clients (particular those not VFOLDER aware) may = make some bogus assumptions. Alexey pointed out that this could already be = the case, since a secondary client connection could expunge the newly appen= ded message before the appender gets to see it. Opinions? = 3) VFOLDERs based on dynamic message attributes. Old VFOLDER draft allows s= erver to reject any VFOLDER creation if it deems search too expensive or in= valid (with appropriate response code) Old VFOLDER draft disallowed dynamic= attributes, VIEW allowed them. New VFOLDER+VIEW draft allows server to mak= e the decision. Randy pointed out that this would complicate some clients which might creat= e vfolders without a user interface, such that a rejection of the search pa= rameters by the search would mean many or all clients would have to have ex= tra code to deal with this case (the client would not be able to prompt the= user and ask them to rewrite the search based on returned error messages b= ecause the original search was not user authored) So we have many options: a) leave as it is. b) mandate static message attributes support only, leave dynamic attributes= for later draft c) mandate dynamic attribute support Opinions? = 4) What are the requirements for when / how often a vfolder's search is eva= luated? Some of the list of things which should trigger it: all agree on me= ssage deposit + some options: a) possibly any IMAP command (including NOP) b) any IMAP command that modifies message state c) on SELECT d) periodically I think everyone agreed that on message deposit, users will want to see thi= s reflected immediately, but that it may be acceptable for some if flag cha= nges or expunges are delayed. 5) The duplicate message/new UID problem. It is possible for some vfolder s= earches + sequence of operations to cause a message to appear in a vfolder,= then disappear, and then reappear. As discussed currently, for this to wor= k, when the message gets re-included in a vfolder it needs to be assigned a= new UID for each time it is moved "to the front" of the mailbox. Randy suggested an alternative -- when a message goes "out of view", don't = expunge it, leave it in the VFOLDER. Then, if a flag modification causes th= e message to be re-included, you don't need to generate a new UID, the clie= nt just resyncs the flags for that message. What's the opinion on this? My only reaction is that some users might be su= rprised if they expect some messages to disappear out of view. For example,= if a vfolder were to contain all messages which were flagged, and the user= unflags the message, they might expect it to disappear from the vfolder. _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or s= tephane.maes@gmail.com (Google) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 11:53:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpUS-00078Q-AB; Thu, 01 Jun 2006 11:53:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpUQ-00077X-PB for lemonade@ietf.org; Thu, 01 Jun 2006 11:53:38 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpUP-0000hX-75 for lemonade@ietf.org; Thu, 01 Jun 2006 11:53:38 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 0E9734AC46; Thu, 1 Jun 2006 17:53:35 +0200 (CEST) Message-Id: Date: Thu, 1 Jun 2006 17:54:13 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [Lemonade] Discussion items from thsimorning on VFOLDER and WITHIN References: <20060601070749343.00000000428@smaes-lap3> In-Reply-To: <20060601070749343.00000000428@smaes-lap3> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Stephane H. Maes writes: > 2) APPEND/COPY support for VFOLDER. Current merged draft says server > can decide to reject an APPEND, or allow it. > > There were arguments that perhaps it should be mandated to allow > appends except in cases where ACL prevents it. Arnt proposed a case > where a client might APPEND something, but the new message may not > may any search criteria of the view, and thus some clients > (particular those not VFOLDER aware) may make some bogus assumptions. > Alexey pointed out that this could already be the case, since a > secondary client connection could expunge the newly appended message > before the appender gets to see it. > > Opinions? As I mentioned, this isn't a parallel. The case I fear is where the client has a loop like this: decide which messages should be in the mailbox until all those messages are in the mailbox: for each message not in the mailbox: append it (Programs like imapsync contain code like this. Programs which copy mail en masse from one server to another.) In Alexey's case, the message is appended twice. (Three times if two clients come along an expunge.) In the case I'm afraid of, it's appended repeatedly until the backing mailbox explodes. > 5) The duplicate message/new UID problem. It is possible for some > vfolder searches + sequence of operations to cause a message to > appear in a vfolder, then disappear, and then reappear. As discussed > currently, for this to work, when the message gets re-included in a > vfolder it needs to be assigned a new UID for each time it is moved > "to the front" of the mailbox. > > Randy suggested an alternative -- when a message goes "out of view", > don't expunge it, leave it in the VFOLDER. Then, if a flag > modification causes the message to be re-included, you don't need to > generate a new UID, the client just resyncs the flags for that > message. > > What's the opinion on this? My only reaction is that some users might > be surprised if they expect some messages to disappear out of view. > For example, if a vfolder were to contain all messages which were > flagged, and the user unflags the message, they might expect it to > disappear from the vfolder. Randy's suggestion covers session-bound clients, but not offline clients. Consider a mobile client which connects three times, and the flag changes in the pauses between connections. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 12:42:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlqFT-0005xg-5p; Thu, 01 Jun 2006 12:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlqFS-0005rL-HE for lemonade@ietf.org; Thu, 01 Jun 2006 12:42:14 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlqFQ-0006jS-32 for lemonade@ietf.org; Thu, 01 Jun 2006 12:42:14 -0400 Received: from [192.168.0.9] ([62.3.217.253]) by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 1 Jun 2006 17:42:09 +0100 Message-ID: <447F1889.9020101@isode.com> Date: Thu, 01 Jun 2006 17:40:41 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] RECONNECT References: <330A23D8336C0346B5C1A5BB1966664702F6CD47@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702F6CD47@ATLANTIS.Brooktrout.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Burger, Eric wrote: >Dave and Alexey realized that it is the same number of bytes and >round-trips to have the client store the state for reconnect than to >have the server store the state. > > To clarify this: the state that the client passes to the server *is* the state stored on the server. The advantage of client side version is that it is easier to implement on the server side. It doesn't change anything on the client side, as clients must already store the same information anyway. The advantage of server side state is that in the future we can add extra state to it, which is not necessarily state associated with the currently selected mailbox. Mandating client side quick reconnect now doesn't prevent us from doing server side quick reconnect in the future, if needed. >Alexey believes it is a small number of edits to make the change to the >document. > >Because of our short time-lines, we will not abandon the server-side >RECONNECT mechanism. Rather, we will have a new document, >draft-ietf-lemonade-reconnect-client, that will describe the client-side >mechanism. > >The work group will examine both drafts and preferably pick one >approach. That approach will go standards-track while the other will >die. > >Less preferably, we can keep both drafts, make one Experimental, and >reference the standards-track document in Profile bis. > >Least preferably, we go with both drafts. > >Thoughts? > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 14:04:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrWz-0000dR-PL; Thu, 01 Jun 2006 14:04:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrWx-0000dM-S0 for lemonade@ietf.org; Thu, 01 Jun 2006 14:04:23 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlrWw-0006Eo-GG for lemonade@ietf.org; Thu, 01 Jun 2006 14:04:23 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k51I4Luv022466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Jun 2006 11:04:21 -0700 Received: from [10.1.241.240] (vpn-10-50-16-34.qualcomm.com [10.50.16.34]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k51I3vPK017792; Thu, 1 Jun 2006 11:04:13 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC1612446572BB5DF@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446572BB5DF@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 1 Jun 2006 11:01:29 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 2:59 PM +0300 6/1/06, wrote: > >> - "a vfolder should appear to function as a regular mailbox" >>> Question: Can one create a VFOLDER based on a VFOLDER? > >> The draft says this is supported. > > Could You point out where? I must have missed it. Thank You. In Section 2, the draft says: From the client's perspective, a vfolder should appear to function as a regular mailbox. This includes the ability for a new virtual folder to be created by using another virtual folder as a backing mailbox. > If I create a view chain like this: > //Inbox/Mails from Joseph/Today only/New mails only/ > And I delete the "Today only" view, what will happen? I understand > the draft describes the case when the mailbox is deleted/moved, but > not the case when a VFOLDER is deleted from a chain. Weird case I > know, but I would like to know what happens in this case. > Thank You. I think we agreed that if the backing mailbox is deleted, the vfolder is also deleted. So: If - mailbox TOP is a vfolder using mailbox MIDDLE as a backing store, and - mailbox MIDDLE is a vfolder using mailbox BOTTOM as a backing store, and - mailbox BOTTOM is a normal mailbox, then as I understand it, - if mailbox MIDDLE is deleted, then mailbox TOP also gets deleted - if mailbox BOTTOM is deleted, then both mailboxes TOP and MIDDLE get deleted -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- My definition of a free society is a society where it is safe to be unpopular. --Adlai Stevenson _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 14:09:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flrc8-00026e-DO; Thu, 01 Jun 2006 14:09:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flrc7-00026Z-FV for lemonade@ietf.org; Thu, 01 Jun 2006 14:09:43 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flrc6-0006Zc-5t for lemonade@ietf.org; Thu, 01 Jun 2006 14:09:43 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k51I9a6g030388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Jun 2006 11:09:36 -0700 Received: from [10.1.241.240] (vpn-10-50-16-34.qualcomm.com [10.50.16.34]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k51I9Saq020548; Thu, 1 Jun 2006 11:09:34 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 1 Jun 2006 11:09:16 -0700 To: "Burger, Eric" , "Enhancements to Internet email to support diverse serviceenivronments" From: Randall Gellens Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 9:01 AM -0400 6/1/06, Eric Burger wrote: > Draft Minutes, lemonade Interim Meeting 65,5 > 31 May 2006 > > Chairs: > Eric Burger > Glenn Parsons > > Attendees: > Alexey Melnikov > Arnt Gulbrandsen > Ray Cromwell > Dave Cridland > Greg Vaudreuil > Mike Parsel > Ken Murcheson > Jerry Shih > Stephane Maes I was there (a bit late due to Chicago weather). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- When news of Alexander Graham Bell's invention reached the United Kingdom, the chief engineer of the British Post Office failed to be impressed. "The Americans," he said loftily, "have need of the telephone -- but we do not. We have plenty of messenger boys..." _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 14:30:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrwL-00074s-Gb; Thu, 01 Jun 2006 14:30:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrwK-00072S-65 for lemonade@ietf.org; Thu, 01 Jun 2006 14:30:36 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlrwI-0008Ss-S5 for lemonade@ietf.org; Thu, 01 Jun 2006 14:30:36 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k51IUU5P032466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Jun 2006 11:30:30 -0700 Received: from [10.1.241.240] (vpn-10-50-16-34.qualcomm.com [10.50.16.34]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k51IUOOe027685; Thu, 1 Jun 2006 11:30:28 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <330A23D8336C0346B5C1A5BB1966664702F6D036@ATLANTIS.Brooktrout.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 1 Jun 2006 11:24:45 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] COMPRESS Thoughts Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:30 PM +0200 6/1/06, Arnt Gulbrandsen wrote: > What is the problem if compression stays on=20 > once it's turned on? I can't recall any=20 > relevant problems with STARTTLS, which behaves=20 > that way. As I recall, it was St=E9phan that has been=20 insisting that the client be able to turn off=20 compression. I've been discussing the issue with some handset=20 people, and so far everything I've heard is that=20 compression is a Good Thing and a client would=20 not want to disable it. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. --Nathaniel Borenstein _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 14:30:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrwQ-000787-MV; Thu, 01 Jun 2006 14:30:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrwP-000763-Gr for lemonade@ietf.org; Thu, 01 Jun 2006 14:30:41 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlrwO-0008T0-6q for lemonade@ietf.org; Thu, 01 Jun 2006 14:30:41 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k51IUX63032469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Jun 2006 11:30:34 -0700 Received: from [10.1.241.240] (vpn-10-50-16-34.qualcomm.com [10.50.16.34]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k51IUOOg027685; Thu, 1 Jun 2006 11:30:31 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 1 Jun 2006 11:23:41 -0700 To: "Burger, Eric" , "Enhancements to Internet email to support diverse serviceenivronments" From: Randall Gellens Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 9:01 AM -0400 6/1/06, Eric Burger wrote: > VFOLDER > ----=AC--- > Issue: Legacy clients might duplicate messages=20 > since they don't know the messages are virtual. > Reminder: In Dallas (and on the list) we said=20 > that only lemonade clients could use VFOLDERs. > Discussion: Would be very useful for legacy clients to see VFOLDERs. > Resolution: Allow VFOLDER only for lemonade clients for now. How are legacy clients barred from SELECTing vfolders? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Rank of Catwoman among the "superheros" American boys under the age of ten say they would most like to be: 1. --(Harper's Index) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 14:48:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsDo-0004Ql-JB; Thu, 01 Jun 2006 14:48:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsDo-0004Qg-2l for lemonade@ietf.org; Thu, 01 Jun 2006 14:48:40 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlsDm-0002yQ-PV for lemonade@ietf.org; Thu, 01 Jun 2006 14:48:40 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k51ImbBS027105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Jun 2006 11:48:37 -0700 Received: from [10.1.241.240] (vpn-10-50-16-34.qualcomm.com [10.50.16.34]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k51ImJrZ026299; Thu, 1 Jun 2006 11:48:33 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060601070749343.00000000428@smaes-lap3> References: <20060601070749343.00000000428@smaes-lap3> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 1 Jun 2006 11:47:04 -0700 To: "stephane.maes@oracle.com" , "lemonade@ietf.org" From: Randall Gellens Subject: Re: [Lemonade] Discussion items from thsimorning on VFOLDER and WITHIN Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 7:07 AM -0700 6/1/06, Stephane H. Maes wrote: > secondary client connection could expunge the newly appended > message before the appender gets to see it. That seems very much an edge case. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The pure and simple truth is rarely pure and never simple. --Oscar Wilde _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 15:03:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsSX-0008IO-Ut; Thu, 01 Jun 2006 15:03:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsSW-0008Ew-AJ for lemonade@ietf.org; Thu, 01 Jun 2006 15:03:52 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlsSU-0005eM-W0 for lemonade@ietf.org; Thu, 01 Jun 2006 15:03:52 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k51J3hlb029473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Jun 2006 12:03:45 -0700 Received: from [10.1.241.240] (vpn-10-50-16-34.qualcomm.com [10.50.16.34]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k51J3VjY009632; Thu, 1 Jun 2006 12:03:39 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20060601070749343.00000000428@smaes-lap3> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 1 Jun 2006 12:02:47 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [Lemonade] Discussion items from thsimorning on VFOLDER and WITHIN Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 5:54 PM +0200 6/1/06, Arnt Gulbrandsen wrote: >> 5) The duplicate message/new UID problem. It is possible for some >> vfolder searches + sequence of operations to cause a message to >> appear in a vfolder, then disappear, and then reappear. As >> discussed currently, for this to work, when the message gets >> re-included in a vfolder it needs to be assigned a new UID for >> each time it is moved "to the front" of the mailbox. >> >> Randy suggested an alternative -- when a message goes "out of >> view", don't expunge it, leave it in the VFOLDER. Then, if a flag >> modification causes the message to be re-included, you don't need >> to generate a new UID, the client just resyncs the flags for that >> message. >> >> What's the opinion on this? My only reaction is that some users >> might be surprised if they expect some messages to disappear out >> of view. For example, if a vfolder were to contain all messages >> which were flagged, and the user unflags the message, they might >> expect it to disappear from the vfolder. > > Randy's suggestion covers session-bound clients, but not offline > clients. Consider a mobile client which connects three times, and > the flag changes in the pauses between connections. But if a message goes in and out of view, and gets a new UID each time it reappears, wouldn't it get downloaded multiple times? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- We should never forget that everything Adolf Hitler did in Germany was legal and everything the Hungarian freedom fighters did in Hungary was illegal. --Martin Luther King, Jr., 1963 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 15:08:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsWZ-0007QO-Au; Thu, 01 Jun 2006 15:08:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsWX-0007QJ-UX for lemonade@ietf.org; Thu, 01 Jun 2006 15:08:01 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlsWW-0006Ax-Gr for lemonade@ietf.org; Thu, 01 Jun 2006 15:08:01 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 80B0E4AC23; Thu, 1 Jun 2006 21:07:59 +0200 (CEST) Message-Id: <3rUAVGSUFos9vsPyoMtEXg.md5@libertango.oryx.com> Date: Thu, 1 Jun 2006 21:08:37 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [Lemonade] Discussion items from thsimorning on VFOLDER and WITHIN References: <20060601070749343.00000000428@smaes-lap3> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Randall Gellens , "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens writes: > But if a message goes in and out of view, and gets a new UID each time > it reappears, wouldn't it get downloaded multiple times? Yes. So it had better not happen often. Fortunately, I don't think it will. If people use UNSEEN and SEEN in vfolders, and the \seen flag keeps being toggled on and off, then we have a problem. But the \seen flag typically is set once and that's it. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 15:24:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsmH-0004x1-Bh; Thu, 01 Jun 2006 15:24:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsmF-0004vl-Uq for lemonade@ietf.org; Thu, 01 Jun 2006 15:24:15 -0400 Received: from out3.smtp.messagingengine.com ([66.111.4.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlsmD-0006vy-LT for lemonade@ietf.org; Thu, 01 Jun 2006 15:24:15 -0400 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 586A9D69A64; Thu, 1 Jun 2006 15:24:09 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Thu, 01 Jun 2006 15:24:10 -0400 X-Sasl-enc: f3hQdQYmVUBhyAeyk/lAiLvTNqEf7yniFlNpCU1Oi7IG 1149189849 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 5650B7FF4; Thu, 1 Jun 2006 15:24:04 -0400 (EDT) Date: Thu, 01 Jun 2006 15:24:03 -0400 From: Cyrus Daboo To: Randall Gellens , Arnt Gulbrandsen , lemonade@ietf.org Subject: Re: [Lemonade] Discussion items from thsimorning on VFOLDER and WITHIN Message-ID: <72FDD20C56FDCB399E7AAF41@Cyrus-Daboo.local> In-Reply-To: References: <20060601070749343.00000000428@smaes-lap3> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Randall, --On June 1, 2006 12:02:47 PM -0700 Randall Gellens wrote: > But if a message goes in and out of view, and gets a new UID each time it > reappears, wouldn't it get downloaded multiple times? Yes. The current drafts says this: Future versions of VFOLDER may introduce a new server supported mechanism for efficiently determining the original mailbox and UID of a message I think THIS version of VFOLDER should provide such a mechanism. A new OUID fetch parameter that returns a relative imap url with the mailbox, uidvalidty and uid of the underlying message would be one simple solution. The other would be a more general GUID mechanism - but that may be going too far... Note that duplicate detection is only going to be done by clients that are aware they are dealing with a VFOLDER so there needs to be a select response to indicate that (this may have been discussed in the meeting - sorry if I missed it). -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 15:26:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsoA-0007dh-Qo; Thu, 01 Jun 2006 15:26:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flso9-0007dc-I6 for lemonade@ietf.org; Thu, 01 Jun 2006 15:26:13 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flso8-0006yc-9I for lemonade@ietf.org; Thu, 01 Jun 2006 15:26:13 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id E192B272B4; Thu, 1 Jun 2006 13:26:11 -0600 (MDT) In-Reply-To: References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> Content-Transfer-Encoding: quoted-printable From: Curtis King Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Date: Thu, 1 Jun 2006 13:26:11 -0600 To: Randall Gellens X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 1-Jun-06, at 12:23 PM, Randall Gellens wrote: > At 9:01 AM -0400 6/1/06, Eric Burger wrote: > >> VFOLDER >> ----=AC--- > > >> Issue: Legacy clients might duplicate messages since they don't =20 >> know the messages are virtual. >> Reminder: In Dallas (and on the list) we said that only lemonade =20 >> clients could use VFOLDERs. >> Discussion: Would be very useful for legacy clients to see VFOLDERs. >> Resolution: Allow VFOLDER only for lemonade clients for now. > > How are legacy clients barred from SELECTing vfolders? If we are going to-do this then why keep the mailbox framework? =20 VFOLDER currently has a number of show stoppers already: 1. duplicate messages. 2. message going into and out of focus. 3. UID issues caused by 1 and 2. 4. Do you delete messages when you delete the VFOLDER? According to =20 the draft it is supposed to behave like a real mailbox. Why not have filters you can apply to mailbox? ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 16:28:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FltmV-0007w4-IZ; Thu, 01 Jun 2006 16:28:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FltmU-0007vR-On for lemonade@ietf.org; Thu, 01 Jun 2006 16:28:34 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FltmT-0006M4-Eq for lemonade@ietf.org; Thu, 01 Jun 2006 16:28:34 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 0618D272B4; Thu, 1 Jun 2006 14:28:33 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <82C1B793-E3C6-4ABB-94F7-CE3B6A703250@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Date: Thu, 1 Jun 2006 14:28:33 -0600 To: Randall Gellens , Enhancements to Internet email to support diverse serviceenivronments X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 1-Jun-06, at 1:26 PM, Curtis King wrote: > Why not have filters you can apply to mailbox? Sorry, this needs more detail. Why not have a draft which treats filters as filters instead of mailboxes? I understand using the mailbox metaphor has lots of appeal, but users and MUAs expect if not rely on specific mailbox behaviors which are hard to reproduce using VFOLDER. I still think the best idea is from Cyrus: -------- Instead, what I would propose for clients being able to 'run scripts', is a combination of the following: 1) Enhance the SEARCH command with better comparators (globbing, regex etc) 2) Introduce a 'pipe' operation that will allow the result set of the last (or named) search command to be fed into a subsequent fetch/ store. I think there was already a proposal for that. 3) Introduce a 'macro' facility that would allow clients to define commonly used commands via a keyword and store those on the server, and then execute the commands via the keyword. This would allow for 'saved searches' - frequently used search commands stored on the server that can be quickly executed without having to uplaod the search each time. Anyone who has written a client that attempts to do traditional mua filtering using IMAP search will appreciate the benefit of something like that. These 'macros' could execute more than one command at a time with some limitations. e.g. a UID SEARCH followed by a UID COPY, followed by a UID STORE, followed by a UID expunge would emulate an mua filter action that could move messages matching certain criteria to another mailbox. ------- You could get VFOLDER behavior by piping a search to select. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 18:28:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlveZ-0007gq-Aq; Thu, 01 Jun 2006 18:28:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlveY-0007eP-4l for lemonade@ietf.org; Thu, 01 Jun 2006 18:28:30 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlveW-000415-Mr for lemonade@ietf.org; Thu, 01 Jun 2006 18:28:30 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FlveV-0006A9-JP for lemonade@ietf.org; Thu, 01 Jun 2006 22:28:27 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 63AF7498007 for ; Thu, 1 Jun 2006 23:32:03 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32274-07 for ; Thu, 1 Jun 2006 23:31:53 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 483AD498006 for ; Thu, 1 Jun 2006 23:31:53 +0100 (BST) Date: Thu, 01 Jun 2006 23:28:16 +0100 Subject: Re: [Lemonade] Discussion items from thsimorning on VFOLDER and WITHIN References: <20060601070749343.00000000428@smaes-lap3> <72FDD20C56FDCB399E7AAF41@Cyrus-Daboo.local> In-Reply-To: <72FDD20C56FDCB399E7AAF41@Cyrus-Daboo.local> MIME-Version: 1.0 Message-Id: <6226.1149200897.196517@peirce.dave.cridland.net> From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Cyrus, On Thu Jun 1 20:24:03 2006, Cyrus Daboo wrote: > Hi Randall, > > --On June 1, 2006 12:02:47 PM -0700 Randall Gellens > wrote: > >> But if a message goes in and out of view, and gets a new UID each >> time it >> reappears, wouldn't it get downloaded multiple times? > > Yes. The current drafts says this: > > Future versions of VFOLDER may introduce a new server supported > mechanism for efficiently determining the original mailbox and > UID of > a message > > I think THIS version of VFOLDER should provide such a mechanism. A > new OUID fetch parameter that returns a relative imap url with the > mailbox, uidvalidty and uid of the underlying message would be one > simple solution. The other would be a more general GUID mechanism - > but that may be going too far... Now, I included this in my design for virtual mailboxes [everyone has done one of these, right?], but Arnt convinced me against adding it to his or V{FOLDER|MAILBOX}, because of the number of times this would be downloaded before it saved a message download. Basically, it's a tradeoff, and if you have 100 messages, with a 100 octet relative URL, that lands you with a ~10k bill, meaning that to pay for it, the duplicate body parts within those 100 messages must add up to more than 10k. Arnt convinced me that you're unlikely to read both backing and virtual mailboxes sufficiently for this to be a problem actually worthwhile solving. Other options include using the message id, which ought to be unique at least for body parts if not headers, and is part of the Envelope, which good IMAP clients ought to be using anyway. This has the advantage that "mailing list duplicates" would be covered. (And although the mailing list copies actually differ, the body part differences don't matter and the extra headers are small). For disconnected mode clients which aim to synchronize the entire mailbox, either method forces an extra round-trip, though, which depending on latency vs bandwidth may be less desirable. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 18:39:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flvox-00045O-IR; Thu, 01 Jun 2006 18:39:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flvov-00041T-Tn for lemonade@ietf.org; Thu, 01 Jun 2006 18:39:13 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flvou-0005g1-K3 for lemonade@ietf.org; Thu, 01 Jun 2006 18:39:13 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1Flvou-0001av-1f for lemonade@ietf.org; Thu, 01 Jun 2006 22:39:12 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 09B5E498007 for ; Thu, 1 Jun 2006 23:42:48 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32412-05 for ; Thu, 1 Jun 2006 23:42:43 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id CBC36498006 for ; Thu, 1 Jun 2006 23:42:43 +0100 (BST) Date: Thu, 01 Jun 2006 23:39:07 +0100 Subject: Re: [lemonade] Draft Minutes, Interim Day 1 References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <6226.1149201547.685118@peirce.dave.cridland.net> From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Jun 1 19:23:41 2006, Randall Gellens wrote: >> Resolution: Allow VFOLDER only for lemonade clients for now. > > How are legacy clients barred from SELECTing vfolders? They're not, but they're prevented from listing them without being asked with special LIST-EXTENDED selection options. I think this is a mistake, actually, because you're preventing legacy clients from taking advantage of them, which I think is a key feature of virtual mailboxes. I appreciate that some dumb clients download every message in every mailbox, but I fail to see the point of crippling the system to pander for clients that are badly written to begin with - you could equally well say that IMAP servers should hide more than 10 mailboxes. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 20:19:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlxON-0006ys-Gv; Thu, 01 Jun 2006 20:19:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlxOM-0006yn-P0 for lemonade@ietf.org; Thu, 01 Jun 2006 20:19:54 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlxOK-00082m-DI for lemonade@ietf.org; Thu, 01 Jun 2006 20:19:54 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M34A0DX6HS005I1G@mauve.mrochek.com> for lemonade@ietf.org; Thu, 1 Jun 2006 17:19:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1149207586; h=Date: From:Subject:MIME-version:Content-type; b=GYmSEWcyJ5f0B9j3PL5Bs7iVt onqB2+eO97NAjnrRHXOvPQ/TmswawmoMaPrgxpzIo8axbe8bzf2+i8MXlvt2A== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M303A101400049K2@mauve.mrochek.com>; Thu, 01 Jun 2006 17:19:45 -0700 (PDT) To: Arnt Gulbrandsen Message-id: <01M34A0CUMZC0049K2@mauve.mrochek.com> Date: Thu, 01 Jun 2006 17:16:35 -0700 (PDT) From: Ned Freed Subject: Re: [lemonade] COMPRESS Thoughts In-reply-to: "Your message dated Thu, 01 Jun 2006 12:30:33 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <330A23D8336C0346B5C1A5BB1966664702F6D036@ATLANTIS.Brooktrout.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Eric Burger writes: > > (4) Protocol allows for client to turn it on or off at will (not per > > body part, but point in time in session) > There's a performance gotcha to this, I realized while changing my > daughter's nappies at 6am this morning. > The compression library likes to read in big chunks. Everyone likes to > do I/O in big chunks. Reading network input one byte at a time is such > a performance drag. If the client tells the server that starting with > the next command, its commands are uncompressed, the server's > compression library has to stop reading at the right byte. It can't > simply read all it can eat. Ditto for responses. > This should fix it: > 1. The client cannot send any other commands until the server has sent a > tagged OK for the 'disable upstream compression' command. > 2. The server disables compression after sending the tagged OK for that > command (including the CRLF). > 3. The server cannot send any unsolicited responses after sending that > tagged OK and before receiving the next command. > The last introduces a new server mode and gets in the way of extending > IDLE... right now, I think that server mode is more trouble than it's > worth. > What is the problem if compression stays on once it's turned on? I can't > recall any relevant problems with STARTTLS, which behaves that way. The only problem I can recall hearing about leaving STARTTLS on comes up in news, not email. The situation there is that you may want to use TLS to protect the authentication exchange, but you really don't want to have it engaged while transferring gigabytes of data. In theory even this can be dealt with by negotiating a null cipher and integrity check (perhaps leaving compression on, come to think of it...), but nobody seemed entirely sure that such renegotiation mid-session would actually work. I see no equivalent issue in regard to compression in email in any case. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 21:48:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlymG-0002qD-K8; Thu, 01 Jun 2006 21:48:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlymF-0002pU-H5 for lemonade@ietf.org; Thu, 01 Jun 2006 21:48:39 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlymE-0000m2-Au for lemonade@ietf.org; Thu, 01 Jun 2006 21:48:39 -0400 X-IronPort-AV: i="4.05,200,1146456000"; d="scan'208"; a="33549111:sNHT46617628" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Draft Minutes, Interim Day 1 Date: Thu, 1 Jun 2006 21:49:33 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664702F6D9E2@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Draft Minutes, Interim Day 1 Thread-Index: AcaFgi6kb2CM9UdDTuaUnR0QP+/2/QASwGcQ From: "Burger, Eric" To: "Alexey Melnikov" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org What *is* the story with ENCRYPT and Profile-bis? -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: Thursday, June 01, 2006 9:47 AM To: Burger, Eric Cc: Enhancements to Internet email to support diverse serviceenivronments Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Burger, Eric wrote: [snip] >ENCRYPT >------- >Issue: Still not clear what the business / use case is for this feature. Needs to be clear and distinct. >Discussion: Classic industry problem: if we don't do it, someone less knowledgeable will do it. >Resolution: new draft coming. > =20 > But this is not going to be included in Lemonade Phase 2. (If my memory=20 doesn't fail me) [snip] _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 22:19:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlzG5-0003OU-VD; Thu, 01 Jun 2006 22:19:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlzG4-0003OL-4L for lemonade@ietf.org; Thu, 01 Jun 2006 22:19:28 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlzG2-00036S-SP for lemonade@ietf.org; Thu, 01 Jun 2006 22:19:28 -0400 X-IronPort-AV: i="4.05,200,1146456000"; d="scan'208"; a="33549948:sNHT39016116" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Draft Minutes, Interim Day 1 Date: Thu, 1 Jun 2006 22:19:25 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664702F6D9F3@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Draft Minutes, Interim Day 1 Thread-Index: AcaFzF6rS7Le/BjcQPKzLFH/1FYwZQAHkBTQ From: "Burger, Eric" To: "Enhancements to Internet email to support diverse service enivronments" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org [as participant] I was thinking about this further. If you have a legacy client, and that client implementation has a policy of "cache everything," would it be incorrect to assert that the client probably has decent bandwidth to the Internet and decent storage? I'm asserting this because such a policy is the opposite of the LEMONADE environment. I would offer that if you have multi-megabits of bandwidth and gigabytes of available storage, you could suffer to cache duplicates until such time you upgrade your client. Am I off base here? -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net]=20 Sent: Thursday, June 01, 2006 6:39 PM To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] Draft Minutes, Interim Day 1 On Thu Jun 1 19:23:41 2006, Randall Gellens wrote: >> Resolution: Allow VFOLDER only for lemonade clients for now. >=20 > How are legacy clients barred from SELECTing vfolders? They're not, but they're prevented from listing them without being=20 asked with special LIST-EXTENDED selection options. I think this is a mistake, actually, because you're preventing legacy=20 clients from taking advantage of them, which I think is a key feature=20 of virtual mailboxes. I appreciate that some dumb clients download every message in every=20 mailbox, but I fail to see the point of crippling the system to=20 pander for clients that are badly written to begin with - you could=20 equally well say that IMAP servers should hide more than 10 mailboxes. Dave. --=20 Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 22:20:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlzHV-00045c-6p; Thu, 01 Jun 2006 22:20:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlzHT-0003yA-Oi for lemonade@ietf.org; Thu, 01 Jun 2006 22:20:55 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlzHS-0003KX-0U for lemonade@ietf.org; Thu, 01 Jun 2006 22:20:55 -0400 X-IronPort-AV: i="4.05,200,1146456000"; d="scan'208"; a="33549984:sNHT39788760" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jun 2006 22:20:51 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664702F6D9F6@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Minutes, Both Days Thread-Index: AcaF6ytq6L2llHPhSRaKY6GPK6IRxA== From: "Burger, Eric" To: "Enhancements to Internet email to support diverse service enivronments" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4a4195ffb11c7b0baf82f77b2a730aa9 Subject: [lemonade] Draft Minutes, Both Days X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org [Corrections applied from list] Draft Minutes, lemonade Interim Meeting 65,5 31 May 2006 - 01 July 2006 Ottawa, ON, Canada Chairs: Eric Burger Glenn Parsons Attendees: Alexey Melnikov Arnt Gulbrandsen Ray Cromwell Dave Cridland Greg Vaudreuil Mike Parsel Ken Murchison Jerry Shih Stephane Maes Randy Gellens Jabber Logs 31 May 2006: http://www3.ietf.org/meetings/ietf-logs/lemonade/2006-05-31.html 01 June 2006: http://www3.ietf.org/meetings/ietf-logs/lemonade/2006-06-01.html Meeting Goal: Get updates to documents by 19 June 2006 in time for WGLC before or at IETF 66 in Montreal. Draft Discussions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RECONNECT --------- Issue: Do we need to mandate a minimum number of outstanding sessions a server must support? Discussion: Could make clients easier to implement if they knew that a server would have at least so many sessions available. Rejoinder: No matter what, another client can consume sessions, so the client must have code to deal with exhaustion of session resources. Thus there is no benefit of having a preset minimum number of sessions available for reconnect. Result: Be silent on a minimum number of sessions. Issue: Do we need server-side RECONNECT? Discussion: RECONNECT authors realized the tokens being passed to let the server know which session was being reconnected was identical to the state the server needed to know to re-establish state. Thus it is possible for the server to be stateless. This follows IETF practice of avoiding fate sharing. The client holds the state, and if the client fails, it doesn't care the state is lost, as it lost the state anyway. The proposal does not add any burden on clients, as the client needed to store the same information with the server-driven scheme. Rejoinder: Server-driven document is already written; do we want to delay? Result: Create new document centered around client-driven RECONNECT. It will be a work group document: draft-ietf-lemonade-reconnect-client; we are confident in its status as only about 2 paragraphs change. After the new draft is issued and the old draft is updated (there are some ABNF issues, etc. that need to be addressed), we will preferably chose one document and kill the other. Alternately, we will chose one, reference it in Profile-bis, and release the other as Experimental. Worst-case is both documents progress. IMAP URL (2192-bis) ------------------- Issue: Alexey needs Mark's input to decide what goes into 2192-bis versus URLAUTH. Resolution: Alexey will e-mail Mark directly. Issue: Alexey needs some help with sections talking about listing content of a server and mailbox naming scope.=20 Resolution: We volunteer Dave to help. Issue: Should 2192-bis include examples of extensions from BINARY, URLFETCH, imap-search-ret? Resolution: If those drafts are stable, then yes, otherwise, no. Alexey will send note to list if he doesn't get a response, then he will assume the drafts are not stable. CONVERT ------- Issue: ISO-8859-n has 16 values for n. Which one(s) do we mandate? Resolution: All of them (?). Clearly at least ISO-8859-1 (trivially easy) and ISO-8859-5 (in honor of Alexey) will be mandatory to implement. Issue: The original draft had a bunch of conversions that are now not mandatory. Resolution: Leave the text, but change RFC 2119 language from MUST/SHOULD to MAY. Note that OMA will impose relevant mandatory-to-implement conversions. We will ensure the protocol can handle them, but will not mandate any particular conversions outside of ISO-8859-n to UTF-8. COMPRESS -------- Note: There are some very interesting results discussed in the Jabber log , around the 12:20 time mark, about compression experiment results for TLS and compress=3Ddeflate. The short of it is that traffic with a moderate amount of attachments gets 70% compression using TLS; traffic with lots of attachments gets better compression with compress=3Ddeflate. Issue: How to disambiguate Content-Transfer-Encoding from Content-Type? Discussion: VPIM experience is the C-T-E is not well supported. One proposal is to use magic MIME types. Rejoinder: Only a C-T-E knowledgeable client will request compression from a C-T-E knowledgeable server. Moreover, using C-T-E is a correct protocol thing to do, as in "say what we mean." Reminder: The server is in the best position to decide whether or not to compress (if compression accepted by the client). The client-driven use case, where the client wants to save CPU at the expense of radio power, does not match the physics of the situation.=20 Discussion: Propose compress=3Ddeflate (draft-arnt-imap-deflate-02). Unquestionable desire to NOT have the mechanism be on a request-per-body-part basis. However, there is also a desire to have the mechanism be controllable (on or off) at client-requested point in the session. Discussion: Although deflate is the compression algorithm of gzip, and the proposed lemonade mechanism was called gzip, we are NOT discussing using gzip anymore. This means that the stream will not include the actual MIME type or file name (as would happen if we used the entire gzip structure). Discussion: Clear win for downstream (server->client) compression. However, compression could be a cost for upstream messages, as the protocol messages are often smaller than the PDU of the compressed block. Discussion: What, if in the middle of a transaction, the client says, "stop compressing"? That isn't a problem, because the IMAP transaction model says the current transaction completes. Resolution: Move compress out of convert document. Use compress=3Ddeflate. Ensure the method is controllable. Ensure the = method can be asymmetric (compress one way and not the other). Arnt is to be lead author. Special note: we will re-use the name draft-ietf-lemonade-compress-04, but the contents will be entirely deleted and the new content will substantially come from draft-arnt-imap-deflate-02. ENCRYPT ------- Issue: Still not clear what the business / use case is for this feature. Needs to be clear and distinct. Discussion: Classic industry problem: if we don't do it, someone less knowledgeable will do it. Resolution: new draft coming. WITHIN ------ Issue: Second recalculation is way too much of a server burden. Discussion: We are not trying to replicate instant messaging. Daily is enough. Hourly is OK. Discussion: We came up with a bunch of use cases which do need finer grain than hourly, e.g., transportation (your flight has been diverted) and military (invade Iraq if I don't hear from you for 15 minutes). Discussion: Can we let the client request whatever it wants (in minutes) and have the server reply with what it set it to? I.e., if a server does hourly, and I request 39 minutes, the server responds that it will do updates hourly; if a server does quarter-hourly, and I request 39 minutes, the server responds with 30 minutes or 45 minutes (up to the server to decide). Resolution: By minutes; need to think about letting the server do the granularity (need text). Issue: Should we give guidance on recomputing views? Resolution: Yes, put in an informative section into the document. VFOLDER ------- Issue: Anonymous users creating VFOLDERs can be a DoS attack. Resolution: Anonymous users cannot create a VFOLDER, but they can read them. Issue: Legacy clients might duplicate messages since they don't know the messages are virtual. Reminder: In Dallas (and on the list) we said that only lemonade clients could use VFOLDERs. Discussion: Would be very useful for legacy clients to see VFOLDERs. Resolution: Allow VFOLDER only for lemonade clients for now. Issue: What happens if one renames a folder a VFOLDER depends on? Discussion: Original proposal is to delete the VFOLDER. Rejoinder: That would be a customer service nightmare, "All of my folders disappeared?!?!" Resolution: VFOLDER calculations get updated when one renames an underlying mailbox. Issue: What happens if one deletes a folder a VFOLDER depends on? Discussion: Choice is to immediately delete the dependent VFOLDERs, keep the VFOLDERs around until the next status/select/examine, or make the VFOLDER real. Arnt's implementation today immediately deletes the dependent VFOLDERs. Issue: What about Append/Copy support for VFOLDER? The current draft says "maybe". =20 Discussion: Alexey proposed saying "yes" unless not possible. Arnt said that some clients expect a message to be there if they put it in the folder. If it isn't there, the client may retry. If it is the View that keeps the message away, the repost will always fail (causing the client to loop). Rejoinder: The scenario of a message never getting posted can happen today. One client can post a message while another expunges it. Answer to that is that while it could happen, it is not likely to occur repetitively. Issue: The server should be able to reject expensive or complex VFOLDER calculations. Discussion: This could cause a user interface problem if the creation of the VFOLDER is hard-coded in the client. That is, the user does not know they are requesting the creation of a VFOLDER. Thus they get a surprise when they get an error messaging saying the VFOLDER they didn't know they were creating failed to be created. Rejoinder: In a sense, this is a client implementation failure, and the user will sensibly force the provider to fix the client. Discussion: The impetus for the question is that it is thought that some servers may not implement dynamic attributes for VFOLDER. Further discussion indicated that if you do VFOLDER and CONDSTORE, you pretty much have already done dynamic attributes. Resolution: Consensus is that if one does VFOLDER, one must do Dynamic Attrributes. Issue: There are two use cases for VFOLDER. One is as a notification mechanism (setup a VFOLDER to filter messages of interest and then report on the state of that VFOLDER). The other is as a mailbox management mechanism (I get thousands of messages per day or I have a ton of messages in my folder, and I want to have only a small subset on my client). Should we have two mechanisms? Discussion: It is true that the former use case demands dynamic attributes while the second may be able to get by with static attributes. However, the use cases are too close together, and the user interface would be too complicated, to split the functionality. Resolution: We just have VFOLDER, and it requires support of dynamic attributes. Issue: Can we have a VFOLDER that is the set of messages that are not selected by any other VFOLDER? Resolution: Submit text. Issue: When does a VFOLDER recomputed its contents? Discussion: Clearly when a new message arrives. What about on any IMAP command? on IMAP commands the mutate state? only on SELECT? by time interval? Resolution: "In a timely manner" [I'd like to see text] NOTIFICATIONS ------------- Note: Ray extended EMN for lemonade needs; will fold back in to official EMN definition in OMA. Issue: MSGEVENTS draft expired Discussion: It is critically important for the set of events to be reviewed for completeness. Resolution: Chris to resubmit; WG to review. NEED VOLUNTEERS TO REVIEW. Issue: MSGEVENTS are not extendable Discussion: We cannot anticipate future extensions to IMAP, nor can we be sure we have covered everything today. Also, there is a legitimate business need for proprietary extensions for use in proprietary environments. Resolution: Ray will investigate creating an extensible mechanism for notification events. Special Note: We will make clear that this mechanism for proprietary extensions MUST make it explicit what kind of notifications are acceptable to go over the wire with this mechanism. In particular, we are talking about stuff we don't care if it gets lost or where a duplicate delivery doesn't harm anything. I think that like the Pork example in the Torah, we should explicitly call out LOCKDOWN as a message that is wholly inappropriate for this mechanism and MUST NOT be sent as an extension message. LOCKDOWN, purge all messages, purge your cache, et al. are all messages that fall into the category of "do not use notifications." Issue: We had two mechanisms, out-of-band (oob) and in-band (ib) for notifications. However, it can be very difficult to decide if a user is actually connected. Discussion: Don't want to have multiple code paths, especially if the choice to go ib can turn out to be wrong. On the other hand, the technology of ib (use TCP) and oob (use, e.g., SMS), can have very different cost profiles. Discussion: Independent of message state, it can be useful to have both mechanisms. Resolution: We will split NOTIFICATIONS into two drafts, on ib and one oob. Alexey will write the ib draft. New draft must be done by June 19. Issue: Server-to-Server (S2S) text in draft does not bind the messages to a transport protocol. Is this OK? Discussion: Might not want to make a binding, so the server can natively interface with SIMPLE Server, XMPP Server, SMSC, MMSC, etc. Rejoinder: Some folks do not care about mobile notifications and even if they do they do not want to have to implement a bunch of notification server protocols. Resolution: We will choose a single transport binding. Stephane will provide text in next revision of NOTIFICATIONS draft, due June 19. Issue: Should lemonade S2S document be explicitly limited to lemonade / messaging environments? Discussion: Do not want to boil the ocean - generic notifications are a BIG computer science problem. Moreover, the whole reason for having a lemonade S2S document is for the purposes of having a baseline, easy-to-implement protocol for lemonade servers to use. Resolution: Randy and Stephane will provide appropriate text, by June 19. DEPLOYMENTS ----------- Issue: Dave was going to supply figures for reconnection costs. Resolution: Dave WILL supply figures for reconnection costs. Issue: Current draft references Profile-bis and NOTIFICATIONS Discussion: They will hold up publication. Discussion: What about TCP-Challenged Environments? Resolution: Drop NOTIFICATIONS, don't reference TCP-Challenged, and reference Profile. Put them back when we do DEPLOYMENTS-bis. Update by June 9. The document will be ready for WGLC at that point. Reminder: We are publishing this as a BCP. TCP-CHALLENGED ENVIRONMENTS --------------------------- Issue: So we are not circumventing firewall policy, HTTP PDUs will have a header to indicate the payload is really a mobile message. Current draft uses X-HTTP-Binding. Resolution: Use something descriptive, like HTTP-Mobile-Email and do not use X-. Issue: The draft enumerates five different approaches to making lemonade work in environments without TCP. Should we choose one? Discussion: While HTTP tunneling provides 100% of the lemonade functionality, HTTP tunneling will not work in all TCP-challenged environments. REST will work in all TCP-challenged environments, but will not provide 100% of lemonade functionality. Resolution: Mandate REST. Not providing 100% of lemonade functionality is a feature, not a bug. Using REST allows lemonade to work in all environments, including high-value environments like satellite e-mail. In addition, not providing 100% of lemonade functionality gives operators that are TCP-challenged an incentive to properly implement their network. Note: We will keep the text for the other methods, to explain why we are not using them. Note: Ray to review how XMPP specifies operation over TCP and fall-back to HTTP. [References to this are in the Jabber logs (pardon the irony).] Chair's note: Ensure there is NO normative language in any of the text for the other methods, and move them to appendices. Make it clear that REST is the only approved (and specified) method available. STREAMING --------- Issue: How to do VCR controls (fast-forward, rewind, speed-up, slow-down, pause)? Discussion: MSCML and MSML have the bulk of the market. This problem is being examined informally by the mediactrl interest group (see ). RAI (TSV, historically) didn't have pressure to examine this work. MSCML is on RFC Editor Queue. Resolution: We will press RAI to solve this issue for us, as it is a SIP control thing. Our document will not reference VCR controls. Issue: Server location is important. Discussion: Neil is working on a proposal. Resolution: Neil's text will go into Profile-bis. PROFILE-BIS ----------- Editorial: Need to update bis to reflect decisions on compression, encryption, and reconnect. Issue: What about streaming? Is it mandatory to implement? Discussion: Streaming is purely a client issue. Server only needs to support URLAUTH and URLFETCH. Resolution: Remove streaming appendix from bis and reference streaming draft. OMA LIAISON =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Document Progress ----------------- We will tell OMA about our progress by enumerating RFC's published and documents in or about to be in WGLC or IETF LC. LC documents include FUTUREDELIVERY, CONVERT, WITHIN, METADATA (ANNOTATEMORE), ESEARCH, and deployment issues. We will not include RECONNECT, as we need to nail down server-side versus client-side state storage first. Interoperability Testing ------------------------ Reasons for Interop: Marketing Moving to IETF Draft standard Compliance Input to OMA IOP We will focus on #2 and help on #4. Plan is to have the following interoperability events: A Private Interop Event (under NDA). Participants: Developers (only) Venue Requirements: Close to the most developers / travel constrained developers; excellent Internet connectivity, as some developers will participate remotely or their servers may be remote Location: UK Dates: October 23-27 [tentative] Goal: Get working implementations of lemonade suite. Prove accuracy / viability of IETF I-D's before RFC publication and moving to IETF Draft Standard from Proposed standard. Results will NOT be published, to encourage folks with alpha code and prototypes. A Market-Focused Interop Event, Highlighting Lemonade Interoperability. Participants: Field Folks Venue Requirements: High visibility venue that will generate customer and press buzz. Location: Telecom 2006, Hong Kong Dates: December (first week?) A Market-Focused Interop Event, Highlighting Mobile Messaging Paricipants: Field Folks Venue Requirements: High visibility venue that is mobile-oriented that will generate customer and press buzz. Location: 3GSM, Barcelona Dates: February 12 - 17, 2007 (?) To make the marketing events happen, we need outside coordinator. Stephane volunteered EIMG group. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 01 22:52:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flzlq-0005NI-4L; Thu, 01 Jun 2006 22:52:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flzlo-0005L0-N5 for lemonade@ietf.org; Thu, 01 Jun 2006 22:52:16 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flzll-0000Oe-EL for lemonade@ietf.org; Thu, 01 Jun 2006 22:52:16 -0400 X-IronPort-AV: i="4.05,200,1146456000"; d="scan'208"; a="33550744:sNHT31105844" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jun 2006 22:52:11 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664702F6D9F9@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your Moment of Glory Thread-Index: AcaF74u06Zu6WoBcRbG7WaQEG3rkhg== From: "Burger, Eric" To: "Enhancements to Internet email to support diverse service enivronments" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Glenn Parsons Subject: [lemonade] Your Moment of Glory X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Did you ever want to get your name into an RFC? Are you new to lemonade? Are you one of our 211 lurkers, waiting for the opportunity to contribute to the community, but were afraid to ask? Well, here is your opportunity! We are about to put a number of documents through Work Group Last Call. There are a number of mechanical checks and write-ups that need to be done to get these documents through IESG review and into the RFC Editor Queue. We need volunteers to take on these tasks. In return, we (as Chairs) will make sure you get your name, in print, in a real, live RFC, in the Acknowledgements section. You do NOT have to be a lemonade expert or existing document author to be successful in these tasks! This is an excellent way for someone to "learn the ropes." I can guarantee that once you complete these tasks, your documents will improve dramatically. We are looking for one volunteer per document. The tasks are: 1. Run the nits checker on the document http://tools.ietf.org/tools/idnits/ 2. Run an ABNF checker on the ABNF in the document (if any) http://rtg.ietf.org/~fenner/abnf.cgi 3. Troll the mail list and meeting minutes for open issues (if any) http://www1.ietf.org/mail-archive/web/lemonade/current/index.html (if you don't have an archive on your machine already) 4. Send the results of the nits checker and ABNF checker to the draft author. Of course, the draft author will do this herself before submitting the draft, so there should be no problems :) 5. Keep track of open issues and whether they have been solved or are declared unsolvable. You don't need to be an expert - you can trust the document authors. 6. When asked, do a write-up, summarizing any open issues or issues that were contentious (you'll know if they were contentious if there are lots (>20) messages on the topic). Please send your willingness to volunteer to the Chairs, Eric Burger and Glenn Parsons.=20 Thanks! _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 03:28:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm450-0002Ir-Hq; Fri, 02 Jun 2006 03:28:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm44z-0002Ih-Sd for lemonade@ietf.org; Fri, 02 Jun 2006 03:28:21 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm44y-0002Bl-Dk for lemonade@ietf.org; Fri, 02 Jun 2006 03:28:21 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k527SILG022620 for ; Fri, 2 Jun 2006 10:28:19 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 10:28:19 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 10:28:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [lemonade] Question on 'Sent Items' deposit Date: Fri, 2 Jun 2006 10:28:05 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446572BBB09@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Question on 'Sent Items' deposit Thread-Index: AcaGFhbFwUpkl/XdRWObFghp1XgOFw== From: To: X-OriginalArrivalTime: 02 Jun 2006 07:28:19.0054 (UTC) FILETIME=[1EC928E0:01C68616] X-Spam-Score: 0.3 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1120796500==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1120796500== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68616.1EDB965F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68616.1EDB965F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, It a is a usual practice to place a copy of a sent email (new, replied, = forwarded) to a special store typically called "Sent items"/"Sent mail" I understand that this is not done automatically - or perhaps I missed = some draft(?) - and it is the client's responsibility to create and = desposit the copy. I recon this is not a problem for a fixed terminal. = However, when I send something from a mobile terminal, I would not want = to upload it twice (once to SUBMIT server and again to the IMAP server). Does LEMONADE provide a mechanism to make sure that we do not need to = upload an email twice? If yes, which draft describes it, if not, I think it should be added. Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh at nokia.com Phone: +358 50 386 0566 ------_=_NextPart_001_01C68616.1EDB965F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [lemonade] Question on 'Sent Items' deposit

Hi all,
It a is a usual practice to = place a copy of a sent email (new, replied, forwarded) to a special = store typically called "Sent items"/"Sent = mail"

I understand that this is not = done automatically - or perhaps I missed some draft(?) - and it is the = client's responsibility to create and desposit the copy. I recon this is = not a problem for a fixed terminal. However, when I send something from = a mobile terminal, I would not want to upload it twice (once to SUBMIT = server and again to the IMAP server).

Does LEMONADE provide a = mechanism to make sure that we do not need to upload an email = twice?
If yes, which draft = describes it, if not, I think it should be added.
Thank You.

Best regards: Zolt=E1n = =D6rd=F6gh
E-mail: zoltan.ordogh at nokia.com
Phone: = +358 50 386 = 0566


------_=_NextPart_001_01C68616.1EDB965F-- --===============1120796500== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============1120796500==-- From lemonade-bounces@ietf.org Fri Jun 02 06:09:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm6bI-0004ey-5H; Fri, 02 Jun 2006 06:09:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm6bH-0004et-NE for lemonade@ietf.org; Fri, 02 Jun 2006 06:09:51 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm6bE-00023Y-6o for lemonade@ietf.org; Fri, 02 Jun 2006 06:09:51 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id ED8C94AC4B for ; Fri, 2 Jun 2006 12:09:46 +0200 (CEST) Message-Id: Date: Fri, 2 Jun 2006 12:10:27 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [Lemonade] Discussion items from thsimorning on VFOLDER and WITHIN References: <20060601070749343.00000000428@smaes-lap3> <72FDD20C56FDCB399E7AAF41@Cyrus-Daboo.local> In-Reply-To: <72FDD20C56FDCB399E7AAF41@Cyrus-Daboo.local> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Cyrus Daboo writes: > I think THIS version of VFOLDER should provide such a mechanism. A new > OUID fetch parameter that returns a relative imap url with the > mailbox, uidvalidty and uid of the underlying message would be one > simple solution. The other would be a more general GUID mechanism - > but that may be going too far... I considered those, and concluded that it was likely to add more downstream traffic than it saves. URLs are big, and there are many GUIDs because they have to be sent in all mailboxes, not just vfolders, so there's a lot of bytes that have to be saved to come out ahead. A third solution, which I thought of only when I read your message, is to add a new SELECT response with the backing mailbox and uidvalidity * OK [BACKINGMAILBOX mailbox nz-number] if you hafta ask... and a new FETCH OUID to retrieve just the UID in that mailbox. That saves traffic if the client saves just 1% of the (body[header.fields(...)] body[1]) fetches, perhaps even if it saves 0.1%. For a client which issues FETCH OUID, that's not a bad bet. Of course, this is troublesome wrt. vfolder-on-vfolder and also wrt. multi-mailbox vfolders. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 06:13:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm6ej-0006Px-OZ; Fri, 02 Jun 2006 06:13:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm6ei-0006Ps-EH for lemonade@ietf.org; Fri, 02 Jun 2006 06:13:24 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm6eg-0002sf-Vm for lemonade@ietf.org; Fri, 02 Jun 2006 06:13:24 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id F2DC14AC4B; Fri, 2 Jun 2006 12:13:21 +0200 (CEST) Message-Id: Date: Fri, 2 Jun 2006 12:14:03 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Draft Minutes, Interim Day 1 References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> In-Reply-To: <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King writes: > If we are going to-do this then why keep the mailbox framework? > VFOLDER currently has a number of show stoppers already: > > 1. duplicate messages. I don't see that as a show stopper. It's the kind of thing developers worry about, that's all. > 2. message going into and out of focus. Also not a show stopper. It happens seldom, so we can afford to be waste bytes when it happens. It's just that we can't break the protocol when it happens. > 3. UID issues caused by 1 and 2. > 4. Do you delete messages when you delete the VFOLDER? According to > the draft it is supposed to behave like a real mailbox. When a message is in several mailboxes and you delete one mailbox (a real one or a vfolder), the message does not disappear from other mailboxes. > Why not have filters you can apply to mailbox? People want their current-day clients to be able to read the vfolder. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 06:32:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm6xW-0004jb-1E; Fri, 02 Jun 2006 06:32:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm6xV-0004jW-6C for lemonade@ietf.org; Fri, 02 Jun 2006 06:32:49 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm6xT-000519-PB for lemonade@ietf.org; Fri, 02 Jun 2006 06:32:49 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 3C6634AC4B for ; Fri, 2 Jun 2006 12:32:46 +0200 (CEST) Message-Id: Date: Fri, 2 Jun 2006 12:33:27 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Draft Minutes, Interim Day 1 References: <330A23D8336C0346B5C1A5BB1966664702F6D9F3@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702F6D9F3@ATLANTIS.Brooktrout.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Burger writes: > I was thinking about this further. If you have a legacy client, and > that client implementation has a policy of "cache everything," would > it be incorrect to assert that the client probably has decent > bandwidth to the Internet and decent storage? No. Decent storage, yes, but not bandwidth. Consider a device such as the latest Sony Vaio, with a 200GB disk and built-in GPRS (if that's not the latest model, surely it is the next one). The most sensible strategy for such a device is to use oodles of disk and minimize GPRS use. There are existing IMAP clients that follow this strategy. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 06:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm7Dz-0004sw-TV; Fri, 02 Jun 2006 06:49:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm7Dz-0004sr-9d for lemonade@ietf.org; Fri, 02 Jun 2006 06:49:51 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm7Dw-0007zB-SS for lemonade@ietf.org; Fri, 02 Jun 2006 06:49:51 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 2 Jun 2006 11:49:44 +0100 Message-ID: <44801795.1030104@isode.com> Date: Fri, 02 Jun 2006 11:48:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Burger, Eric" Subject: Re: [lemonade] Draft Minutes, Interim Day 1 References: <330A23D8336C0346B5C1A5BB1966664702F6D9E2@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702F6D9E2@ATLANTIS.Brooktrout.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Burger, Eric wrote: >What *is* the story with ENCRYPT and Profile-bis? > > I thought we've decided that this is going to be a WG document, but will not be included in Profile bis. >-----Original Message----- >From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] >Sent: Thursday, June 01, 2006 9:47 AM >To: Burger, Eric >Cc: Enhancements to Internet email to support diverse >serviceenivronments >Subject: Re: [lemonade] Draft Minutes, Interim Day 1 > >Burger, Eric wrote: > >[snip] > > > >>ENCRYPT >>------- >>Issue: Still not clear what the business / use case is for this >> >> >feature. Needs to be clear and distinct. > > >>Discussion: Classic industry problem: if we don't do it, someone less >> >> >knowledgeable will do it. > > >>Resolution: new draft coming. >> >> >But this is not going to be included in Lemonade Phase 2. (If my memory >doesn't fail me) >[snip] > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 07:34:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm7vV-0006Z9-0M; Fri, 02 Jun 2006 07:34:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm7vT-0006Z4-9k for lemonade@ietf.org; Fri, 02 Jun 2006 07:34:47 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm7vR-0002G7-Ru for lemonade@ietf.org; Fri, 02 Jun 2006 07:34:47 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 2 Jun 2006 12:34:44 +0100 Message-ID: <4480221F.1050300@isode.com> Date: Fri, 02 Jun 2006 12:33:51 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] Question on 'Sent Items' deposit References: <0FA975F2D8295A448BE3ADC1612446572BBB09@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC1612446572BBB09@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan.Ordogh@nokia.com wrote: > Hi all, > Hi Zoltan, > It a is a usual practice to place a copy of a sent email (new, > replied, forwarded) to a special store typically called "Sent > items"/"Sent mail" > > I understand that this is not done automatically - or perhaps I missed > some draft(?) - and it is the client's responsibility to create and > desposit the copy. I recon this is not a problem for a fixed terminal. > However, when I send something from a mobile terminal, I would not > want to upload it twice (once to SUBMIT server and again to the IMAP > server). > The client uses IMAP CATENATE extension (RFC 4469) to construct a complete message in the "Sent mail" mailbox, then the client generates a signed URL pointing to the constructed message using IMAP URLAUTH extension (RFC 4467) and finally the client submits the message using SMTP BURL extension (RFC 4468). This is described in the Lemonade Profile document (draft-ietf-lemonade-profile-07.txt, that would become an RFC really soon now). So the client will create a message to be submitted directly in the "Sent mail" mailbox, so it wouldn't have to upload the same message twice to the Submit server and to the IMAP server. > Does LEMONADE provide a mechanism to make sure that we do not need to > upload an email twice? > If yes, which draft describes it, if not, I think it should be added. > Thank You. > *Alexey * _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 07:39:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm80D-0005nm-MA; Fri, 02 Jun 2006 07:39:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm80C-0005nh-Gx for lemonade@ietf.org; Fri, 02 Jun 2006 07:39:40 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm80B-0002TM-3P for lemonade@ietf.org; Fri, 02 Jun 2006 07:39:40 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1Fm80A-0003mM-91; Fri, 02 Jun 2006 11:39:38 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 3F736498008; Fri, 2 Jun 2006 12:43:19 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06357-07; Fri, 2 Jun 2006 12:43:09 +0100 (BST) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:a1c9:c566:9a2a:6cb0]) by turner.dave.cridland.net (Postfix) with ESMTP id 02FF1498007; Fri, 2 Jun 2006 12:43:07 +0100 (BST) Date: Fri, 02 Jun 2006 12:41:23 +0100 Subject: Re: [lemonade] Question on 'Sent Items' deposit References: <0FA975F2D8295A448BE3ADC1612446572BBB09@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC1612446572BBB09@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <2880.1149248485.157000@JOHN> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri Jun 02 08:28:05 2006, Zoltan.Ordogh@nokia.com wrote: > Hi all, > It a is a usual practice to place a copy of a sent email (new, > replied, forwarded) to a special store typically called "Sent > items"/"Sent mail" I tend to put them in INBOX, in fact, but the practise of a specific mailbox for copies of sent messages is common. > I understand that this is not done automatically - or perhaps I > missed some draft(?) - and it is the client's responsibility to > create and desposit the copy. I recon this is not a problem for a > fixed terminal. However, when I send something from a mobile > terminal, I would not want to upload it twice (once to SUBMIT > server and again to the IMAP server). > Does LEMONADE provide a mechanism to make sure that we do not need > to upload an email twice? Yes, and we do - you upload the copy (via APPEND, possibly using CATENATE to assemble), and then send by using a single BURL/URLAUTH pair. There's an alternate method, which uses POSTADDRESS, which isn't currently part of Lemonade. (Perhaps it should be?) This is covered in section 2.7 of Profile Bis (and probably of Profile, too). I might alter the title if it makes this easier to find. Incidentally, usage of these mechanisms can be sensible over DSL links, since usage-based billing is increasingly common. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 07:46:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm86x-0003BW-Kl; Fri, 02 Jun 2006 07:46:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm86w-0003BR-Ad for lemonade@ietf.org; Fri, 02 Jun 2006 07:46:38 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm86t-00039K-QS for lemonade@ietf.org; Fri, 02 Jun 2006 07:46:38 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k52BkWxQ003955 for ; Fri, 2 Jun 2006 14:46:34 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 14:46:31 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 14:45:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Question on 'Sent Items' deposit Date: Fri, 2 Jun 2006 14:45:49 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446572BBED9@esebe199.NOE.Nokia.com> In-Reply-To: <2880.1149248485.157000@JOHN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Question on 'Sent Items' deposit Thread-Index: AcaGOX26eDmOXYJTT42EmbVRW5XddQAAGOGg From: To: X-OriginalArrivalTime: 02 Jun 2006 11:45:49.0769 (UTC) FILETIME=[18212B90:01C6863A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org So this guy is saying what we discussed yesterday. When sending an email you put it to the sent items and the Submmit the URL with BURL. We have to ask our engineers about this kind of behavior. Cat >-----Original Message----- >From: ext Dave Cridland [mailto:dave@cridland.net]=20 >Sent: 02 June, 2006 14:41 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) >Cc: Enhancements to Internet email to support diverse service=20 >enivronments >Subject: Re: [lemonade] Question on 'Sent Items' deposit > >On Fri Jun 02 08:28:05 2006, Zoltan.Ordogh@nokia.com wrote: >> Hi all, >> It a is a usual practice to place a copy of a sent email (new,=20 >> replied, forwarded) to a special store typically called "Sent=20 >> items"/"Sent mail" > >I tend to put them in INBOX, in fact, but the practise of a=20 >specific mailbox for copies of sent messages is common. > > >> I understand that this is not done automatically - or perhaps I=20 >> missed some draft(?) - and it is the client's responsibility to=20 >> create and desposit the copy. I recon this is not a problem for a=20 >> fixed terminal. However, when I send something from a mobile=20 >> terminal, I would not want to upload it twice (once to SUBMIT=20 >> server and again to the IMAP server). >> Does LEMONADE provide a mechanism to make sure that we do not need=20 >> to upload an email twice? > >Yes, and we do - you upload the copy (via APPEND, possibly using=20 >CATENATE to assemble), and then send by using a single BURL/URLAUTH=20 >pair. > >There's an alternate method, which uses POSTADDRESS, which isn't=20 >currently part of Lemonade. (Perhaps it should be?) > >This is covered in section 2.7 of Profile Bis (and probably of=20 >Profile, too). I might alter the title if it makes this easier to=20 >find. > >Incidentally, usage of these mechanisms can be sensible over DSL=20 >links, since usage-based billing is increasingly common. > >Dave. >--=20 >Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ >Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 09:23:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9co-0002CV-Ox; Fri, 02 Jun 2006 09:23:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9cn-0002CQ-FQ for lemonade@ietf.org; Fri, 02 Jun 2006 09:23:37 -0400 Received: from out3.smtp.messagingengine.com ([66.111.4.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm9cm-0005YQ-5X for lemonade@ietf.org; Fri, 02 Jun 2006 09:23:37 -0400 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 172A4D69396; Fri, 2 Jun 2006 09:23:35 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Fri, 02 Jun 2006 09:23:36 -0400 X-Sasl-enc: Ay7CI8LmCxL6uO0KS5wR8lbUDKYLeENWb0zN6LF41VJg 1149254616 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 182778101; Fri, 2 Jun 2006 09:23:32 -0400 (EDT) Date: Fri, 02 Jun 2006 09:23:29 -0400 From: Cyrus Daboo To: Arnt Gulbrandsen , lemonade@ietf.org Subject: Re: [Lemonade] Discussion items from thsimorning on VFOLDER and WITHIN Message-ID: <29C68D773C6A73BB2A0FCC48@Cyrus-Daboo.local> In-Reply-To: References: <20060601070749343.00000000428@smaes-lap3> <72FDD20C56FDCB399E7AAF41@Cyrus-Daboo.local> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Arnt, --On June 2, 2006 12:10:27 PM +0200 Arnt Gulbrandsen wrote: >> I think THIS version of VFOLDER should provide such a mechanism. A new >> OUID fetch parameter that returns a relative imap url with the >> mailbox, uidvalidty and uid of the underlying message would be one >> simple solution. The other would be a more general GUID mechanism - >> but that may be going too far... > > I considered those, and concluded that it was likely to add more > downstream traffic than it saves. URLs are big, and there are many GUIDs > because they have to be sent in all mailboxes, not just vfolders, so > there's a lot of bytes that have to be saved to come out ahead. URLs have the advantage of only being needed in the vfolders and the client can use other sync methods to only fetch those for messages known to have changed or been added (i.e. it does not have to be part of the 'normal' fetch operations). You proposed shortcut below of sending the backing mailbox uidvalidity at select time would help cut down the length too. > A third solution, which I thought of only when I read your message, is to > add a new SELECT response with the backing mailbox and uidvalidity > > * OK [BACKINGMAILBOX mailbox nz-number] if you hafta ask... > > and a new FETCH OUID to retrieve just the UID in that mailbox. > > That saves traffic if the client saves just 1% of the > (body[header.fields(...)] body[1]) fetches, perhaps even if it saves > 0.1%. For a client which issues FETCH OUID, that's not a bad bet. > > Of course, this is troublesome wrt. vfolder-on-vfolder and also wrt. > multi-mailbox vfolders. OUID could return just the UID in the case of a single backing mailboxes, and in the case of multiple backing mailboxes, an alias for the mailbox name and the UID. The mailbox name could be given a short alias by the server and that could be included in the select response, then an even more compact form used: * OK [BACKINGMAILBOX INBOX 12345 A] if you hafta ask... * OK [BACKINGMAILBOX INBOX/sent-items 54321 B] if you hafta ask... * OK [BACKINGMAILBOX INBOX/read-items 20606 C] if you hafta ask... ... a FETCH 1:3 OUID * FETCH OUID A:123 * FETCH OUID B:22 * FETCH OUID C:5432 etc -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 09:28:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9hC-0000TG-Sy; Fri, 02 Jun 2006 09:28:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9hB-0000T9-Ho for lemonade@ietf.org; Fri, 02 Jun 2006 09:28:09 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm9hA-0006Dx-76 for lemonade@ietf.org; Fri, 02 Jun 2006 09:28:09 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k52DRw415067; Fri, 2 Jun 2006 09:27:58 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Draft Minutes, Interim Day 1 Date: Fri, 2 Jun 2006 09:27:51 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0A5FCC04@zcarhxm0.corp.nortel.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702F6D9E2@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Draft Minutes, Interim Day 1 Thread-Index: AcaFgi6kb2CM9UdDTuaUnR0QP+/2/QASwGcQAB6kGgA= From: "Glenn Parsons" To: "Burger, Eric" , "Alexey Melnikov" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org There is no consensus to include encryption in Profile bis yet. =20 And to that point we need more details on the use case that can be used to prove why it should be. However, once we understand the use case we might decide that this would be more suitable to the MEM TS instead of Profile-bis. The new draft is actioned to provide that use case. Glenn. -----Original Message----- From: Burger, Eric [mailto:eburger@cantata.com]=20 Sent: Thursday, June 01, 2006 9:50 PM To: Alexey Melnikov Cc: Enhancements to Internet email to support diverse serviceenivronments Subject: RE: [lemonade] Draft Minutes, Interim Day 1 What *is* the story with ENCRYPT and Profile-bis? -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] Sent: Thursday, June 01, 2006 9:47 AM To: Burger, Eric Cc: Enhancements to Internet email to support diverse serviceenivronments Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Burger, Eric wrote: [snip] >ENCRYPT >------- >Issue: Still not clear what the business / use case is for this feature. Needs to be clear and distinct. >Discussion: Classic industry problem: if we don't do it, someone less knowledgeable will do it. >Resolution: new draft coming. > =20 > But this is not going to be included in Lemonade Phase 2. (If my memory doesn't fail me) [snip] _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 11:34:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBfY-0006QK-Sx; Fri, 02 Jun 2006 11:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBfX-0006QF-SS for lemonade@ietf.org; Fri, 02 Jun 2006 11:34:35 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmBfU-0000l3-Gi for lemonade@ietf.org; Fri, 02 Jun 2006 11:34:35 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 048B2272B4; Fri, 2 Jun 2006 09:34:32 -0600 (MDT) In-Reply-To: References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Date: Fri, 2 Jun 2006 09:34:31 -0600 To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: lemonade@ietf.org, Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 2-Jun-06, at 4:14 AM, Arnt Gulbrandsen wrote: > Curtis King writes: >> If we are going to-do this then why keep the mailbox framework? >> VFOLDER currently has a number of show stoppers already: >> >> 1. duplicate messages. > > I don't see that as a show stopper. It's the kind of thing > developers worry about, that's all. > >> 2. message going into and out of focus. > > Also not a show stopper. It happens seldom, so we can afford to be > waste bytes when it happens. It's just that we can't break the > protocol when it happens. As one who implements these drafts, this is a pain. Tracking UID and assigning new UID when a message comes back into focus means you have to assign message new UID for each message in a VFOLDER. Not a very virtual folder to me. > >> 3. UID issues caused by 1 and 2. More hand waving here ;) >> 4. Do you delete messages when you delete the VFOLDER? According >> to the draft it is supposed to behave like a real mailbox. > > When a message is in several mailboxes and you delete one mailbox > (a real one or a vfolder), the message does not disappear from > other mailboxes. Why not? Wouldn't that be something an end user might want to-do? This means messages in a vfolder need a reference count. Once again this isn't very virtual from the server perspective. > >> Why not have filters you can apply to mailbox? > > People want their current-day clients to be able to read the vfolder. I agree, but this has been decided in the meeting: Issue: Legacy clients might duplicate messages since they don't know the messages are virtual. Reminder: In Dallas (and on the list) we said that only lemonade clients could use VFOLDERs. Discussion: Would be very useful for legacy clients to see VFOLDERs. Resolution: Allow VFOLDER only for lemonade clients for now. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 12:12:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCG6-00029t-9f; Fri, 02 Jun 2006 12:12:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCG5-0001yo-24 for lemonade@ietf.org; Fri, 02 Jun 2006 12:12:21 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmCG3-0006Lj-Oi for lemonade@ietf.org; Fri, 02 Jun 2006 12:12:21 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FmCG3-0004cn-04; Fri, 02 Jun 2006 16:12:19 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id E5BF4498007; Fri, 2 Jun 2006 17:16:01 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08974-04; Fri, 2 Jun 2006 17:15:53 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 378D2498006; Fri, 2 Jun 2006 17:15:53 +0100 (BST) Date: Fri, 02 Jun 2006 17:12:09 +0100 Subject: Re: [Lemonade] Discussion items from thsimorning on VFOLDER and WITHIN References: <20060601070749343.00000000428@smaes-lap3> <72FDD20C56FDCB399E7AAF41@Cyrus-Daboo.local> <29C68D773C6A73BB2A0FCC48@Cyrus-Daboo.local> In-Reply-To: <29C68D773C6A73BB2A0FCC48@Cyrus-Daboo.local> MIME-Version: 1.0 Message-Id: <6226.1149264729.702413@peirce.dave.cridland.net> From: Dave Cridland To: Cyrus Daboo Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri Jun 2 14:23:29 2006, Cyrus Daboo wrote: > OUID could return just the UID in the case of a single backing > mailboxes, and in the case of multiple backing mailboxes, an alias > for the mailbox name and the UID. The mailbox name could be given a > short alias by the server and that could be included in the select > response, then an even more compact form used: > > I suspect you'd find this compressed to a similar length to the relative URL. After all, you're just doing a backreference, in effect. It might even compress worse, because of the extra framing used. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 12:18:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCLy-00048q-Mn; Fri, 02 Jun 2006 12:18:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCLx-00046R-S8 for lemonade@ietf.org; Fri, 02 Jun 2006 12:18:25 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmCLw-0006v0-Ck for lemonade@ietf.org; Fri, 02 Jun 2006 12:18:25 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 458F14AC7E; Fri, 2 Jun 2006 18:18:23 +0200 (CEST) Message-Id: Date: Fri, 2 Jun 2006 18:19:05 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Draft Minutes, Interim Day 1 References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> In-Reply-To: <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King writes: > On 2-Jun-06, at 4:14 AM, Arnt Gulbrandsen wrote: >> Curtis King writes: >>> If we are going to-do this then why keep the mailbox framework? >>> VFOLDER currently has a number of show stoppers already: >>> >>> 1. duplicate messages. >> >> I don't see that as a show stopper. It's the kind of thing >> developers worry about, that's all. >> >>> 2. message going into and out of focus. >> >> Also not a show stopper. It happens seldom, so we can afford to be >> waste bytes when it happens. It's just that we can't break the >> protocol when it happens. > > As one who implements these drafts, this is a pain. Tracking UID and > assigning new UID when a message comes back into focus means you have > to assign message new UID for each message in a VFOLDER. Not a very > virtual folder to me. Yes. Agreed. I currently store name, owner, ACL, two UIDNEXT values, a search expression and a bunch of uid+uid pairs. Storing less would be desirable. But how? The only possibilities I can think of have worse consequences, e.g. blocking the way to multi-mailbox vfolders. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 12:39:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCgl-0005lG-Ps; Fri, 02 Jun 2006 12:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCgk-0005lB-H6 for lemonade@ietf.org; Fri, 02 Jun 2006 12:39:54 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmCgj-0002gJ-56 for lemonade@ietf.org; Fri, 02 Jun 2006 12:39:54 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k52GdoJ23520 for ; Fri, 2 Jun 2006 12:39:50 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jun 2006 12:39:50 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0A668132@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft liaison to OMA Thread-Index: AcaGYyrLPsYFy7O6TTqna3iW0WpfTA== From: "Glenn Parsons" To: "Enhancements to Internet email to support diverse serviceenivronments" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [lemonade] Draft liaison to OMA X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Folks, As discussed during the interim here is a draft liaison to OMA. Note that this needs to be sent soon to ensure it is available for their next meeting. As a result, I will be sending this to OMA on June 8th. Please forward me your comments (if any) before then. Cheers, Glenn. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DD=3DR=3D= A=3DF=3DT=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D From: IETF LEMONADE Working Group To: OMA MWG MEM Sub Working Group Date: June 1, 2006 Title: Update on LEMONADE activity=09 Response contact: lemonade@ietf.org Purpose: For Action The LEMONADE working group (WG) would like to thank the OMA Mobile Email Sub Working Group for your latest liaison. We would like to update you on our progress. Of note is that we have several RFCs that have recently been approved: RFC 4467 - IMAP URLAUTH RFC 4468 - IMAP BURL RFC 4469 - IMAP CATENATE RFC 4550 - LEMONADE Profile In addition, we are nearing completion on several of the documents in discussion in the WG. The following documents are either in or will be in WG last call after our meeting: Draft-vaudreuil-futuredelivery Draft-ietf-lemonade-convert Draft-ietf-search-within Draft-ietf-lemonade-deployments Draft-daboo-annotatemore Draft-melnikov-imap-search-ret In the LEMONADE Notifications document (draft-ietf-lemonade-notifications) we have based notification on OMA EMN. However, in the development of the functionality we have the need to identify items (such as message subject, date, sender, etc.) that are not part of the EMN mechanism. As a result, we have described these as a different extended notification payload in addition to the base EMN payload. We request that OMA MEM examine this extension and indicate if our current approach is suitable and if OMA would consider extending EMN with these capabilities. =20 As we have indicated before, the LEMONADE WG is working on a set of extensions to IMAP and ESMTP to support mobile email. This set will be succinctly described in the LEMONADE profile (draft-ietf-lemonade-profile-bis). We understand that the OMA TS will normatively reference the LEMONADE profile for the MEM protocol. In order to help us understand your usage better, we would appreciate a presentation on the OMA MEM TS for LEMONADE.=20 Finally, LEMONADE is considering options for an interoperability event. interop. From an IETF perspective, our interest is only to facilitate protocol maturity. Specifically, that is to prove the feasibility of the protocol and to document multiple interworking implementations. We are discussing a private event in Fall 2006 to initiate this testing. Our results could be input to OMA MEM for use in your interop events. And also this could be followed by marketing/interop at Telecom 2006 and 3GSM trade shows. Would OMA MEM be interested in interop events? Up-to-date information on LEMONADE Internet-Drafts and RFCs can always be found at http://www.ietf.org/html.charters/lemonade-charter.html with more detail tracked on the supplemental site. Finally, as information, the next meetings of the IETF LEMONADE WG are: - Jul 10-14 - IETF 66 plenary - Montreal - Oct ? - LEMONADE interim/interop - UK - TBD - Nov 10-14 - IETF 67 plenary - California - TBD _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 12:45:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCm2-0002Dy-3R; Fri, 02 Jun 2006 12:45:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCm0-0002Di-8w for lemonade@ietf.org; Fri, 02 Jun 2006 12:45:20 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmCly-0003EI-Tb for lemonade@ietf.org; Fri, 02 Jun 2006 12:45:20 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k52GjDr9002375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Jun 2006 09:45:14 -0700 Received: from [192.168.1.13] (vpn-10-50-16-141.qualcomm.com [10.50.16.141]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k52Gj47k011577; Fri, 2 Jun 2006 09:45:11 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <3rUAVGSUFos9vsPyoMtEXg.md5@libertango.oryx.com> References: <20060601070749343.00000000428@smaes-lap3> <3rUAVGSUFos9vsPyoMtEXg.md5@libertango.oryx.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 2 Jun 2006 09:37:32 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [Lemonade] Discussion items from thsimorning on VFOLDER and WITHIN Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 9:08 PM +0200 6/1/06, Arnt Gulbrandsen wrote: > Randall Gellens writes: >> But if a message goes in and out of view, and gets a new UID each >> time it reappears, wouldn't it get downloaded multiple times? > > Yes. So it had better not happen often. Fortunately, I don't think it will. > > If people use UNSEEN and SEEN in vfolders, and the \seen flag keeps > being toggled on and off, then we have a problem. But the \seen > flag typically is set once and that's it. I think this is client-specific, with some clients setting \seen once the message has been displayed to the user, or appears in a preview pane for a few seconds, or clicked past. I think Eudora sets its internal \seen flag like this, and updates the server in batches. I often reset messages to unseen, to let myself know that I haven't finished reading or thinking about a message. So in my case, messages go between \seen and not often. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There is a life-size picture of a dogcow conveniently located in the Finder. Look under "Page Setup..." Now look under "Options." Like any talented dog, it can do flips. Like any talented cow, it can do precision bitmap alignment. --Apple Tech Note #31 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 16:16:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmG3u-0006Ss-8H; Fri, 02 Jun 2006 16:16:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmG3s-0006Sd-Sd for lemonade@ietf.org; Fri, 02 Jun 2006 16:16:00 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmG3r-0007VI-Iw for lemonade@ietf.org; Fri, 02 Jun 2006 16:16:00 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id EDD6A272B6; Fri, 2 Jun 2006 14:15:58 -0600 (MDT) In-Reply-To: References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Date: Fri, 2 Jun 2006 14:15:57 -0600 To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 2-Jun-06, at 10:19 AM, Arnt Gulbrandsen wrote: >> As one who implements these drafts, this is a pain. Tracking UID >> and assigning new UID when a message comes back into focus means >> you have to assign message new UID for each message in a VFOLDER. >> Not a very virtual folder to me. > > Yes. Agreed. I currently store name, owner, ACL, two UIDNEXT > values, a search expression and a bunch of uid+uid pairs. Storing > less would be desirable. But how? The only possibilities I can > think of have worse consequences, e.g. blocking the way to multi- > mailbox vfolders. I doubt know if you can, but servers are being force to store more information for a VFOLDER than a real mailbox. That just doesn't seem like the right design. Why not have named searches which can be used as FILTERS when selecting a mailbox to provide the desired view? Clients can handle an UID going out and in of view because they will expect that behavior. For things like multi-mailbox vfolders why not use a named search and copy to populate a new mailbox from the source mailboxes? This may require some extensions to search and some way of storing the last uid used int the search. Now, the clients can decide when to update the mailbox and what messages and flags are synchronized between the mailboxes. This isn't any more work than vfolder, but you can sure do more with it. I hope I'm making more sense. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 16:28:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGFe-00008m-B1; Fri, 02 Jun 2006 16:28:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGFd-00008h-CF for lemonade@ietf.org; Fri, 02 Jun 2006 16:28:09 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGFa-0000I1-UK for lemonade@ietf.org; Fri, 02 Jun 2006 16:28:09 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k52KS0QQ003059; Fri, 2 Jun 2006 13:28:00 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k52KRwWa008227 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Jun 2006 13:28:00 -0700 Date: Fri, 2 Jun 2006 13:27:59 -0700 (Pacific Daylight Time) From: Mark Crispin To: Curtis King Subject: Re: [lemonade] Draft Minutes, Interim Day 1 In-Reply-To: <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> Message-ID: References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Enhancements to Internet email to support diverse serviceenivronments , Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri, 2 Jun 2006, Curtis King wrote: > Why not have named searches which can be used as FILTERS when selecting a > mailbox to provide the desired view? Clients can handle an UID going out and > in of view because they will expect that behavior. For what it's worth, I agree with this observation. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 18:26:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmI5u-0007D4-94; Fri, 02 Jun 2006 18:26:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmI5s-00076U-Qx for lemonade@ietf.org; Fri, 02 Jun 2006 18:26:12 -0400 Received: from pathbreaker.com ([64.71.130.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmI5r-0004iR-Ff for lemonade@ietf.org; Fri, 02 Jun 2006 18:26:12 -0400 Received: (qmail 13051 invoked by uid 89); 2 Jun 2006 22:25:30 -0000 Received: from localhost (HELO ?192.168.1.101?) (ray%logicaldepth.com@127.0.0.1) by 0 with SMTP; 2 Jun 2006 22:25:30 -0000 Message-ID: <4480BAED.7090902@pathbreaker.com> Date: Fri, 02 Jun 2006 15:25:49 -0700 From: Ray Cromwell User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Curtis King Subject: Re: [lemonade] Draft Minutes, Interim Day 1 References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> In-Reply-To: <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Enhancements to Internet email to support diverse serviceenivronments , Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King wrote: > For things like multi-mailbox vfolders why not use a named search and > copy to populate a new mailbox from the source mailboxes? This may > require some extensions to search and some way of storing the last > uid used int the search. Now, the clients can decide when to update > the mailbox and what messages and flags are synchronized between the > mailboxes. > Other lemonade extensions (notably notifications) are depending on the server to know when to update the "mailbox", not the client. The server minimally needs to know that one of the "searches" of interest to the client (whether this is implemented as vfolders, filters, or search+copy) would have changed, so that the server can tell a client (typically a mobile client) to wakeup and go check for changes. If the mobile client had to poll for changes itself, it would be a drain on battery life and bandwidth. The current draft does allow the server to reject searches which would allow messages to appear/reappear (e.g. searches based on dynamic attributes, or searches using 'within' that would create an interval with gaps in it). The real question is, is this really a problem for mobile clients, and is the cure worse than the disease? (duplicate downloading rarely vs losing the ability to search on dynamic attributes or spending bandwidth on ouid/global uid/hash/urls) -Ray _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 18:50:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmITC-0005XE-5U; Fri, 02 Jun 2006 18:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmITB-0005PK-1G for lemonade@ietf.org; Fri, 02 Jun 2006 18:50:17 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmIT9-0000jz-NP for lemonade@ietf.org; Fri, 02 Jun 2006 18:50:16 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 2F72D272B5; Fri, 2 Jun 2006 16:50:15 -0600 (MDT) In-Reply-To: <4480BAED.7090902@pathbreaker.com> References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> <4480BAED.7090902@pathbreaker.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Date: Fri, 2 Jun 2006 16:50:14 -0600 To: Ray Cromwell X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 2-Jun-06, at 4:25 PM, Ray Cromwell wrote: > Other lemonade extensions (notably notifications) are depending on > the server to know when to update the "mailbox", not the client. > The server minimally needs to know that one of the "searches" of > interest to the client (whether this is implemented as vfolders, > filters, or search+copy) would have changed, so that the server can > tell a client (typically a mobile client) to wakeup and go check > for changes. If the mobile client had to poll for changes itself, > it would be a drain on battery life and bandwidth. Notification is completely separate from updating the content of mailbox. > > The current draft does allow the server to reject searches which > would allow messages to appear/reappear (e.g. searches based on > dynamic attributes, or searches using 'within' that would create an > interval with gaps in it). The real question is, is this really a > problem for mobile clients, and is the cure worse than the disease? > (duplicate downloading rarely vs losing the ability to search on > dynamic attributes or spending bandwidth on ouid/global uid/hash/urls) Don't forget about the other half, the server ;) My suggestion of using filters avoids duplicate downloading, supports dynamic attributes, and notifications. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 19:38:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmJDi-0007HT-9b; Fri, 02 Jun 2006 19:38:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmJDh-0007HO-Ag for lemonade@ietf.org; Fri, 02 Jun 2006 19:38:21 -0400 Received: from pathbreaker.com ([64.71.130.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmJDf-0003hR-VR for lemonade@ietf.org; Fri, 02 Jun 2006 19:38:21 -0400 Received: (qmail 18662 invoked by uid 89); 2 Jun 2006 23:37:39 -0000 Received: from localhost (HELO ?192.168.1.101?) (ray%logicaldepth.com@127.0.0.1) by 0 with SMTP; 2 Jun 2006 23:37:39 -0000 Message-ID: <4480CBD6.7040808@pathbreaker.com> Date: Fri, 02 Jun 2006 16:37:58 -0700 From: Ray Cromwell User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Curtis King Subject: Re: [lemonade] Draft Minutes, Interim Day 1 References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> <4480BAED.7090902@pathbreaker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King wrote: > > Notification is completely separate from updating the content of > mailbox. Yes, but from a user's point of view on the client, they probably want notifications associated with events related to a particular (virtual) mailbox on their client. Let's say I want all messages from the lemonade mailing list in the past day to appear on my client grouped in a mailbox called 'lemonade' and I want notifications when something changes in this "mailbox" on the server. That means that even if this client side lemonade mailbox isn't a real mailbox on the server, but a filter on an existing mailbox, the server must still somehow be able to monitor filters and know which mailboxes to attach those filters to for the purposes of notifications. Moreover, it must somehow tell the client which filter applied to which mailbox it should check for updates on. It seems we're changing syntax from "SELECT mailbox" to "SELECT mailbox VIEW named-view" with the benefit being a possible gain for legacy clients. The server would still need to check for messages disappearing/reappearing within a view if dynamic attributes are used, so it doesn't appear to relieve any pressure on server implementation, wouldn't it? -Ray _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 02 21:06:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmKac-0001zx-Iq; Fri, 02 Jun 2006 21:06:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmKab-0001zr-Gs for lemonade@ietf.org; Fri, 02 Jun 2006 21:06:05 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmKaa-00043M-6y for lemonade@ietf.org; Fri, 02 Jun 2006 21:06:05 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id A3D27272B5; Fri, 2 Jun 2006 19:06:03 -0600 (MDT) In-Reply-To: <4480CBD6.7040808@pathbreaker.com> References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> <4480BAED.7090902@pathbreaker.com> <4480CBD6.7040808@pathbreaker.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Date: Fri, 2 Jun 2006 19:06:02 -0600 To: Ray Cromwell X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 2-Jun-06, at 5:37 PM, Ray Cromwell wrote: > It seems we're changing syntax from "SELECT mailbox" to "SELECT > mailbox VIEW named-view" with the benefit being a possible gain for > legacy clients. The benefit to legacy clients is from using "SELECT mailbox". But since vfolders are available using LISTEXT it's no use for them. Besides thinking about it more, vfolders would be very confusing to legacy clients. > The server would still need to check for messages disappearing/ > reappearing within a view if dynamic attributes are used, so it > doesn't appear to relieve any pressure on server implementation, > wouldn't it? A filter sure does save work. vfolder requires the server to assign a new UID to a message in the vfolder. As Arnt pointed out this means storing on disk UIDNEXT and a mapping between backing mailbox message uid and the vfolder uid. Using a filter I don't have to store any of this extra information. Notifications using vfolder: 1. monitor back-end mailbox for changes. 2. when there is a change see if it matches the search criteria. 3. if adding a new message assign an UID and increment UIDNEXT. 4. if deleting a message decrement message reference count. 5. report changes to client Notifications using filter: 1. monitor back-end mailbox for changes. 2. when there is a change re-run the search 3, diff the two search results and report the changes. A filter is much simpler to implement even with extra protocol changes needed. vfolder is filter on backing mailbox pretending it's a real mailbox. This overloads what a mailbox is. Why not call a filter a filter? ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Jun 03 01:17:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmOVY-0000tj-4o; Sat, 03 Jun 2006 01:17:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmOVX-0000te-6a for lemonade@ietf.org; Sat, 03 Jun 2006 01:17:07 -0400 Received: from mail3.panix.com ([166.84.1.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmOVU-0002ag-Sl for lemonade@ietf.org; Sat, 03 Jun 2006 01:17:07 -0400 Received: from mailspool2.panix.com (mailspool2.panix.com [166.84.1.79]) by mail3.panix.com (Postfix) with ESMTP id B76D713A8D0 for ; Sat, 3 Jun 2006 01:17:04 -0400 (EDT) Received: from [192.168.1.11] (ool-45749fe3.dyn.optonline.net [69.116.159.227]) by mailspool2.panix.com (Postfix) with ESMTP id 70AC8E173E3 for ; Sat, 3 Jun 2006 01:17:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC1612446572BBB09@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446572BBB09@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X 6.2.3 (MacOS 10.3) Date: Sat, 3 Jun 2006 00:26:52 -0400 To: From: "Robert A. Rosenberg" Subject: Re: [lemonade] Question on 'Sent Items' deposit X-Spam-Score: 0.6 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1208710798==" Errors-To: lemonade-bounces@ietf.org --===============1208710798== Content-Type: multipart/alternative; boundary="============_-1062810672==_ma============" --============_-1062810672==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable At 10:28 +0300 on 06/02/2006, wrote about=20 [lemonade] Question on 'Sent Items' deposit: >Hi all, >It a is a usual practice to place a copy of a sent email (new,=20 >replied, forwarded) to a special store typically called "Sent=20 >items"/"Sent mail" > >I understand that this is not done automatically - or perhaps I=20 >missed some draft(?) - and it is the client's responsibility to=20 >create and desposit the copy. I recon this is not a problem for a=20 >fixed terminal. However, when I send something from a mobile=20 >terminal, I would not want to upload it twice (once to SUBMIT server=20 >and again to the IMAP server). > >Does LEMONADE provide a mechanism to make sure that we do not need=20 >to upload an email twice? >If yes, which draft describes it, if not, I think it should be added. >Thank You. > >Best regards: Zolt=E1n =D6rd=F6gh >E-mail: zoltan.ordogh at nokia.com >Phone: +358 50 386 0566 One solution to this problem is to implement an IMAP equivalent of=20 the POP3 "XTND XMIT" extension. This POP3 capability, if you are not=20 familiar with it, allows the POP Server to act as a MSA (Mail=20 Submission Agent) via the POP Session followed by handing off the=20 message to the local SMTP Server. Since it has the message, the IMAP Server can save it to the "Sent=20 items"/"Sent mail" folder after relaying it to the SMTP Server. --============_-1062810672==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [lemonade] Question on 'Sent Items' deposit
At 10:28 +0300 on 06/02/2006, <Zoltan.Ordogh@nokia.com> wrote about [lemonade] Question on 'Sent Items' deposit:

Hi all,
It= a is a usual practice to place a copy of a sent email (new, replied, forwarded) to a special store typically called "Sent items"/"Sent mail"
I understand that this is not done automatically - or perhaps I missed some draft(?) - and it is the client's responsibility to create and desposit the copy. I recon this is not a problem for a fixed terminal. However, when I send something from a mobile terminal, I would not want to upload it twice (once to SUBMIT server and again to the IMAP server).
Do= es LEMONADE provide a mechanism to make sure that we do not need to upload an email twice?
If yes, which draft describes it, if not, I think it should be added.
Th= ank You.
Best regards: Zolt=E1n =D6rd=F6gh
E-mail: zoltan.ordogh at nokia.com
Phone: +358 50 386 0566

One solution to this problem is to implement an IMAP equivalent of the POP3 "XTND XMIT" extension. This POP3 capability, if you are not familiar with it, allows the POP Server to act as a MSA (Mail Submission Agent) via the POP Session followed by handing off the message to the local SMTP Server.

Since it has the message, the IMAP Server can save it to the "Sent items"/"Sent mail" folder after relaying it to the SMTP Server.
--============_-1062810672==_ma============-- --===============1208710798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============1208710798==-- From lemonade-bounces@ietf.org Sat Jun 03 02:28:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmPcd-0006nu-6u; Sat, 03 Jun 2006 02:28:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmPcc-0006k8-CX for lemonade@ietf.org; Sat, 03 Jun 2006 02:28:30 -0400 Received: from pathbreaker.com ([64.71.130.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmPcZ-0001MB-PL for lemonade@ietf.org; Sat, 03 Jun 2006 02:28:30 -0400 Received: (qmail 18885 invoked by uid 89); 3 Jun 2006 06:27:47 -0000 Received: from localhost (HELO ?192.168.1.101?) (ray%logicaldepth.com@127.0.0.1) by 0 with SMTP; 3 Jun 2006 06:27:47 -0000 Message-ID: <44812BF6.80403@pathbreaker.com> Date: Fri, 02 Jun 2006 23:28:06 -0700 From: Ray Cromwell User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Curtis King Subject: Re: [lemonade] Draft Minutes, Interim Day 1 References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> <4480BAED.7090902@pathbreaker.com> <4480CBD6.7040808@pathbreaker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King wrote: > > A filter sure does save work. vfolder requires the server to assign a > new UID to a message in the vfolder. As Arnt pointed out this means > storing on disk UIDNEXT and a mapping between backing mailbox message > uid and the vfolder uid. Using a filter I don't have to store any of > this extra information. > > Notifications using vfolder: > > 1. monitor back-end mailbox for changes. > 2. when there is a change see if it matches the search criteria. > 3. if adding a new message assign an UID and increment UIDNEXT. > 4. if deleting a message decrement message reference count. > 5. report changes to client > > Notifications using filter: > 1. monitor back-end mailbox for changes. > 2. when there is a change re-run the search > 3, diff the two search results and report the changes. > > A filter is much simpler to implement even with extra protocol > changes needed. > Perhaps I'm misunderstanding something, but I don't see how filters solve the problem. It seems to me that the difference between vfolders and filters is that vfolders apply the filter by default when you select a mailbox, and with your filter proposal, they don't get applied unless the client asks them to when selecting a mailbox. This by itself does not solve the problem of needing to assign new UIDs. Consider the following sequence of user actions using "filters" 1) user creates new filter "Flagged Stuff" with search expression "SEARCH FLAGGED", client issues command to create this filter on the server 2) user tells client he wants this applied to INBOX creating a new 'pseudo folder' on his client called "Flagged Stuff" so that when he clicks the flagged stuff, he sees only flagged messages 3) user tries to sync "Flagged Stuff" 4) client issues something like SELECT INBOX VIEW "Flagged Stuff" to server 5) client syncs INBOX with this view applied into a separare local folder on the client. A message with UID 150 appears in the sequence. Client stays in this session with view attached. 6) using a separate client#2 (say, a desktop client), user unflags message with UID 150 7) client syncs again (either cause of user action, notification, or IDLE). Message with UID 150 is now expunged from local client #1 cache 8) using client #2, user re-flags message with UID 150 in INBOX 9) client#1 syncs again, Message with UID 150 in INBOX must reappear in the view of this session. According to my understanding, if this happens, it violates IMAP4 guarantees, therefore, it must be given a new UID that is greater than all other UIDs in the view. > vfolder is filter on backing mailbox pretending it's a real mailbox. > This overloads what a mailbox is. Why not call a filter a filter? > Does it? Does RFC3501 rigorously define what a mailbox is or is it an abstraction that can have several implementations? Seems to me that if a VFOLDER's semantics are done right, and if it obeys all of RFC3501's semantics with respect to how mailboxes behavior, we simply have an 'is-a' relationship between interface and implementation. Mailbox being the interface, and backing mailbox, newsgroup, vfolder, and others being implementations of that interface. -Ray > ck > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Jun 03 12:09:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmYgt-0001Rm-B7; Sat, 03 Jun 2006 12:09:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmYgs-0001Ne-3P for lemonade@ietf.org; Sat, 03 Jun 2006 12:09:30 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmYgq-0001Gj-P4 for lemonade@ietf.org; Sat, 03 Jun 2006 12:09:30 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k53G9Ra6026631; Sat, 3 Jun 2006 09:09:28 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k53G9KtI010894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Jun 2006 09:09:27 -0700 Date: Sat, 3 Jun 2006 09:09:20 -0700 (PDT) From: Mark Crispin To: "Robert A. Rosenberg" Subject: Re: [lemonade] Question on 'Sent Items' deposit In-Reply-To: Message-ID: References: <0FA975F2D8295A448BE3ADC1612446572BBB09@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sat, 3 Jun 2006, Robert A. Rosenberg wrote: > One solution to this problem is to implement an IMAP equivalent of the POP3 > "XTND XMIT" extension. This POP3 capability, if you are not familiar with it, > allows the POP Server to act as a MSA (Mail Submission Agent) via the POP > Session followed by handing off the message to the local SMTP Server. Simple answer: No. No. 1000 times, NO!! This topic is dead, buried, and the corpse thoroughly rotted. There are list archives, read them. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Jun 03 12:11:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmYiZ-0003BY-W5; Sat, 03 Jun 2006 12:11:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmYiZ-0003BT-08 for lemonade@ietf.org; Sat, 03 Jun 2006 12:11:15 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmYiW-0001JS-Jk for lemonade@ietf.org; Sat, 03 Jun 2006 12:11:14 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k53GBBhb011976; Sat, 3 Jun 2006 09:11:11 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k53GBAB7010990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Jun 2006 09:11:11 -0700 Date: Sat, 3 Jun 2006 09:11:10 -0700 (PDT) From: Mark Crispin To: Ray Cromwell Subject: Re: [lemonade] Draft Minutes, Interim Day 1 In-Reply-To: <44812BF6.80403@pathbreaker.com> Message-ID: References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> <4480BAED.7090902@pathbreaker.com> <4480CBD6.7040808@pathbreaker.com> <44812BF6.80403@pathbreaker.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri, 2 Jun 2006, Ray Cromwell wrote: > Does it? Does RFC3501 rigorously define what a mailbox is or is it an > abstraction that can have several implementations? Seems to me that if a > VFOLDER's semantics are done right, and if it obeys all of RFC3501's > semantics with respect to how mailboxes behavior, we simply have an 'is-a' > relationship between interface and implementation. Mailbox being the > interface, and backing mailbox, newsgroup, vfolder, and others being > implementations of that interface. The problem is that VMAILBOX (not VFOLDER) has to complex with IMAP's mailbox semantics, but it really isn't an IMAP mailbox, so it has to do these various unfriendly kludges with UIDs to avoid the viiolation of IMAP, but those kludges cause their own problems. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Jun 03 19:09:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmfFJ-0007X7-Mn; Sat, 03 Jun 2006 19:09:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmfFI-0007Uv-L0 for lemonade@ietf.org; Sat, 03 Jun 2006 19:09:28 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmf0Q-0006qd-DJ for lemonade@ietf.org; Sat, 03 Jun 2006 18:54:09 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id B8495272B5; Sat, 3 Jun 2006 16:54:05 -0600 (MDT) In-Reply-To: <44812BF6.80403@pathbreaker.com> References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> <4480BAED.7090902@pathbreaker.com> <4480CBD6.7040808@pathbreaker.com> <44812BF6.80403@pathbreaker.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24777498-401D-465C-8990-B8C12FA0F8FD@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Date: Sat, 3 Jun 2006 16:54:06 -0600 To: Ray Cromwell X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 3-Jun-06, at 12:28 AM, Ray Cromwell wrote: > 9) client#1 syncs again, Message with UID 150 in INBOX must > reappear in the view of this session. According to my > understanding, if this happens, it violates IMAP4 guarantees, > therefore, it must be given a new UID that is greater than all > other UIDs in the view. Sorry, I haven't been clear enough. The above is correct when dealing with a mailbox which Mark explained is the problem with VMAILBOX. What I'm suggesting is not to use SELECT but something new which either can be extension to SELECT or an other command like VIEW or FILTER. Since its a new command we can change the semantics to better meet our requirements like allowing UID go in and out of view. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 05 03:07:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9BP-0002ax-Fz; Mon, 05 Jun 2006 03:07:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9BO-0002ap-I4 for lemonade@ietf.org; Mon, 05 Jun 2006 03:07:26 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn9BN-00062l-S0 for lemonade@ietf.org; Mon, 05 Jun 2006 03:07:26 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5577HgV008104 for ; Mon, 5 Jun 2006 10:07:24 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 10:07:21 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 10:07:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: FW: [lemonade] LEMONADE Profile 2 issues Date: Mon, 5 Jun 2006 10:07:07 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657323A48@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] LEMONADE Profile 2 issues Thread-Index: AcZ5soXTmp4eJRFxRP2S5d2DVSC3wQMtaIq9AIGL/7A= From: To: X-OriginalArrivalTime: 05 Jun 2006 07:07:21.0553 (UTC) FILETIME=[B07EFC10:01C6886E] X-Spam-Score: 0.7 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1355042789==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1355042789== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6886E.B02ED0B1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6886E.B02ED0B1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, this is something I sent to the Chairmen, they suggested it to be sent = to the mailing list. So, here we go: =20 Page 1 -> Typo: "It provides also extensions to provide support for = realizationz of"-> realizations Section 12.2.2 " I2 designates proprietary adapters to the backends. They may = invoved functions performed in the message stores or submit server as well as in the MEM enabler server." -> invoved? Involved, right? -> What is a proprietary adapter? This is supposed to provide an IMAP = <-> POP3 mapping, right? So the message here is that proprietary emails = will never work because LEMONADE supports IMAP/SUBMIT only, so whatever = You do, You will need a LEMONADE anabled IMAP/SUBMIT anyway, right? If = so, should this whole section be removed then? (LEMONADE does not = provide any support/specification for it, so it's not in the scope). Section 13 -> Title contains "LEMONADE" - is is supposed to be there or it is = simply incomplete? -> under DF: reference [25] is for the sieve charter and not the = specification. It needs to be described how sieve filters can be used. = Also, it says "can be" - is that a MAY? If so, what other alternatives = are there? I mean the client and the LEMONADE-compliant server both need = to know otherwise we have IOP issues, right? -> under VF: reference sentence seems to be messed up (reference [26] is = used twice in the same sentence) and the sentence itself does not look = good either. -> under VF: referenced document [37] is listed as "Replaced, Dead or = Unknown" on the web site, while the document designated as replacement = does not exist (in the LEMONADE repository at least). Section 14. ->Third last bullet lists reference [49]. This reference is listed as = "Replaced, Dead or Unknown" and it cannot be accessed on the LEMONADE = repository. ->Second last bullet lists reference [46] for best practices, while [45] = is listed here as well. Now, [46] discourages piggybacking, while [45] = encourages it - which is contradicting. Contradictions are no good in = standards, can we get rid of either one of them? -> The bullets are full of "as discussed in" statement. Would it be = possible to have requirements on those instead? Like "MUST/SHOULD/MAY = follow this or MUST/SHOULD/MAY follow that"? And finally: There are an awfully long list of references listed - however not all of = these are used. Reference [48] is a very good example. Stephane for = example takes every opportunity to promote proprietary technology P-IMAP = - if You check, it's almost in every draft, but never actually used. I = am not saying P-IMAP is bad, I am saying that this kind of behaviour = confuses OMA MEM, analists (even my own managers) because they do not = know what LEMONADE is and what the relation of profile/bis to P-IMAP is = (which was believed to be dropped quite a while ago). To avoid = confusion, all of the unused references should be either removed or = described why and how they are used. I hope these worries can be addressed as soon as possible. Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 ------_=_NextPart_001_01C6886E.B02ED0B1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [lemonade] LEMONADE Profile 2 issues
Hi all,
this is something I sent to the Chairmen, they suggested = it to be=20 sent to the mailing list.
So, here we go:
 
Page 1
-> Typo: "It = provides also=20 extensions to provide support for realizationz of"->=20 realizations

Section 12.2.2
"   I2 designates = proprietary=20 adapters to the backends.  They may invoved
   = functions=20 performed in the message stores or submit server as well = as
   in=20 the MEM enabler server."
-> invoved? Involved, right?
-> = What is a=20 proprietary adapter? This is supposed to provide an IMAP <-> POP3 = mapping,=20 right? So the message here is that proprietary emails will never work = because=20 LEMONADE supports IMAP/SUBMIT only, so whatever You do, You will need a = LEMONADE=20 anabled IMAP/SUBMIT anyway, right? If so, should this whole section be = removed=20 then? (LEMONADE does not provide any support/specification for it, so = it's not=20 in the scope).

Section 13
-> Title contains "LEMONADE" - is = is=20 supposed to be there or it is simply incomplete?
-> under DF: = reference=20 [25] is for the sieve charter and not the specification. It needs to be=20 described how sieve filters can be used. Also, it says "can be" - is = that a MAY?=20 If so, what other alternatives are there? I mean the client and the=20 LEMONADE-compliant server both need to know otherwise we have IOP = issues,=20 right?

-> under VF: reference sentence seems to be messed up=20 (reference [26] is used twice in the same sentence) and the sentence = itself does=20 not look good either.

-> under VF: referenced document [37] is = listed=20 as "Replaced, Dead or Unknown" on the web site, while the document = designated as=20 replacement does not exist (in the LEMONADE repository at = least).

Section=20 14.
->Third last bullet lists reference [49]. This reference is = listed as=20 "Replaced, Dead or Unknown" and it cannot be accessed  on the LEMONADE = repository.

->Second=20 last bullet lists reference [46] for best practices, while [45] is = listed here=20 as well. Now, [46] discourages piggybacking, while [45] encourages it - = which is=20 contradicting. Contradictions are no good in standards, can we get rid = of either=20 one of them?

-> The bullets are full of "as discussed in" = statement.=20 Would it be possible to have requirements on those instead? Like=20 "MUST/SHOULD/MAY follow this or MUST/SHOULD/MAY follow that"?

And = finally:
There are an awfully long list of references listed - = however not=20 all of these are used. Reference [48] is a very good example. Stephane = for=20 example takes every opportunity to promote proprietary = technology=20 P-IMAP  - if You check, it's almost in every draft, but never = actually=20 used. I am not saying P-IMAP is bad, I am saying that this kind of = behaviour=20 confuses OMA MEM, analists (even my own managers) because they do not = know what=20 LEMONADE is and what the relation of profile/bis to P-IMAP is (which was = believed to be dropped quite a while ago). To avoid confusion, all of = the unused=20 references should be either removed or described why and how they are=20 used.

I hope these worries can be addressed as soon as = possible.
Thank=20 You.

Best regards: Zolt=E1n =D6rd=F6gh
E-mail:=20 zoltan.ordogh@nokia.com
Phone: +358 50 386=20 0566


------_=_NextPart_001_01C6886E.B02ED0B1-- --===============1355042789== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============1355042789==-- From lemonade-bounces@ietf.org Mon Jun 05 03:17:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9LD-0000uE-Ka; Mon, 05 Jun 2006 03:17:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9LC-0000u9-EW for lemonade@ietf.org; Mon, 05 Jun 2006 03:17:34 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn9LA-0006Ek-TT for lemonade@ietf.org; Mon, 05 Jun 2006 03:17:34 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k557HSXD029837; Mon, 5 Jun 2006 10:17:31 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 10:17:30 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 10:17:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Question on 'Sent Items' deposit Date: Mon, 5 Jun 2006 10:17:16 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657323A68@esebe199.NOE.Nokia.com> In-Reply-To: <2880.1149248485.157000@JOHN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Question on 'Sent Items' deposit Thread-Index: AcaGOX26eDmOXYJTT42EmbVRW5XddQCNZ/sQ From: To: X-OriginalArrivalTime: 05 Jun 2006 07:17:30.0264 (UTC) FILETIME=[1B50E980:01C68870] X-Spam-Score: 0.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dave, thank You. Yes, I certainly would like to have it in the profile. >From "The FCC problem" I did not quite get the idea - I am not familiar = with the term. I would prefer describing it more detail in bis. So, You are saying it can be done. Now, is the UID the same in all messages - to guarantee that the client = does not download the newly deposited message from the "Sent items" box? Could You elaborate this statement: "Incidentally, usage of these mechanisms can be sensible over DSL links, = since usage-based billing is increasingly common." I do not understand how can it be sensible when the email is not = uploaded again. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh at nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext Dave Cridland [mailto:dave@cridland.net]=20 Sent: 02 June, 2006 14:41 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: Enhancements to Internet email to support diverse service = enivronments Subject: Re: [lemonade] Question on 'Sent Items' deposit On Fri Jun 02 08:28:05 2006, Zoltan.Ordogh@nokia.com wrote: > Hi all, > It a is a usual practice to place a copy of a sent email (new,=20 > replied, forwarded) to a special store typically called "Sent=20 > items"/"Sent mail" I tend to put them in INBOX, in fact, but the practise of a specific = mailbox for copies of sent messages is common. > I understand that this is not done automatically - or perhaps I=20 > missed some draft(?) - and it is the client's responsibility to=20 > create and desposit the copy. I recon this is not a problem for a=20 > fixed terminal. However, when I send something from a mobile=20 > terminal, I would not want to upload it twice (once to SUBMIT=20 > server and again to the IMAP server). > Does LEMONADE provide a mechanism to make sure that we do not need=20 > to upload an email twice? Yes, and we do - you upload the copy (via APPEND, possibly using=20 CATENATE to assemble), and then send by using a single BURL/URLAUTH=20 pair. There's an alternate method, which uses POSTADDRESS, which isn't=20 currently part of Lemonade. (Perhaps it should be?) This is covered in section 2.7 of Profile Bis (and probably of=20 Profile, too). I might alter the title if it makes this easier to=20 find. Incidentally, usage of these mechanisms can be sensible over DSL=20 links, since usage-based billing is increasingly common. Dave. --=20 Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 05 03:20:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9Ne-00025S-2J; Mon, 05 Jun 2006 03:20:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9Nc-000257-SQ for lemonade@ietf.org; Mon, 05 Jun 2006 03:20:04 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn9Nb-0006JY-DJ for lemonade@ietf.org; Mon, 05 Jun 2006 03:20:04 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k557JxfE031424; Mon, 5 Jun 2006 10:19:59 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 10:18:59 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 10:18:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Question on 'Sent Items' deposit Date: Mon, 5 Jun 2006 10:18:45 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657323A6F@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Question on 'Sent Items' deposit Thread-Index: AcaHKDURrUR2J3OgTR6W7uNkUu5VQgBR/xfg From: To: , X-OriginalArrivalTime: 05 Jun 2006 07:18:59.0074 (UTC) FILETIME=[50403E20:01C68870] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org This is exactly the reason why we need to describe it in more detail in = bis :-) Thank You Robert and Mark anyway.=20 Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh at nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext Mark Crispin [mailto:mrc@CAC.Washington.EDU]=20 Sent: 03 June, 2006 19:09 To: Robert A. Rosenberg Cc: lemonade@ietf.org Subject: Re: [lemonade] Question on 'Sent Items' deposit On Sat, 3 Jun 2006, Robert A. Rosenberg wrote: > One solution to this problem is to implement an IMAP equivalent of the = > POP3 "XTND XMIT" extension. This POP3 capability, if you are not=20 > familiar with it, allows the POP Server to act as a MSA (Mail=20 > Submission Agent) via the POP Session followed by handing off the = message to the local SMTP Server. Simple answer: No. No. 1000 times, NO!! This topic is dead, buried, and the corpse thoroughly rotted. There are = list archives, read them. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 05 06:19:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnCBC-0001iJ-0l; Mon, 05 Jun 2006 06:19:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnCBA-0001iC-Tv for lemonade@ietf.org; Mon, 05 Jun 2006 06:19:24 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnCB9-0001jK-Bs for lemonade@ietf.org; Mon, 05 Jun 2006 06:19:24 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 15F384AC98; Mon, 5 Jun 2006 12:19:22 +0200 (CEST) Message-Id: Date: Mon, 5 Jun 2006 12:20:17 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Draft Minutes, Interim Day 1 References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> In-Reply-To: <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King writes: > On 2-Jun-06, at 10:19 AM, Arnt Gulbrandsen wrote: >>> As one who implements these drafts, this is a pain. Tracking UID >>> and assigning new UID when a message comes back into focus means >>> you have to assign message new UID for each message in a VFOLDER. >>> Not a very virtual folder to me. >> >> Yes. Agreed. I currently store name, owner, ACL, two UIDNEXT values, >> a search expression and a bunch of uid+uid pairs. Storing less >> would be desirable. But how? The only possibilities I can think of >> have worse consequences, e.g. blocking the way to multi- mailbox >> vfolders. > > I doubt know if you can, but servers are being force to store more > information for a VFOLDER than a real mailbox. That just doesn't seem > like the right design. All I can say is that I've tried hard and not found any way. For example, I thought about some variations that didn't store the UID map, but then the server had to look at the entire mailbox at each SELECT (or APPLYFILTER, or whatever the SELECT-like command is called). I considered variations that involved storing data clientside, but that breaks when the user uses both a desktop client and a portable device. I tried workarounds for that, such as mandating that the client store their clientside data serverside (in METADATA) and use a prescribed command sequence to "SELECT". And so on. > Why not have named searches which can be used as FILTERS when > selecting a mailbox to provide the desired view? Clients can handle > an UID going out and in of view because they will expect that > behavior. > > For things like multi-mailbox vfolders why not use a named search and > copy to populate a new mailbox from the source mailboxes? This may > require some extensions to search and some way of storing the last > uid used int the search. Now, the clients can decide when to update > the mailbox and what messages and flags are synchronized between the > mailboxes. Why don't you write up a draft in some detail and we'll see whether it's an improvement? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 05 07:47:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnDYM-000634-Gw; Mon, 05 Jun 2006 07:47:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnDYM-00062o-8F for lemonade@ietf.org; Mon, 05 Jun 2006 07:47:26 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnDYK-0005jj-Qc for lemonade@ietf.org; Mon, 05 Jun 2006 07:47:26 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 60D5B4ACB6; Mon, 5 Jun 2006 13:47:23 +0200 (CEST) Message-Id: <63XKNtDBcX0PXoKEwf71Pw.md5@libertango.oryx.com> Date: Mon, 5 Jun 2006 13:48:18 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [Lemonade] Discussion items from thsimorning on VFOLDER and WITHIN References: <20060601070749343.00000000428@smaes-lap3> <72FDD20C56FDCB399E7AAF41@Cyrus-Daboo.local> <29C68D773C6A73BB2A0FCC48@Cyrus-Daboo.local> In-Reply-To: <29C68D773C6A73BB2A0FCC48@Cyrus-Daboo.local> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Cyrus Daboo X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Something I just thought of. An URL is sufficent to fetch a message, but not sufficient for a client to know whether it already has a message. This is because the server knows whether INBOX and users.daboo.inbox are the same, but the client does not. Ditto users.daboo.INBOX and users.daboo.inbox. Of course, this is again just a few per cent lost. The client can do a case-sensitive equality test and be right almost all of the time, and the few per cent is just a minor slowdown in an unused case. Not worth much effort. (The common case being that the user reads either vfolders or the backing mailbox, not both.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 05 08:01:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnDlY-0003aI-TH; Mon, 05 Jun 2006 08:01:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnDlY-0003aA-0W for lemonade@ietf.org; Mon, 05 Jun 2006 08:01:04 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnDlW-0006DD-Hv for lemonade@ietf.org; Mon, 05 Jun 2006 08:01:03 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 5 Jun 2006 13:00:53 +0100 Message-ID: <4481EAEE.3070206@isode.com> Date: Sat, 03 Jun 2006 21:02:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Cridland References: <1632.1148375454.675000@JOHN> In-Reply-To: <1632.1148375454.675000@JOHN> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: service enivronments , Enhancements Subject: [lemonade] Re: RECONNECT comments: Typos, nits, minor issues. X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > Section 2.1: > The last paragraph appears to be marketing, not technical, information > - there's no reason at all the user cannot use the client program > while it's resynchronizing. Deleted. [...] > Section 5.1: > > Why is there a special sequence for no folder? Why not just send an > empty "* FOLDER" response? All clients have to deal with empty > responses, for instance for SEARCH responses. As per our recend discussion, "* FOLDER" was changed to "* SELECTED". And I made the mailbox name optional. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 05 08:41:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnEOd-0005Ws-Ta; Mon, 05 Jun 2006 08:41:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnEOc-0005Wn-UW for lemonade@ietf.org; Mon, 05 Jun 2006 08:41:26 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnEOb-0007u5-Fn for lemonade@ietf.org; Mon, 05 Jun 2006 08:41:26 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 5 Jun 2006 13:41:23 +0100 Message-ID: <4484263D.2070008@isode.com> Date: Mon, 05 Jun 2006 13:40:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Cridland Subject: Re: [lemonade] Question on 'Sent Items' deposit References: <0FA975F2D8295A448BE3ADC1612446572BBB09@esebe199.NOE.Nokia.com> <2880.1149248485.157000@JOHN> In-Reply-To: <2880.1149248485.157000@JOHN> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: lemonade@ietf.org, "Zoltan.Ordogh@nokia.com" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > On Fri Jun 02 08:28:05 2006, Zoltan.Ordogh@nokia.com wrote: > >> Hi all, >> It a is a usual practice to place a copy of a sent email (new, >> replied, forwarded) to a special store typically called "Sent >> items"/"Sent mail" > > I tend to put them in INBOX, in fact, but the practise of a specific > mailbox for copies of sent messages is common. > >> I understand that this is not done automatically - or perhaps I >> missed some draft(?) - and it is the client's responsibility to >> create and desposit the copy. I recon this is not a problem for a >> fixed terminal. However, when I send something from a mobile >> terminal, I would not want to upload it twice (once to SUBMIT server >> and again to the IMAP server). >> Does LEMONADE provide a mechanism to make sure that we do not need to >> upload an email twice? > > Yes, and we do - you upload the copy (via APPEND, possibly using > CATENATE to assemble), and then send by using a single BURL/URLAUTH pair. > > There's an alternate method, which uses POSTADDRESS, which isn't > currently part of Lemonade. (Perhaps it should be?) > > This is covered in section 2.7 of Profile Bis (and probably of > Profile, too). Yes, this is the same section in Profile. Step by step instructions are specified in Section 2.4.1 of Profile. > I might alter the title if it makes this easier to find. I am wondering if Profile bis should have a section with several simple examples, that would help to understand the more detailed explanation? > Incidentally, usage of these mechanisms can be sensible over DSL > links, since usage-based billing is increasingly common. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 05 09:04:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnEkb-0007ne-3q; Mon, 05 Jun 2006 09:04:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnEka-0007nZ-RB for lemonade@ietf.org; Mon, 05 Jun 2006 09:04:08 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnEkZ-0001ni-9O for lemonade@ietf.org; Mon, 05 Jun 2006 09:04:08 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 5 Jun 2006 14:04:04 +0100 Message-ID: <44842B8F.20908@isode.com> Date: Mon, 05 Jun 2006 14:03:11 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] Question on 'Sent Items' deposit References: <0FA975F2D8295A448BE3ADC161244657323A68@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657323A68@esebe199.NOE.Nokia.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Encoded: Changed encoding from 8bit for 7bit transmission X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan.Ordogh@nokia.com wrote: >Hi Dave, >thank You. > >Yes, I certainly would like to have it in the profile. >From "The FCC problem" I did not quite get the idea - I am not familiar wi= th the term. >I would prefer describing it more detail in bis. > = > FCC is "file carbon copy", a term used in several Mail User Agents to = describe saving a copy of a sent message into a mailbox (which is = usually a file). Somebody who has been around for longer might be better in explaining this. >So, You are saying it can be done. >Now, is the UID the same in all messages > No, IMAP server will create a separate UID (unique identifier) for each = message. >- to guarantee that the client does not download the newly deposited messa= ge from the "Sent items" box? > = > UIDPLUS extension addresses this issue. When the client = uploads/constructs a message with APPEND, the server returns the = APPENDUID response code, which tells the client UID of the created = message. This is exactly to avoid the need for the client to download = the message it just uploaded. This is shown in the example in section 2.4.1. >Could You elaborate this statement: >"Incidentally, usage of these mechanisms can be sensible over DSL links, s= ince usage-based billing is increasingly common." >I do not understand how can it be sensible when the email is not uploaded = again. > = > I think Dave just said that "forward without download" is useful for = both people with mobile devices and DSL users. >Best regards: Zolt=E1n =D6rd=F6gh >E-mail: zoltan.ordogh at nokia.com >Phone: +358 50 386 0566 > > >-----Original Message----- >From: ext Dave Cridland [mailto:dave@cridland.net] = >Sent: 02 June, 2006 14:41 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) >Cc: Enhancements to Internet email to support diverse service enivronments >Subject: Re: [lemonade] Question on 'Sent Items' deposit > >On Fri Jun 02 08:28:05 2006, Zoltan.Ordogh@nokia.com wrote: > = > >>Hi all, >>It a is a usual practice to place a copy of a sent email (new, = >>replied, forwarded) to a special store typically called "Sent = >>items"/"Sent mail" >> = >> > >I tend to put them in INBOX, in fact, but the practise of a specific mailb= ox for copies of sent messages is common. > = > >>I understand that this is not done automatically - or perhaps I = >>missed some draft(?) - and it is the client's responsibility to = >>create and desposit the copy. I recon this is not a problem for a = >>fixed terminal. However, when I send something from a mobile = >>terminal, I would not want to upload it twice (once to SUBMIT = >>server and again to the IMAP server). >>Does LEMONADE provide a mechanism to make sure that we do not need = >>to upload an email twice? >> = >> > >Yes, and we do - you upload the copy (via APPEND, possibly using = >CATENATE to assemble), and then send by using a single BURL/URLAUTH = >pair. > >There's an alternate method, which uses POSTADDRESS, which isn't = >currently part of Lemonade. (Perhaps it should be?) > >This is covered in section 2.7 of Profile Bis (and probably of = >Profile, too). I might alter the title if it makes this easier to = >find. > >Incidentally, usage of these mechanisms can be sensible over DSL = >links, since usage-based billing is increasingly common. > >Dave. > = > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 05 16:12:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLQe-0003z3-Ru; Mon, 05 Jun 2006 16:12:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLQd-0003yw-Cz for lemonade@ietf.org; Mon, 05 Jun 2006 16:11:59 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLQc-0000vt-48 for lemonade@ietf.org; Mon, 05 Jun 2006 16:11:59 -0400 X-IronPort-AV: i="4.05,211,1146456000"; d="scan'208"; a="33697881:sNHT26663108" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Jun 2006 16:11:53 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664702FAB979@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interim Minutes Updated Thread-Index: AcaI3Eli25o4A42XRzCRGyG9xpy/3Q== From: "Burger, Eric" To: "Enhancements to Internet email to support diverse service enivronments" X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [lemonade] Interim Minutes Updated X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Added folks I was missing from our virtual blue sheets. Added information for proposed marketing interop tests. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 05 21:15:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnQAP-0002Px-BP; Mon, 05 Jun 2006 21:15:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMYt-0004Wn-R4 for lemonade@ietf.org; Mon, 05 Jun 2006 17:24:35 -0400 Received: from stiedprtick1-ext.va.neustar.com ([156.154.16.147] helo=ticket.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMYt-0002yx-JG for lemonade@ietf.org; Mon, 05 Jun 2006 17:24:35 -0400 Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1FnMYt-00081m-A5 for lemonade@ietf.org; Mon, 05 Jun 2006 17:24:35 -0400 From: "Liaison Statements via RT" In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #86613 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: lemonade@ietf.org To: lemonade@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Mon, 05 Jun 2006 17:24:35 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-Mailman-Approved-At: Mon, 05 Jun 2006 21:15:32 -0400 Subject: [lemonade] [Inquiry #86613] AutoReply: New Liaison Statement, "Update on LEMONADE activity" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Reply-To: statements@ietf.org List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "New Liaison Statement, "Update on LEMONADE activity"", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #86613] in the queue: Liaison-Statements. Please include the string: [Inquiry #86613] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, statements@ietf.org ------------------------------------------------------------------------- Title: Update on LEMONADE activity Submission Date: 2006-06-05 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=230 Please reply by 2006-07-03 From: Glenn Parsons(IETF LEMONADE WG) To: OMA MEM(OMA-LIAISON@mail.openmobilealliance.org) Cc: lemonade@ietf.org dean.willis@softarmor.com hardie@qualcomm.com Reponse Contact: lemonade@ietf.org Technical Contact: gparsons@nortel.com eburger@cantata.com Purpose: For action Body: The LEMONADE working group (WG) would like to thank the OMA Mobile Email Sub Working Group for your latest liaison. We would like to update you on our progress. Of note is that we have several RFCs that have recently been approved: RFC 4467 – IMAP URLAUTH RFC 4468 – IMAP BURL RFC 4469 – IMAP CATENATE RFC 4550 – LEMONADE Profile RFC 4551 – IMAP CONDSTORE In addition, we are nearing completion on several of the documents in discussion in the WG. The following documents are either in or will be in WG last call after our meeting: Draft-vaudreuil-futuredelivery Draft-ietf-lemonade-convert Draft-ietf-search-within Draft-ietf-lemonade-deployments Draft-daboo-imap-annotatemore Draft-melnikov-imap-search-res In the LEMONADE Notifications document (draft-ietf-lemonade-notifications) we have based notification on OMA EMN. However, in the development of the functionality we have the need to identify items (such as message subject, date, sender, etc.) that are not part of the EMN mechanism. As a result, we have described these as a different extended notification payload in addition to the base EMN payload. We request that OMA MEM examine this extension and indicate if our current approach is suitable and if OMA would consider extending EMN with these capabilities. As we have indicated before, the LEMONADE WG is working on a set of extensions to IMAP and ESMTP to support mobile email. This set will be succinctly described in the LEMONADE profile (draft-ietf-lemonade-profile-bis). We understand that the OMA TS will normatively reference the LEMONADE profile for the MEM protocol. In order to help us understand your usage better, we would appreciate a presentation on the OMA MEM TS for LEMONADE. Finally, LEMONADE is considering options for an interoperability event. interop. From an IETF perspective, our interest is only to facilitate protocol maturity. Specifically, that is to prove the feasibility of the protocol and to document multiple interworking implementations. We are discussing a private event in Fall 2006 to initiate this testing. Our results could be input to OMA MEM for use in your interop events. And also this could be followed by marketing/interop at Telecom 2006 and 3GSM trade shows. Would OMA MEM be interested in interop events? Up-to-date information on LEMONADE Internet-Drafts and RFCs can always be found at http://tools.ietf.org/wg/lemonade/ with additional information on our charter page http://www.ietf.org/html.charters/lemonade-charter.html Finally, as information, the next meetings of the IETF LEMONADE WG are: - Jul 10-14 – IETF 66 plenary – Montreal - Oct ? – LEMONADE interim/interop – UK - TBD - Nov 10-14 – IETF 67 plenary – California - TBD Attachment(s): text of liaison (https://datatracker.ietf.org/documents/LIAISON/file322.pdf) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 06 06:38:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnYwz-00047s-E8; Tue, 06 Jun 2006 06:38:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnY4k-0004e4-BT for lemonade@ietf.org; Tue, 06 Jun 2006 05:42:14 -0400 Received: from xms1.etsi.org ([212.234.161.112] helo=Xms1.etsihq.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnY4h-0000aI-U4 for lemonade@ietf.org; Tue, 06 Jun 2006 05:42:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Jun 2006 11:42:08 +0200 Message-ID: In-Reply-To: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OMA-MEM-2006-0105-ILS-update-on-LEMONADE-Activity : Thread-Index: AcaI5oqixbVP3/sXRxarBzE92Vmb/gAZtZOQ From: "Christine Mera" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f X-Mailman-Approved-At: Tue, 06 Jun 2006 06:38:16 -0400 Subject: [lemonade] OMA-MEM-2006-0105-ILS-update-on-LEMONADE-Activity : X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Glenn, Your liaison has been registered and sent to OMA MWG MEM. Best regards, Christine M=E9ra OMA Liaison Co-ordinator=20 -----Original Message----- From: OMA Liaison list [mailto:OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG] = On Behalf Of Glenn Parsons (IETF LEMONADE WG) Sent: 05 June 2006 23:24 To: OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG Subject: OMA-MEM-2006-0105-ILS-update-on-LEMONADE-Activity :=20 Title: Update on LEMONADE activity Submission Date: 2006-06-05 URL of the IETF Web page: = https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D230 Please reply by 2006-07-03 From: Glenn Parsons(IETF LEMONADE WG) To: OMA MEM(OMA-LIAISON@mail.openmobilealliance.org) Cc: lemonade@ietf.org dean.willis@softarmor.com hardie@qualcomm.com Reponse Contact: lemonade@ietf.org Technical Contact: gparsons@nortel.com eburger@cantata.com Purpose: For action Body: The LEMONADE working group (WG) would like to thank the OMA Mobile = Email Sub Working Group for your latest liaison. We would like to update you on our progress. Of note is that we have = several RFCs that have recently been approved: RFC 4467 - IMAP URLAUTH RFC 4468 - IMAP BURL RFC 4469 - IMAP CATENATE RFC 4550 - LEMONADE Profile RFC 4551 - IMAP CONDSTORE In addition, we are nearing completion on several of the documents in = discussion in the WG. The following documents are either in or will be = in WG last call after our meeting: Draft-vaudreuil-futuredelivery Draft-ietf-lemonade-convert Draft-ietf-search-within Draft-ietf-lemonade-deployments Draft-daboo-imap-annotatemore Draft-melnikov-imap-search-res In the LEMONADE Notifications document = (draft-ietf-lemonade-notifications) we have based notification on OMA = EMN. However, in the development of the functionality we have the need = to identify items (such as message subject, date, sender, etc.) that are = not part of the EMN mechanism. As a result, we have described these as = a different extended notification payload in addition to the base EMN = payload. We request that OMA MEM examine this extension and indicate if = our current approach is suitable and if OMA would consider extending EMN = with these capabilities. =20 As we have indicated before, the LEMONADE WG is working on a set of = extensions to IMAP and ESMTP to support mobile email. This set will be = succinctly described in the LEMONADE profile = (draft-ietf-lemonade-profile-bis). We understand that the OMA TS will = normatively reference the LEMONADE profile for the MEM protocol. In = order to help us understand your usage better, we would appreciate a = presentation on the OMA MEM TS for LEMONADE.=20 Finally, LEMONADE is considering options for an interoperability event. = interop. From an IETF perspective, our interest is only to facilitate = protocol maturity. Specifically, that is to prove the feasibility of = the protocol and to document multiple interworking implementations. We = are discussing a private event in Fall 2006 to initiate this testing. = Our results could be input to OMA MEM for use in your interop events. = And also this could be followed by marketing/interop at Telecom 2006 and = 3GSM trade shows. Would OMA MEM be interested in interop events? Up-to-date information on LEMONADE Internet-Drafts and RFCs can always = be found at http://tools.ietf.org/wg/lemonade/ with additional information on our charter page = http://www.ietf.org/html.charters/lemonade-charter.html=20 Finally, as information, the next meetings of the IETF LEMONADE WG are: - Jul 10-14 - IETF 66 plenary - Montreal - Oct ? - LEMONADE interim/interop - UK - TBD - Nov 10-14 - IETF 67 plenary - California - TBD Attachment(s): text of liaison = (https://datatracker.ietf.org/documents/LIAISON/file322.pdf) -------------------------------------------------------------------------= OMA - http://www.openmobilealliance.org Mailing List Archives are available at = http://mail.openmobilealliance.org This message was delivered to you from the OMA-LIAISON list on the OMA = Mailing List Server. If you wish to unsubscribe from this list please send a message to: LISTSERV@MAIL.OPENMOBILEALLIANCE.ORG with the words SIGNOFF OMA-LIAISON = in the BODY of the message. -------------------------------------------------------------------------= _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 06 12:28:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FneQK-0003pg-8r; Tue, 06 Jun 2006 12:28:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FneQJ-0003pX-7i for lemonade@ietf.org; Tue, 06 Jun 2006 12:28:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FncYC-0004WD-IV for lemonade@ietf.org; Tue, 06 Jun 2006 10:28:56 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FncKa-0004TX-37 for lemonade@ietf.org; Tue, 06 Jun 2006 10:14:54 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 6 Jun 2006 15:14:50 +0100 Message-ID: <4484A369.3090306@isode.com> Date: Mon, 05 Jun 2006 22:34:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lemonade WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [lemonade] Use of \Draft flag to indicate message ready for submission X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi folks, After reviewing some of the recent editorial changed done to Profile bis, it occurred to me that the draft is now recommending to use the \Draft system flag to mark messages that are about to be submitted. I think this is wrong, the \Draft flag has a special meaning of "the marked message is being edited, it might not be a proper RFC 2822 message", which is quite different from "the message is complete and waiting to be submitted". So I would suggest to define a new flag for the latter meaning. One of the advantage of having a new flag is ability to have both types of messages in the same mailbox. If a client submitting multiple messages crashes (which does happen), upon restart it can pick up from the message it failed to submit and continue submitting other messages in the mailbox. Any objections to the proposal? Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 06 12:52:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnemj-0008Ur-JI; Tue, 06 Jun 2006 12:52:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnemi-0008UN-4m for lemonade@ietf.org; Tue, 06 Jun 2006 12:52:04 -0400 Received: from out1.smtp.messagingengine.com ([66.111.4.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnemg-0000I5-QW for lemonade@ietf.org; Tue, 06 Jun 2006 12:52:04 -0400 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 446B9D69873; Tue, 6 Jun 2006 12:52:01 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Tue, 06 Jun 2006 12:52:03 -0400 X-Sasl-enc: JHBGcbbncwQbZwQRQlIMClTKtOA2cRuvQvMRP0hYlDvY 1149612723 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 030DE1E56; Tue, 6 Jun 2006 12:51:55 -0400 (EDT) Date: Tue, 06 Jun 2006 12:51:50 -0400 From: Cyrus Daboo To: Alexey Melnikov , Lemonade WG Subject: Re: [lemonade] Use of \Draft flag to indicate message ready for submission Message-ID: <7CAA2C95FA4686C648064717@Cyrus-Daboo.local> In-Reply-To: <4484A369.3090306@isode.com> References: <4484A369.3090306@isode.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Alexey, --On June 5, 2006 10:34:33 PM +0100 Alexey Melnikov wrote: > After reviewing some of the recent editorial changed done to Profile bis, > it occurred to me that the draft is now recommending to use the \Draft > system flag to mark messages that are about to be submitted. I think this > is wrong, the \Draft flag has a special meaning of "the marked message is > being edited, it might not be a proper RFC 2822 message", which is quite > different from "the message is complete and waiting to be submitted". So > I would suggest to define a new flag for the latter meaning. One of the > advantage of having a new flag is ability to have both types of messages > in the same mailbox. If a client submitting multiple messages crashes > (which does happen), upon restart it can pick up from the message it > failed to submit and continue submitting other messages in the mailbox. > > Any objections to the proposal? I agree - let's not overload the meaning of \Draft. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 06 12:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fneu2-0003x6-PV; Tue, 06 Jun 2006 12:59:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fneu1-0003x0-IU for lemonade@ietf.org; Tue, 06 Jun 2006 12:59:37 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnety-0000tg-Vi for lemonade@ietf.org; Tue, 06 Jun 2006 12:59:37 -0400 Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k56GxX3W022117; Tue, 6 Jun 2006 09:59:34 -0700 (PDT) Received: from we-gotmail.red.iplanet.com (gotmail-1.red.iplanet.com [192.18.73.251]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k56GxW8J018398; Tue, 6 Jun 2006 09:59:33 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=US-ASCII Received: from NIKITA.sun.com (vpn-129-150-25-31.SFBay.Sun.COM [129.150.25.31]) by we-gotmail.red.iplanet.com (Sun Java(tm) System Messaging Server 6.3-0.07 (built Apr 11 2006)) with ESMTPSA id <0J0G00D1N777D300@we-gotmail.red.iplanet.com>; Tue, 06 Jun 2006 09:59:32 -0700 (PDT) Date: Tue, 06 Jun 2006 09:59:26 -0700 (Pacific Daylight Time) From: Anil SRIVASTAVA To: Alexey Melnikov Subject: Re: [lemonade] Use of \Draft flag to indicate message ready for submission In-reply-to: <4484A369.3090306@isode.com> Message-id: References: <4484A369.3090306@isode.com> X-Message-flag: Outlook: the best virus distribution system around Accept-Language: English; en Organization: Sun Microsystems [http://www.sun.com] X-Mailer: Pine 4.64 (Windows XP) - Got Pine? [http://www.washington.edu/pine] X-Message-Class: normal X-Endorsement: Message brought to you by Sun Java Enterprise System Communication Suite 4 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: anil.srivastava@Sun.COM List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I agree with the proposal. Let us not mix \draft with message ready to be submitted. Anil On 2006-06-05/22:34 [+0100], alexey.melnikov@isode.com [Alexey Melnikov] wrote: > Hi folks, > After reviewing some of the recent editorial changed done to Profile bis, it > occurred to me that the draft is now recommending to use the \Draft system > flag to mark messages that are about to be submitted. I think this is wrong, > the \Draft flag has a special meaning of "the marked message is being edited, > it might not be a proper RFC 2822 message", which is quite different from "the > message is complete and waiting to be submitted". So I would suggest to define > a new flag for the latter meaning. One of the advantage of having a new flag > is ability to have both types of messages in the same mailbox. If a client > submitting multiple messages crashes (which does happen), upon restart it can > pick up from the message it failed to submit and continue submitting other > messages in the mailbox. > > Any objections to the proposal? > > Alexey > > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > _______________ Anil SRIVASTAVA anil.srivastava@Sun.COM _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 06 14:37:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngQx-0001gM-7q; Tue, 06 Jun 2006 14:37:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngQv-0001gH-Iu for lemonade@ietf.org; Tue, 06 Jun 2006 14:37:41 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FngQu-0005PY-53 for lemonade@ietf.org; Tue, 06 Jun 2006 14:37:41 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FngQs-0002Vd-T2; Tue, 06 Jun 2006 18:37:39 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 4655B498007; Tue, 6 Jun 2006 19:42:03 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17583-03; Tue, 6 Jun 2006 19:41:57 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 402C7498006; Tue, 6 Jun 2006 19:41:57 +0100 (BST) Date: Tue, 06 Jun 2006 19:37:32 +0100 Subject: Re: [lemonade] Use of \Draft flag to indicate message ready for submission References: <4484A369.3090306@isode.com> In-Reply-To: <4484A369.3090306@isode.com> MIME-Version: 1.0 Message-Id: <3408.1149619052.645680@peirce.dave.cridland.net> From: Dave Cridland To: Alexey Melnikov Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon Jun 5 22:34:33 2006, Alexey Melnikov wrote: > Hi folks, > After reviewing some of the recent editorial changed done to > Profile bis, it occurred to me that the draft is now recommending > to use the \Draft system flag to mark messages that are about to be > submitted. I think this is wrong, the \Draft flag has a special > meaning of "the marked message is being edited, it might not be a > proper RFC 2822 message", which is quite different from "the > message is complete and waiting to be submitted". So I would > suggest to define a new flag for the latter meaning. Incidentally, that was my edit, based on a mis-reading of a thread here, so I'm quite happy to define a new flag instead. Another related proposal: Alexey has had a long-standing draft defining a formal registry for what I'll call $keywords, and it's this that originally defined $Forwarded, for instance. It's draft-melnokov-imap-keywords - and currently expired. I would personally feel happier if $Forwarded were restored to this draft, and I would feel much happier if $NewKeywordMeaningReadyToSend were defined in such a document. So I'd like to table a motion that: a) Alexey is encouraged into bringing his draft back into production, b) we reference it from Profile Bis, c) it defines a new flag indicating "ready for submission", d) optionally, it defines $Forwarded as well, updating Profile. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 06 14:51:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngeH-0003y4-0B; Tue, 06 Jun 2006 14:51:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngeG-0003xw-80 for lemonade@ietf.org; Tue, 06 Jun 2006 14:51:28 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FngeE-0006Um-VZ for lemonade@ietf.org; Tue, 06 Jun 2006 14:51:28 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-11.tower-121.messagelabs.com!1149619870!7764782!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 14660 invoked from network); 6 Jun 2006 18:51:10 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-11.tower-121.messagelabs.com with SMTP; 6 Jun 2006 18:51:10 -0000 Received: from [135.210.128.33] (unknown[135.210.128.33](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060606185110gw100100jae> (Authid: tony); Tue, 6 Jun 2006 18:51:10 +0000 Message-ID: <4485CE97.5020307@att.com> Date: Tue, 06 Jun 2006 14:51:03 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 CC: Lemonade WG Subject: Re: [lemonade] Use of \Draft flag to indicate message ready for submission References: <4484A369.3090306@isode.com> In-Reply-To: <4484A369.3090306@isode.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org +1 Alexey Melnikov wrote: > After reviewing some of the recent editorial changed done to Profile > bis, it occurred to me that the draft is now recommending to use the > \Draft system flag to mark messages that are about to be submitted. I > think this is wrong, the \Draft flag has a special meaning of "the > marked message is being edited, it might not be a proper RFC 2822 > message", which is quite different from "the message is complete and > waiting to be submitted". So I would suggest to define a new flag for > the latter meaning. One of the advantage of having a new flag is ability > to have both types of messages in the same mailbox. If a client > submitting multiple messages crashes (which does happen), upon restart > it can pick up from the message it failed to submit and continue > submitting other messages in the mailbox. > > Any objections to the proposal? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 06 16:42:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FniNJ-0005iK-CP; Tue, 06 Jun 2006 16:42:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FniNF-0005eS-WA; Tue, 06 Jun 2006 16:42:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fni2p-0002Z6-Rs; Tue, 06 Jun 2006 16:20:55 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fnhpi-0001vL-Lb; Tue, 06 Jun 2006 16:07:23 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k56Jo1mU022825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FnhYv-0007Ms-R9; Tue, 06 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 06 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : IMAP4 Extensions for Quick Reconnect Author(s) : C. Wilson, A. Melnikov Filename : draft-ietf-lemonade-reconnect-07.txt Pages : 24 Date : 2006-6-6 This document defines a quick reconnect IMAP4 extension, which gives a mobile client the ability to resume a previously abandoned session, without the need to perform a full synchronization sequence. The goal is to minimize the amount of data transfered at login after a dropped connection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-reconnect-07.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-lemonade-reconnect-07.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: <2006-6-6133704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-reconnect-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-reconnect-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-6133704.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Wed Jun 07 06:16:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnv5Q-0002eP-Sg; Wed, 07 Jun 2006 06:16:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnv5P-0002eK-Ht for lemonade@ietf.org; Wed, 07 Jun 2006 06:16:27 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnv5N-0003rL-2a for lemonade@ietf.org; Wed, 07 Jun 2006 06:16:27 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k57AGN4p002386; Wed, 7 Jun 2006 13:16:24 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 13:16:24 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 13:16:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Use of \Draft flag to indicate message ready forsubmission Date: Wed, 7 Jun 2006 13:16:08 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465738EB31@esebe199.NOE.Nokia.com> In-Reply-To: <4484A369.3090306@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Use of \Draft flag to indicate message ready forsubmission Thread-Index: AcaJhmbc8UJMJJKMSRCSVVxcEPhbyAAlHFGA From: To: , X-OriginalArrivalTime: 07 Jun 2006 10:16:24.0514 (UTC) FILETIME=[6E40FA20:01C68A1B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Yes, I agree with this. Once a draft message is complete (e.g. saved as a draft), it won't be = necessarily sent. I for instance use it to store notes/comments (which I = never send) related to emails that I have received. Do You have a proposal for a good name for this flag? Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: 06 June, 2006 00:35 To: Lemonade WG Subject: [lemonade] Use of \Draft flag to indicate message ready = forsubmission Hi folks, After reviewing some of the recent editorial changed done to Profile = bis, it occurred to me that the draft is now recommending to use the = \Draft system flag to mark messages that are about to be submitted. I = think this is wrong, the \Draft flag has a special meaning of "the = marked message is being edited, it might not be a proper RFC 2822 = message", which is quite different from "the message is complete and = waiting to be submitted". So I would suggest to define a new flag for = the latter meaning. One of the advantage of having a new flag is ability = to have both types of messages in the same mailbox. If a client = submitting multiple messages crashes (which does happen), upon restart = it can pick up from the message it failed to submit and continue = submitting other messages in the mailbox. Any objections to the proposal? Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 07 07:05:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnvr1-0002fx-GJ; Wed, 07 Jun 2006 07:05:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnvqz-0002fo-S3 for lemonade@ietf.org; Wed, 07 Jun 2006 07:05:37 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnvqy-000054-Dd for lemonade@ietf.org; Wed, 07 Jun 2006 07:05:37 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 7 Jun 2006 12:05:33 +0100 Message-ID: <4486B2FA.907@isode.com> Date: Wed, 07 Jun 2006 12:05:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. > > Title : IMAP4 Extensions for Quick Reconnect > Author(s) : C. Wilson, A. Melnikov > Filename : draft-ietf-lemonade-reconnect-07.txt > Pages : 24 > Date : 2006-6-6 > >This document defines a quick reconnect IMAP4 extension, which gives >a mobile client the ability to resume a previously abandoned session, >without the need to perform a full synchronization sequence. The >goal is to minimize the amount of data transfered at login after a >dropped connection. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-07.txt > I believe this revision addresses all editorial comments from Dave and Arnt. It also addresses most of the editorial comments from Randy. The too remaining non editorial issues (ABNF for LOGOUT parameters and minimum number of per user sessions) were addressed as well. Alexey P.S. I've discovered some obsolete text in -07, which I removed from my copy. I will do another revision if the document is to be sent to IESG. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 07 07:10:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnvvQ-00051L-3W; Wed, 07 Jun 2006 07:10:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnvvO-00050Y-Tz for lemonade@ietf.org; Wed, 07 Jun 2006 07:10:10 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnvvN-00015P-Gl for lemonade@ietf.org; Wed, 07 Jun 2006 07:10:10 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 7 Jun 2006 12:10:07 +0100 Message-ID: <4486B40D.8040201@isode.com> Date: Wed, 07 Jun 2006 12:10:05 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] Use of \Draft flag to indicate message ready forsubmission References: <0FA975F2D8295A448BE3ADC16124465738EB31@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC16124465738EB31@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan.Ordogh@nokia.com wrote: >Yes, I agree with this. >Once a draft message is complete (e.g. saved as a draft), it won't be necessarily sent. I for instance use it to store notes/comments (which I never send) related to emails that I have received. > > Yes, I do the same. >Do You have a proposal for a good name for this flag? > > That is the difficult part :-)! Suggestions? Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 07 08:01:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwjO-0004dp-Em; Wed, 07 Jun 2006 08:01:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwjM-0004cd-DB for lemonade@ietf.org; Wed, 07 Jun 2006 08:01:48 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnwjL-00012s-SU for lemonade@ietf.org; Wed, 07 Jun 2006 08:01:48 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k57C1jG9024223 for ; Wed, 7 Jun 2006 15:01:47 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 15:01:47 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 15:01:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt Date: Wed, 7 Jun 2006 15:01:31 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465738ECE0@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt Thread-Index: AcaEO55OQHzzHme/SmWEI/8W20rNUAF5MwKQ From: To: X-OriginalArrivalTime: 07 Jun 2006 12:01:47.0856 (UTC) FILETIME=[27426500:01C68A2A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi all, A few questions/comments: - Section 4.3, first paragraph. I saw some emails about including/not = including Compression in CONVERT. What was the conclusion on this? Does = the current bis reflect that agreement? OMA STI does not include = parameters for compressing files. - Section 4.3, last paragraph. So, there will be a COMPRESS anyway? - Section 4.3 general. This section is confusing. Would it be possible = to describe things from the compression level point of view saying this = is low-level, that is application-level, and that is object-level = compression. This is believed to be better for this, that is believed to = be better for that. For low-level use this and that, for = application-level use this and that, and for object-level use this and = that. This is mandatory, while that is optional for the server. Clients = to evaluate which is available and best used according to their = capabilities and the current network conditions. - Section 4.5. Normative statement missing - is it a MUST, SHOULD or = MAY? - "required by [RFC3501]. As noted above, servers SHOULD support" that = note is quite far above - could we say "Section 4.3"? - Section 5: "STARTTLS | Required by IMAP [RFC3501]" Are we going to = describe all dependencies? If not, remove, if yes, add all please. - Section 5: "LPROVISION, LSETPREF, LGETPREF | Section 4.4" these are = not described in section 4.4. - Section 13, 1st bullet: double dot at the end of the paragraph. - Section 13, 3nd bullet: "Notifications (server to client)" -> "Server = to client notifications", but: why the separation if they are discussed = in the same draft anyway? Thank You for the update, good stuff. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20 Sent: 31 May, 2006 01:50 To: i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF. Title : LEMONADE profile bis Author(s) : S. Maes, et al. Filename : draft-ietf-lemonade-profile-bis-02.txt Pages : 55 Date : 2006-5-30 =09 This document describes LEMONADE profile bis. It contains pointers or = mention to all the features that are normatively part of LEMONADE = profile bis. This document describes a profile (a set of required extensions, = restrictions and usage modes) of the IMAP and mail submission protocols. = This profile allows clients (especially those that are constrained in = memory, bandwidth, processing power, or other areas) to efficiently use = IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to = download and upload the mail, to optimize submission and to efficiently = resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon extensions to IMAP and Mail Submission = protocols; specifically URLAUTH and CATENATE IMAP protocol ([RFC3501]) extensions and BURL extension to the SUBMIT protocol = (SUBMIT). It provides also extensions to provide support for realizations of OMA = mobile email enabler (MEM) ([MEM-req] and [MEM-arch]) using Internet = Mail protocols defined by the IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-02.tx= t To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-profile-bis-02.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-lemonade-profile-bis-02.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 07 08:11:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwsT-0000wd-5h; Wed, 07 Jun 2006 08:11:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwsR-0000nG-Km for lemonade@ietf.org; Wed, 07 Jun 2006 08:11:11 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnwsQ-0001GY-6U for lemonade@ietf.org; Wed, 07 Jun 2006 08:11:11 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k57CB9qX002451; Wed, 7 Jun 2006 15:11:09 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 15:10:32 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 15:10:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Use of \Draft flag to indicate message ready forsubmission Date: Wed, 7 Jun 2006 15:10:16 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465738ED04@esebe199.NOE.Nokia.com> In-Reply-To: <4486B40D.8040201@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Use of \Draft flag to indicate message ready forsubmission Thread-Index: AcaKI8KjSsOYQepeQoSVAdic/tR+GwAB3pQg From: To: X-OriginalArrivalTime: 07 Jun 2006 12:10:30.0918 (UTC) FILETIME=[5F075260:01C68A2B] X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org \Unsent?=20 Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: 07 June, 2006 14:10 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: lemonade@ietf.org Subject: Re: [lemonade] Use of \Draft flag to indicate message ready = forsubmission Zoltan.Ordogh@nokia.com wrote: >Yes, I agree with this. >Once a draft message is complete (e.g. saved as a draft), it won't be = necessarily sent. I for instance use it to store notes/comments (which I = never send) related to emails that I have received. > =20 > Yes, I do the same. >Do You have a proposal for a good name for this flag? > =20 > That is the difficult part :-)! Suggestions? Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 07 08:24:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnx5V-0000DW-44; Wed, 07 Jun 2006 08:24:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnx5T-0000DR-JT for lemonade@ietf.org; Wed, 07 Jun 2006 08:24:39 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnx5S-0001YW-4j for lemonade@ietf.org; Wed, 07 Jun 2006 08:24:39 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 7 Jun 2006 13:24:36 +0100 Message-ID: <4486C57E.30001@isode.com> Date: Wed, 07 Jun 2006 13:24:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] Use of \Draft flag to indicate message ready forsubmission References: <0FA975F2D8295A448BE3ADC16124465738ED04@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC16124465738ED04@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan.Ordogh@nokia.com wrote: >\Unsent? > > Can't use the leading "\", as it means that the flag is a system flag. For most servers addition of a system flag requires some code modifications. $Unsent? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 07 08:54:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnxYW-00053W-D8; Wed, 07 Jun 2006 08:54:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnxYV-00053R-N8 for lemonade@ietf.org; Wed, 07 Jun 2006 08:54:39 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnxYU-0005Di-9w for lemonade@ietf.org; Wed, 07 Jun 2006 08:54:39 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 7 Jun 2006 13:54:37 +0100 Message-ID: <4486CC85.80400@isode.com> Date: Wed, 07 Jun 2006 13:54:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lemonade WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [lemonade] Notifications for multiple devices per user X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org In my private discussion with Zoltan he raised a question about IMAP server ability to store notification information (i.e. where the notification is to be sent) for multiple devices per user. Is this the requirement the WG wants to consider when thinking about notifications? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 07 08:57:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnxbP-0005MH-Ex; Wed, 07 Jun 2006 08:57:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnxbO-0005MC-6e for lemonade@ietf.org; Wed, 07 Jun 2006 08:57:38 -0400 Received: from out1.smtp.messagingengine.com ([66.111.4.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnxbM-0006QN-UV for lemonade@ietf.org; Wed, 07 Jun 2006 08:57:38 -0400 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id D113BD6A1BF; Wed, 7 Jun 2006 08:57:35 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Wed, 07 Jun 2006 08:57:38 -0400 X-Sasl-enc: 6E/H3mlCygkO1EIj3LK4Mxg9J5fJiE9Ag7e32eFo2L6S 1149685057 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 8E0A54158; Wed, 7 Jun 2006 08:57:35 -0400 (EDT) Date: Wed, 07 Jun 2006 08:57:31 -0400 From: Cyrus Daboo To: Alexey Melnikov , Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] Use of \Draft flag to indicate message ready forsubmission Message-ID: <4FD6E8A97358AC98A137776C@Cyrus-Daboo.local> In-Reply-To: <4486C57E.30001@isode.com> References: <0FA975F2D8295A448BE3ADC16124465738ED04@esebe199.NOE.Nokia.com> <4486C57E.30001@isode.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Alexey, --On June 7, 2006 1:24:30 PM +0100 Alexey Melnikov wrote: > Zoltan.Ordogh@nokia.com wrote: > >> \Unsent? >> >> > Can't use the leading "\", as it means that the flag is a system flag. > For most servers addition of a system flag requires some code > modifications. > > $Unsent? Actually, profilebis is using the \Draft flag (or rather the absence of the draft flag) as an indicator that the message was sent, as opposed to an indicator that the message is waiting to be sent. So I think what we actually want is a $Sent flag that the client can set once its fully completed the submission of the message. The alternative of $Unsent would mean that the client has to set that when doing the initial APPEND/CATENATE and then remove it on submission. Maybe we need both a $ToSend and a $Sent flag to cover all possible states? -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 07 09:44:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnyKU-0006ZW-MF; Wed, 07 Jun 2006 09:44:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnyKT-0006ZR-Qv for lemonade@ietf.org; Wed, 07 Jun 2006 09:44:13 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnyKS-0004Nb-Ca for lemonade@ietf.org; Wed, 07 Jun 2006 09:44:13 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FnyKR-0000lR-IU; Wed, 07 Jun 2006 13:44:11 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id E2C9A498007; Wed, 7 Jun 2006 14:48:42 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24332-01; Wed, 7 Jun 2006 14:48:33 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id A575A498006; Wed, 7 Jun 2006 14:48:33 +0100 (BST) Date: Wed, 07 Jun 2006 14:43:58 +0100 Subject: Re: [lemonade] Use of \Draft flag to indicate message ready forsubmission References: <0FA975F2D8295A448BE3ADC16124465738EB31@esebe199.NOE.Nokia.com> <4486B40D.8040201@isode.com> In-Reply-To: <4486B40D.8040201@isode.com> MIME-Version: 1.0 Message-Id: <8863.1149687841.064414@peirce.dave.cridland.net> From: Dave Cridland To: Alexey Melnikov Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Enhancements to Internet email to support diverse service enivronments , "Zoltan.Ordogh@nokia.com" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Jun 7 12:10:05 2006, Alexey Melnikov wrote: > Zoltan.Ordogh@nokia.com wrote: > >> Yes, I agree with this. >> Once a draft message is complete (e.g. saved as a draft), it won't >> be necessarily sent. I for instance use it to store notes/comments >> (which I never send) related to emails that I have received. >> > Yes, I do the same. > > I should mention that one of my users specifically wanted a $Note for that purpose, but that's distinct from a message where editing is complete, and the message is awaiting being sent. $Note - "The message has not been submitted, and is explicitly not intended to be sent.". >> Do You have a proposal for a good name for this flag? >> > That is the difficult part :-)! > Suggestions? $Pending - "The message is intended to be sent, but has not yet been submitted. Clients MUST NOT automatically send the message without user interaction." That latter proscription to both allow uses other than purely staging a message for immediate send, and prevent it from turning into an ill-advised IMAP-based submission mechanism. I'd assume that a client starting up might note the presence of $Pending messages and offer to send them, however. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 07 09:45:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnyM6-0007A0-U8; Wed, 07 Jun 2006 09:45:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnyM5-00079E-RG for lemonade@ietf.org; Wed, 07 Jun 2006 09:45:53 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnyM4-0004RV-Gq for lemonade@ietf.org; Wed, 07 Jun 2006 09:45:53 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FnyM2-0004jh-7l; Wed, 07 Jun 2006 13:45:50 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 699B1498007; Wed, 7 Jun 2006 14:50:22 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24237-07; Wed, 7 Jun 2006 14:50:18 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 33823498006; Wed, 7 Jun 2006 14:50:18 +0100 (BST) Date: Wed, 07 Jun 2006 14:45:45 +0100 Subject: Re: [lemonade] Use of \Draft flag to indicate message ready forsubmission References: <0FA975F2D8295A448BE3ADC16124465738ED04@esebe199.NOE.Nokia.com> <4486C57E.30001@isode.com> <4FD6E8A97358AC98A137776C@Cyrus-Daboo.local> In-Reply-To: <4FD6E8A97358AC98A137776C@Cyrus-Daboo.local> MIME-Version: 1.0 Message-Id: <8863.1149687945.612394@peirce.dave.cridland.net> From: Dave Cridland To: Cyrus Daboo Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Enhancements to Internet email to support diverse service enivronments , Alexey Melnikov , "Zoltan.Ordogh@nokia.com" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Jun 7 13:57:31 2006, Cyrus Daboo wrote: > Actually, profilebis is using the \Draft flag (or rather the > absence of the draft flag) as an indicator that the message was > sent, as opposed to an indicator that the message is waiting to be > sent. So I think what we actually want is a $Sent flag that the > client can set once its fully completed the submission of the > message. > > I'd have to say that a $Sent flag is unsuitable, because: a) that then would imply that any messages which did not have that flag were awaiting send, which is not the case now, and b) local copies of sent messages can arrive from outside IMAP, such as a BCC to oneself, or use of POSTADDRESS. > The alternative of $Unsent would mean that the client has to set > that when doing the initial APPEND/CATENATE and then remove it on > submission. > > It's possible that this is a dead-end - no flag, present or absent - may be the best option in most cases. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 07 09:52:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnyS2-00046J-Mq; Wed, 07 Jun 2006 09:52:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnyS1-00046E-J9 for lemonade@ietf.org; Wed, 07 Jun 2006 09:52:01 -0400 Received: from out1.smtp.messagingengine.com ([66.111.4.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnyS0-00050Y-CS for lemonade@ietf.org; Wed, 07 Jun 2006 09:52:01 -0400 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 4CFB1D69CCD; Wed, 7 Jun 2006 09:51:59 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Wed, 07 Jun 2006 09:52:01 -0400 X-Sasl-enc: qb9PWHt6KuV5HmmSrzuxWe7HOVHBlkT+wkIcWsNZhn7h 1149688321 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id D39BACD; Wed, 7 Jun 2006 09:51:54 -0400 (EDT) Date: Wed, 07 Jun 2006 09:51:50 -0400 From: Cyrus Daboo To: Dave Cridland Subject: Re: [lemonade] Use of \Draft flag to indicate message ready forsubmission Message-ID: In-Reply-To: <8863.1149687945.612394@peirce.dave.cridland.net> References: <0FA975F2D8295A448BE3ADC16124465738ED04@esebe199.NOE.Nokia.com> <4486C57E.30001@isode.com> <4FD6E8A97358AC98A137776C@Cyrus-Daboo.local> <8863.1149687945.612394@peirce.dave.cridland.net> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Enhancements to Internet email to support diverse service enivronments , Alexey Melnikov , Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dave, --On June 7, 2006 2:45:45 PM +0100 Dave Cridland wrote: >> Actually, profilebis is using the \Draft flag (or rather the >> absence of the draft flag) as an indicator that the message was >> sent, as opposed to an indicator that the message is waiting to be >> sent. So I think what we actually want is a $Sent flag that the >> client can set once its fully completed the submission of the >> message. >> >> > I'd have to say that a $Sent flag is unsuitable, because: > > a) that then would imply that any messages which did not have that flag > were awaiting send, which is not the case now, and I disagree, to me it means only that messages with that flag have been submitted via the BURL mechanism. > b) local copies of sent messages can arrive from outside IMAP, such as a > BCC to oneself, or use of POSTADDRESS. We could change the name to $Submitted to make the intent clearer. > >> The alternative of $Unsent would mean that the client has to set >> that when doing the initial APPEND/CATENATE and then remove it on >> submission. >> >> > It's possible that this is a dead-end - no flag, present or absent - may > be the best option in most cases. That's reasonable too... -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 07 13:28:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1pI-0002GP-ME; Wed, 07 Jun 2006 13:28:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1pH-0002As-DV for lemonade@ietf.org; Wed, 07 Jun 2006 13:28:15 -0400 Received: from stiedprtick1-ext.va.neustar.com ([156.154.16.147] helo=ticket.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1pG-0005Sm-94 for lemonade@ietf.org; Wed, 07 Jun 2006 13:28:15 -0400 Received: from apache by ticket.ietf.org with local (Exim 4.43) id 1Fo1pG-0006ET-4g for lemonade@ietf.org; Wed, 07 Jun 2006 13:28:14 -0400 From: " via RT" In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #86613 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: Rebecca.Bunch@Neustar.biz To: lemonade@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 07 Jun 2006 13:28:14 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Subject: [lemonade] [Inquiry #86613] Resolved: New Liaison Statement, "Update on LEMONADE activity" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Reply-To: statements@ietf.org List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 07 15:50:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo430-0002wB-EM; Wed, 07 Jun 2006 15:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo42W-00026j-GI; Wed, 07 Jun 2006 15:50:04 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo42U-0007Xw-AN; Wed, 07 Jun 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k57Jo2Rx002882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fo42U-0002kA-0g; Wed, 07 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Jun 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Internet Message Store Events Author(s) : C. Newman Filename : draft-ietf-lemonade-msgevent-00.txt Pages : 14 Date : 2006-6-7 One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail), devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events which interest real-world consumers of such a system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-msgevent-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-msgevent-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-7141826.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-msgevent-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-msgevent-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-7141826.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Thu Jun 08 04:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoG6k-0005Uh-6L; Thu, 08 Jun 2006 04:43:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoG6h-0005RH-I2 for lemonade@ietf.org; Thu, 08 Jun 2006 04:43:11 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoFyz-0003Vy-TW for lemonade@ietf.org; Thu, 08 Jun 2006 04:35:17 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id D92624ACC0; Thu, 8 Jun 2006 10:35:09 +0200 (CEST) Message-Id: Date: Thu, 8 Jun 2006 10:36:19 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Notifications for multiple devices per user References: <4486CC85.80400@isode.com> In-Reply-To: <4486CC85.80400@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Alexey Melnikov writes: > In my private discussion with Zoltan he raised a question about IMAP > server ability to store notification information (i.e. where the > notification is to be sent) for multiple devices per user. Is this > the requirement the WG wants to consider when thinking about > notifications? Isn't this a given? Noone stops using the desktop/laptop just because he gets a shiny new Nokia 770, so that's two devices already. Of couse some people might argue that a desktop/laptop has no need for notifications, but I wouldn't say so. People are too fond of little RAM-sucking desktop gadgets. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 08 04:43:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoG7F-0006En-D0; Thu, 08 Jun 2006 04:43:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoG6l-0005Sf-4C for lemonade@ietf.org; Thu, 08 Jun 2006 04:43:15 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoFvv-0002S4-Sv for lemonade@ietf.org; Thu, 08 Jun 2006 04:32:07 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k588W1G7024805 for ; Thu, 8 Jun 2006 11:32:02 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 11:31:28 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 11:31:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] draft-cook-lemonade-streaming-00.txt Date: Thu, 8 Jun 2006 11:31:13 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465738F2DB@esebe199.NOE.Nokia.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702F1A73C@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] draft-cook-lemonade-streaming-00.txt Thread-Index: AcZ7KvWhMH5SLE5+SIyxoTbAWZTn9gIUu9UAADN23uABokMg4A== From: To: X-OriginalArrivalTime: 08 Jun 2006 08:31:27.0691 (UTC) FILETIME=[EF77C9B0:01C68AD5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I think it's looking good and simple: we generate a URL withing the IMAP = session for the media, then client connects directly to media server to = start streaming. Comments/questions: - URLAUTH is RFC 4467 now, not a draft, so the reference should be = updated. - There is no mentioning of DRM. Should there be? Has it been = considered at all? Or we do not need to because we leave it up to the = client and the media server to sort it out? Can an IMAP server create an = authorized URL for a DRMed content without any problem? (I'm not an = expert on DRM, but I do know that it has been problematic in other = messaging systems). Thank You, a good draft once again. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Burger, Eric [mailto:eburger@cantata.com]=20 Sent: 31 May, 2006 03:48 To: Enhancements to Internet email to support diverse = serviceenivronments Subject: [lemonade] draft-cook-lemonade-streaming-00.txt Until it hits the archives, here is a copy of the outline for the = streaming services draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 08 05:52:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoHBy-0002MN-9Z; Thu, 08 Jun 2006 05:52:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoHBx-0002MD-7p for lemonade@ietf.org; Thu, 08 Jun 2006 05:52:41 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoHBv-0006sg-Na for lemonade@ietf.org; Thu, 08 Jun 2006 05:52:41 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k589qaTo028163; Thu, 8 Jun 2006 12:52:38 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 12:52:35 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 12:52:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Date: Thu, 8 Jun 2006 12:52:19 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465738F444@esebe199.NOE.Nokia.com> In-Reply-To: <4486B2FA.907@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Thread-Index: AcaKJHbj8Y67KjjgTaSgEH5IbuflXQAtgL4g From: To: , X-OriginalArrivalTime: 08 Jun 2006 09:52:34.0884 (UTC) FILETIME=[448A8040:01C68AE1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Thank You for the update Alexey, I have a few comments: - " state is deleted. While there is no required minimum expiration timeout, server implementations are encouraged to support as long a time as possible, subject to denial-of-service and related concerns." = This is something I have commented before. I do not know if the idea has = been discussed. It would be very beneficial for the client to know how = long the server keeps the sessions, even better if the client could = negotiate this setting. Has this been discussed during the interim? Was = there any conclusion? - " previous, active resumable session is available. If an active session is already available and a new one can be created, the" What = happens when a new session cannot be created? Who says it cannot be = created and why? What is the server/client behaviour if it could not be = created? - " In order to limit Denial of Service attacks a server = implementation SHOULD have a per-user limit on maximum number of resumable = sessions." If the server imposes such limit, what is the way to = communicate the number of current sessions and the limit to the client? - " server then checks the last known modification sequence." MODSEQ? - " [[anchor8: This section clearly assumes voluntarily disconnect]]" = should it be described instead having it as an anchor? It is already = described - except the voluntary part - so it could simply be removed. Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: 07 June, 2006 14:06 To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts = directories. >This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF. > > Title : IMAP4 Extensions for Quick Reconnect > Author(s) : C. Wilson, A. Melnikov > Filename : draft-ietf-lemonade-reconnect-07.txt > Pages : 24 > Date : 2006-6-6 >=09 >This document defines a quick reconnect IMAP4 extension, which gives a=20 >mobile client the ability to resume a previously abandoned session,=20 >without the need to perform a full synchronization sequence. The goal=20 >is to minimize the amount of data transfered at login after a dropped=20 >connection. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-07.tx >t > I believe this revision addresses all editorial comments from Dave and = Arnt. It also addresses most of the editorial comments from Randy. The too remaining non editorial issues (ABNF for LOGOUT parameters and = minimum number of per user sessions) were addressed as well. Alexey P.S. I've discovered some obsolete text in -07, which I removed from my = copy. I will do another revision if the document is to be sent to IESG. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 08 05:57:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoHGk-0006jz-9Q; Thu, 08 Jun 2006 05:57:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoHGj-0006ip-Oh for lemonade@ietf.org; Thu, 08 Jun 2006 05:57:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoGkF-0001Fx-Lk for lemonade@ietf.org; Thu, 08 Jun 2006 05:24:03 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoGLV-0002Gs-9w for lemonade@ietf.org; Thu, 08 Jun 2006 04:58:30 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k588wPPx020460 for ; Thu, 8 Jun 2006 11:58:27 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 11:58:25 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 11:58:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt Date: Thu, 8 Jun 2006 11:58:11 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465738F36E@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt Thread-Index: AcaKbDhOytIIioFxSSyhTSUeAE6IfQAa6nRQ From: To: X-OriginalArrivalTime: 08 Jun 2006 08:58:25.0923 (UTC) FILETIME=[B4026530:01C68AD9] X-Spam-Score: -2.6 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi all, A few comments/questions: - General: it is unclear which events will go to the clients and which = ones for admins (or both). Take OverQuota or Login as an example. = Perhaps the reason is that this draft is simply a collection of event = definitions without context? If so, it is fine, but then the bis (or the = notification draft needs to put each and every one of these into = context). - OverQuota and UnderQuota does not quite belong to "4.1. Message = Addition and Deletion" . Should we move it to "4.3. Access Accounting"? - Can we add more events? Like MailboxCreated (name), MailboxRenamed = (name, newname), MailboxDeleted (name), MailboxMoved (name, = targetmailbox)? - This is for 'folder' management, but there could be a = lot more. - Extension mechanism? (To define custom events and parameters when = needed?) Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20 Sent: 07 June, 2006 22:50 To: i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF. Title : Internet Message Store Events Author(s) : C. Newman Filename : draft-ietf-lemonade-msgevent-00.txt Pages : 14 Date : 2006-6-7 =09 One of the missing features in the existing Internet mail and messaging = standards is a facility for server-to-server and server-to- client event = notifications related to message store events. As the scope of Internet = mail expands to support more diverse media (such as voice mail), devices = (such as cell phones) and to provide rich interactions with other = services (such as web portals and legal compliance systems), the need = for an interoperable notification system increases. This document = attempts to enumerate the types of events which interest real-world = consumers of such a system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-00.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-msgevent-00.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-msgevent-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 08 18:03:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoSbG-0002AH-0y; Thu, 08 Jun 2006 18:03:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoSbF-0002A7-M2 for lemonade@ietf.org; Thu, 08 Jun 2006 18:03:33 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoSbE-0001CF-9q for lemonade@ietf.org; Thu, 08 Jun 2006 18:03:33 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k58M3FfO017745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Jun 2006 15:03:17 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k58M3Al9022713; Thu, 8 Jun 2006 15:03:13 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 8 Jun 2006 15:00:38 -0700 To: Arnt Gulbrandsen , "Stephane H. Maes" , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:41 PM +0200 5/31/06, Arnt Gulbrandsen wrote: > 1. APPEND/COPY. > > In section 1 and 8, APPEND and COPY are explicitly permitted on > vfolders. I think that's desirable, but there's a problem, perhaps > a nasty one: A client may expect that if it appends/copies a > message to a mailbox, that message shows up in that mailbox. If the > mailbox happens to be a vfolder and the message doesn't match the > search, the message may (apparently) disappear without a trace. > > There are three possibilities: Either the message must be made to > fit the search (e.g. by setting the right flags if the search uses > flags), or the search must be modified to include that message's > UID, or the WG considers it acceptable that the message sometimes > goes only to the backing mailbox, not to the vfolder. Personally, I > think the first two are horrid and strongly favour the latter, I'm > just a little nervous that it might confuse some IMAP clients. > > Section 8 should probably get a sentence or paragraph on this, once > there's consensus. > > 2. VFOLDER on VFOLDER. > > In section 2, a vfolders may be created with another vfolder as > backing. I don't see a use-case for that, and I do see one > drawback, namely that it complicates making a vfolder > "users.stephane.blah" with "users.stephane.*" as backing. The > present draft does not permit multi-mailbox backing, but I don't > expect that state of affairs to last very long. People want > multi-mailbox backing. More on that below. > > Can anyone think of a use-case or other argument for allowing > vfolders on vfolders? I think perhaps these two issues are related, with the core issue being: does a vfolder appear to a client as just another mailbox, or is it special in some way? If a vfolder is distinguishable from a regular mailbox, then perhaps it is OK to not use a vfolder as a backing store. In a non-list email exchange, Alexey suggested that if a vfolder is used as a backing mailbox, that the server would in reality make the search criteria the intersection of those of the new vfolder and the older vfolder. So, if: - mailbox TOP is a vfolder using mailbox MIDDLE as a backing store, and - mailbox MIDDLE is a vfolder using mailbox BOTTOM as a backing store, and - mailbox BOTTOM is a normal mailbox, Then allowing mailbox MIDDLE to be used as the backing store for vfolder TOP becomes just a short-hand for creating vfolder TOP using as its search criteria that of vfolder MIDDLE plus new elements. But after vfolder TOP is created, it would be seen to be using mailbox BOTTOM as its backing store. On the COPY/APPEND issue, if vfolders are distinguishable, then perhaps it is OK if a COPY/APPEND might seem to vanish. With UIDPLUS, perhaps the APPENDUID and COPYUID response codes might indicate the UID in the backing mailbox? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- yoin (yoh-EEN; Japanese; noun): experiential reverberation that continues to move one long after the initial external stimulus has ceased. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 08 18:48:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoTIV-0005q6-6q; Thu, 08 Jun 2006 18:48:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoTIT-0005q0-C7 for lemonade@ietf.org; Thu, 08 Jun 2006 18:48:13 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoTIS-0007A2-1K for lemonade@ietf.org; Thu, 08 Jun 2006 18:48:13 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k58Mm9oD018011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Jun 2006 15:48:10 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k58Mm7VG028633; Thu, 8 Jun 2006 15:48:09 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <01M34A0CUMZC0049K2@mauve.mrochek.com> References: <330A23D8336C0346B5C1A5BB1966664702F6D036@ATLANTIS.Brooktrout.com> <01M34A0CUMZC0049K2@mauve.mrochek.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 8 Jun 2006 15:47:46 -0700 To: Ned Freed From: Randall Gellens Subject: Re: [lemonade] COMPRESS Thoughts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I'd be happy if compression can not be disabled once it has been enabled, since that simplifies the extension, and in general simpler is better. Also, from talking to handset people I haven't yet heard that there would be a situation where you would want to turn off compression. That still leaves the question of directionality: I assume there are still good reasons why clients might want to enable server-to-client compression but not client-to-server (since doing so would force them to compress their commands)? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- You see, wire telegraph is a kind of very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates in exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat. --Albert Einstein _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 08 18:59:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoTTG-0002FR-N8; Thu, 08 Jun 2006 18:59:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoTTF-0002FM-B4 for lemonade@ietf.org; Thu, 08 Jun 2006 18:59:21 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoTTE-00080f-1E for lemonade@ietf.org; Thu, 08 Jun 2006 18:59:21 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FoTTC-0007E4-Eg; Thu, 08 Jun 2006 22:59:18 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 8E437498007; Fri, 9 Jun 2006 00:04:04 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04637-09; Fri, 9 Jun 2006 00:03:59 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 88670498006; Fri, 9 Jun 2006 00:03:59 +0100 (BST) Date: Thu, 08 Jun 2006 23:59:12 +0100 Subject: Re: [lemonade] COMPRESS Thoughts References: <330A23D8336C0346B5C1A5BB1966664702F6D036@ATLANTIS.Brooktrout.com> <01M34A0CUMZC0049K2@mauve.mrochek.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <16208.1149807553.116422@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Enhancements to Internet email to support diverse service enivronments , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Jun 8 23:47:46 2006, Randall Gellens wrote: > I'd be happy if compression can not be disabled once it has been > enabled, since that simplifies the extension, and in general > simpler is better. Also, from talking to handset people I haven't > yet heard that there would be a situation where you would want to > turn off compression. > > That still leaves the question of directionality: I assume there > are still good reasons why clients might want to enable > server-to-client compression but not client-to-server (since doing > so would force them to compress their commands)? As I understand things, for mobile handsets you basically always want to compress the upstream traffic, because it saves on radio transmission, which is a greater power drain than the CPU. You may wish to double-check that with handset people - please do, in fact. I wouldn't be entirely happy ruling out other highly resource constrained clients wanting to avoid upstream compression, though. Dave, -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 08 19:06:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoTaT-0000z6-Kf; Thu, 08 Jun 2006 19:06:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoTaS-0000z1-Bl for lemonade@ietf.org; Thu, 08 Jun 2006 19:06:48 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoTaR-0000bn-08 for lemonade@ietf.org; Thu, 08 Jun 2006 19:06:48 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k58N6fFo020022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Jun 2006 16:06:42 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k58N6ECD005066; Thu, 8 Jun 2006 16:06:41 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702F6D9F6@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664702F6D9F6@ATLANTIS.Brooktrout.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 8 Jun 2006 16:06:09 -0700 To: "Burger, Eric" , "Enhancements to Internet email to support diverse service enivronments" From: Randall Gellens Subject: Re: [lemonade] Draft Minutes, Both Days Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 10:20 PM -0400 6/1/06, Eric Burger wrote: > NOTIFICATIONS > ------------- > Issue: Server-to-Server (S2S) text in draft does not bind the messages > to a transport protocol. Is this OK? > Discussion: Might not want to make a binding, so the server can natively > interface with SIMPLE Server, XMPP Server, SMSC, MMSC, etc. > Rejoinder: Some folks do not care about mobile notifications and even if > they do they do not want to have to implement a bunch of notification > server protocols. > Resolution: We will choose a single transport binding. Stephane will > provide text in next revision of NOTIFICATIONS draft, due June 19. > > Issue: Should lemonade S2S document be explicitly limited to lemonade / > messaging environments? > Discussion: Do not want to boil the ocean - generic notifications are a > BIG computer science problem. Moreover, the whole reason for having a > lemonade S2S document is for the purposes of having a baseline, > easy-to-implement protocol for lemonade servers to use. > Resolution: Randy and Stephane will provide appropriate text, by June > 19. My notes indicate that there are to be two notification drafts: one for the format (payload), and one for the mandatory-to-implement protocol. (I agreed to co-author the second.) Did I misunderstand, and there is supposed to be only one draft covering both? > DEPLOYMENTS > ----------- > Issue: Dave was going to supply figures for reconnection costs. > Resolution: Dave WILL supply figures for reconnection costs. I haven't seen text from Dave yet, and I sent in a revision which can go to WGLC. If Dave has figures at hand they can be added during WGLC, otherwise they can go into deployments-bis. > Issue: Current draft references Profile-bis and NOTIFICATIONS > Discussion: They will hold up publication. > Discussion: What about TCP-Challenged Environments? > Resolution: Drop NOTIFICATIONS, don't reference TCP-Challenged, and > reference Profile. Put them back when we do DEPLOYMENTS-bis. Update by > June 9. The document will be ready for WGLC at that point. Actually, the then-current draft did not reference notifications, but did reference profile-bis. The resolution was to reference profile instead of profile-bis, and to not add notifications or tcp-challenged until deployments-bis. I sent in an updated draft that is ready for WGLC. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- People demand freedom of speech to make up for the freedom of thought which they avoid. --Kierkegaard _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 08 19:35:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoU2M-0003X2-Th; Thu, 08 Jun 2006 19:35:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoU2L-0003VI-Af for lemonade@ietf.org; Thu, 08 Jun 2006 19:35:37 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoU2I-0004UN-Us for lemonade@ietf.org; Thu, 08 Jun 2006 19:35:37 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k58NZR5Q025254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Jun 2006 16:35:28 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k58NZ9Lk013212; Thu, 8 Jun 2006 16:35:26 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <16208.1149807553.116422@peirce.dave.cridland.net> References: <330A23D8336C0346B5C1A5BB1966664702F6D036@ATLANTIS.Brooktrout.com> <01M34A0CUMZC0049K2@mauve.mrochek.com> <16208.1149807553.116422@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 8 Jun 2006 16:34:03 -0700 To: Dave Cridland From: Randall Gellens Subject: Re: [lemonade] COMPRESS Thoughts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Enhancements to Internet email to support diverse service enivronments , Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:59 PM +0100 6/8/06, Dave Cridland wrote: > On Thu Jun 8 23:47:46 2006, Randall Gellens wrote: >> I'd be happy if compression can not be disabled once it has been >> enabled, since that simplifies the extension, and in general >> simpler is better. Also, from talking to handset people I haven't >> yet heard that there would be a situation where you would want to >> turn off compression. >> >> That still leaves the question of directionality: I assume there >> are still good reasons why clients might want to enable >> server-to-client compression but not client-to-server (since doing >> so would force them to compress their commands)? > > As I understand things, for mobile handsets you basically always > want to compress the upstream traffic, because it saves on radio > transmission, which is a greater power drain than the CPU. > > You may wish to double-check that with handset people - please do, in fact. I just ran this by some other handset people, and got confirmation that, for a handset, compression is always a win. I was told that even receiving radio transmission uses more power than decompressing the power (assuming the compression engine gets out of the way for already-compressed data). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- You are wise, witty, and wonderful, but you spend too much time reading this sort of trash. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 09 04:36:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FocTh-0006ez-Gp; Fri, 09 Jun 2006 04:36:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FocTg-0006eu-U5 for lemonade@ietf.org; Fri, 09 Jun 2006 04:36:24 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FocTf-0003FC-KP for lemonade@ietf.org; Fri, 09 Jun 2006 04:36:24 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FocTe-0007yM-3T; Fri, 09 Jun 2006 08:36:22 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 390A7498007; Fri, 9 Jun 2006 09:41:12 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07711-02; Fri, 9 Jun 2006 09:41:01 +0100 (BST) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:ad2d:76f1:cb21:f122]) by turner.dave.cridland.net (Postfix) with ESMTP id DD201498006; Fri, 9 Jun 2006 09:41:01 +0100 (BST) Date: Fri, 09 Jun 2006 09:36:07 +0100 Subject: Re: [lemonade] Draft Minutes, Both Days References: <330A23D8336C0346B5C1A5BB1966664702F6D9F6@ATLANTIS.Brooktrout.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <284.1149842168.612000@JOHN> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri Jun 09 00:06:09 2006, Randall Gellens wrote: > At 10:20 PM -0400 6/1/06, Eric Burger wrote: >> Issue: Dave was going to supply figures for reconnection costs. >> Resolution: Dave WILL supply figures for reconnection costs. > > I haven't seen text from Dave yet, and I sent in a revision which > can go to WGLC. If Dave has figures at hand they can be added > during WGLC, otherwise they can go into deployments-bis. > > I have one feature I need to ensure works properly - specifically, TLS session resumption stuff - then I need to settle down with ethereal and Polymer's debug mode and count octets, carefully disabling any extension not in Profile. I'll do this before Monday. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 09 07:35:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FofGs-0000Te-IU; Fri, 09 Jun 2006 07:35:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FofGq-0000TY-WF for lemonade@ietf.org; Fri, 09 Jun 2006 07:35:21 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FofGp-0000Hy-HW for lemonade@ietf.org; Fri, 09 Jun 2006 07:35:20 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 9 Jun 2006 12:35:01 +0100 Message-ID: <44895CE1.1050007@isode.com> Date: Fri, 09 Jun 2006 12:34:57 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randall Gellens Subject: Re: [lemonade] Draft Minutes, Both Days References: <330A23D8336C0346B5C1A5BB1966664702F6D9F6@ATLANTIS.Brooktrout.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: support diverse service enivronments , Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > At 10:20 PM -0400 6/1/06, Eric Burger wrote: > >> NOTIFICATIONS >> ------------- > [...] >> Issue: Should lemonade S2S document be explicitly limited to lemonade / >> messaging environments? >> Discussion: Do not want to boil the ocean - generic notifications are a >> BIG computer science problem. Moreover, the whole reason for having a >> lemonade S2S document is for the purposes of having a baseline, >> easy-to-implement protocol for lemonade servers to use. >> Resolution: Randy and Stephane will provide appropriate text, by June >> 19. > > My notes indicate that there are to be two notification drafts: one > for the format (payload), and one for the mandatory-to-implement > protocol. (I agreed to co-author the second.) Did I misunderstand, > and there is supposed to be only one draft covering both? I would prefer to have 2 documents. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 09 15:32:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FomiY-0007Rz-IO; Fri, 09 Jun 2006 15:32:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FomiX-0007Rt-1Z for lemonade@ietf.org; Fri, 09 Jun 2006 15:32:25 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FomiV-0000gk-KS for lemonade@ietf.org; Fri, 09 Jun 2006 15:32:25 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k59JWL9o009670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jun 2006 12:32:22 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k59JWIAN013948; Fri, 9 Jun 2006 12:32:20 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44842B8F.20908@isode.com> References: <0FA975F2D8295A448BE3ADC161244657323A68@esebe199.NOE.Nokia.com> <44842B8F.20908@isode.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 9 Jun 2006 12:30:20 -0700 To: Alexey Melnikov , Zoltan.Ordogh@nokia.com From: Randall Gellens Subject: Re: [lemonade] Question on 'Sent Items' deposit Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 2:03 PM +0100 6/5/06, Alexey Melnikov wrote: > Zoltan.Ordogh@nokia.com wrote: > >> Hi Dave, >> thank You. >> >> Yes, I certainly would like to have it in the profile. >> From "The FCC problem" I did not quite get the idea - I am not >> familiar with the term. >> I would prefer describing it more detail in bis. >> > FCC is "file carbon copy", a term used in several Mail User Agents > to describe saving a copy of a sent message into a mailbox (which > is usually a file). > Somebody who has been around for longer might be better in explaining this. I'll take a shot: Long, long ago, in the dim, dark ages before we all had computers on our desks (much less in our pockets), people who worked in offices used a form of written communication called a "memo". It was often used for one-to-one or one-to-many or even few-to-many communication within a company (more often, actual letters were used to communicate outside the company). The memo typically was typed onto a form that was divided into a heading and the body. The heading listed the names of the recipients and the author(s), as well as a subject. The recipients were subdivided into those the memo was being sent to, and others who were being sent a copy for their information. Usually the implication was that those it was being sent to were expected to take some sort of action, while those only receiving a copy were merely being informed as a courtesy. (But there were many political games that were played regarding just whose name appeared and where.). This was in the days before routine photocopy machines, so the manner in which copies were produced was interesting: multiple sheets of paper were stacked, interleaved with sheets of something called 'carbon paper'. This 'carbon paper' was an extremely thin sheet of paper coated on one side with carbon. If it was in between two sheets of paper, then anything written or typed on the top sheet would be also appear on the second sheet, by virtue of the force of the writing or typing pressing the carbon onto the second sheet. (Multiple sets of carbon paper and plain paper could be used together, to produce the desired number of copies. However, because the physical pressure of the typing (or writing) was needed to produce each copy, and needed to be transferred through each preceding copy, there were limits to how many copies could be produced. Each successive copy was fainter than the one before.) Because of the technology used, those being sent a copy were referred to as "carbon copy recipients" or "cc" recipients. When email was developed it naturally used the memo as a model. Hence we still use the term "cc". (Those being sent a copy without the knowledge of the others are referred to as "blind carbon copy" recipients or "bcc".) > >> So, You are saying it can be done. >> Now, is the UID the same in all messages >> > No, IMAP server will create a separate UID (unique identifier) for > each message. > >> - to guarantee that the client does not download the newly >> deposited message from the "Sent items" box? >> > UIDPLUS extension addresses this issue. When the client > uploads/constructs a message with APPEND, the server returns the > APPENDUID response code, which tells the client UID of the created > message. This is exactly to avoid the need for the client to > download the message it just uploaded. > This is shown in the example in section 2.4.1. Note that the client will first create the message using APPEND (perhaps with CATENATE to help with assembly). It then receives the UID via APPENDUID, and then uses this UID to have a URLAUTH constructed. It then uses the URLAUTH to send the message via BURL. The key here to answering your question is that the client of necessity knows the UID of the appended message. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Wealth is not only money. Wealth can be happiness in your sweetheart or your honey. --(Fortune cookie) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 09 15:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fomzf-0004yf-WC; Fri, 09 Jun 2006 15:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fomzb-0004xL-3t; Fri, 09 Jun 2006 15:50:03 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FomzZ-0003Jk-PC; Fri, 09 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k59Jo1Rx031450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FomzZ-0005yV-DG; Fri, 09 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 09 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-03.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Deployment Considerations for lemonade-compliant Mobile Email Author(s) : R. Gellens Filename : draft-ietf-lemonade-deployments-03.txt Pages : 11 Date : 2006-6-9 This document discusses deployment issues and describes requirements for successful deployment of mobile email which are implicit in the IETF lemonade documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-deployments-03.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-lemonade-deployments-03.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: <2006-6-9110926.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-deployments-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-deployments-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-9110926.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Fri Jun 09 19:44:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foqed-0006B5-Ly; Fri, 09 Jun 2006 19:44:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foqec-000692-R7 for lemonade@ietf.org; Fri, 09 Jun 2006 19:44:38 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foqeb-00012b-GB for lemonade@ietf.org; Fri, 09 Jun 2006 19:44:38 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k59NiVo9002109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jun 2006 16:44:32 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k59NiSX1002452; Fri, 9 Jun 2006 16:44:30 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20060601070749343.00000000428@smaes-lap3> <72FDD20C56FDCB399E7AAF41@Cyrus-Daboo.local> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 9 Jun 2006 16:42:48 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [Lemonade] Discussion items from thsimorning on VFOLDER and WITHIN Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:10 PM +0200 6/2/06, Arnt Gulbrandsen wrote: > A third solution, which I thought of only when I read your message, > is to add a new SELECT response with the backing mailbox and > uidvalidity > > * OK [BACKINGMAILBOX mailbox nz-number] if you hafta ask... > > and a new FETCH OUID to retrieve just the UID in that mailbox. > > That saves traffic if the client saves just 1% of the > (body[header.fields(...)] body[1]) fetches, perhaps even if it > saves 0.1%. For a client which issues FETCH OUID, that's not a bad > bet. > > Of course, this is troublesome wrt. vfolder-on-vfolder and also > wrt. multi-mailbox vfolders. Alexey pointed out (in a non-list discussion) that vfolder-on-vfolder can be done by storing the union of the selection criteria, meaning that there is really no such thing; that is, a vfolder-on-vfolder request is really just a client shortcut in creating a vfolder on top of a real mailbox. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The earth is like a tiny grain of sand, only much, much heavier. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 09 20:19:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ForCZ-0001CK-7x; Fri, 09 Jun 2006 20:19:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ForCY-0001CF-Bw for lemonade@ietf.org; Fri, 09 Jun 2006 20:19:42 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ForCX-0004lQ-1R for lemonade@ietf.org; Fri, 09 Jun 2006 20:19:42 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5A0JZYo005217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jun 2006 17:19:36 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5A0JSYc011842; Fri, 9 Jun 2006 17:19:32 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 9 Jun 2006 17:19:22 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 6:19 PM +0200 6/2/06, Arnt Gulbrandsen wrote: >> As one who implements these drafts, this is a pain. Tracking UID >> and assigning new UID when a message comes back into focus means >> you have to assign message new UID for each message in a VFOLDER. >> Not a very virtual folder to me. > > Yes. Agreed. I currently store name, owner, ACL, two UIDNEXT > values, a search expression and a bunch of uid+uid pairs. Storing > less would be desirable. But how? The only possibilities I can > think of have worse consequences, e.g. blocking the way to > multi-mailbox vfolders. If there was only one backing mailbox, then maybe you could use the real UID as the UID in the vfolder. I'm bothered by the idea of messages going in and out of view and getting a new UID each time. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Resistance is Useless! (If less than one ohm.) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 09 20:38:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ForUY-000468-Pk; Fri, 09 Jun 2006 20:38:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ForUX-000460-Eh for lemonade@ietf.org; Fri, 09 Jun 2006 20:38:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoqmP-0001ma-Dm for lemonade@ietf.org; Fri, 09 Jun 2006 19:52:41 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoqaX-0001jR-Nk for lemonade@ietf.org; Fri, 09 Jun 2006 19:40:27 -0400 Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 90CDA142301; Fri, 9 Jun 2006 16:40:24 -0700 (PDT) In-Reply-To: <4486CC85.80400@isode.com> References: <4486CC85.80400@isode.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7ED1AE38-5BA6-4100-B072-07B1397C8E95@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [lemonade] Notifications for multiple devices per user Date: Fri, 9 Jun 2006 16:40:22 -0700 To: Alexey Melnikov X-Mailer: Apple Mail (2.750) X-Spam-Score: -2.6 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org There's an alternative architecture for the same use case, and that's to let the notification server (SIP or XMPP, in particular) do fanout. Then the IMAP server simply sends the notification to the user's notification address (plus some application field if specified) and the user decides which devices subscribe to those notifications. I could be wrong but I think some of those kinds of servers can gateway to SMS so that would even work in. lisa On Jun 7, 2006, at 5:54 AM, Alexey Melnikov wrote: > In my private discussion with Zoltan he raised a question about > IMAP server ability to store notification information (i.e. where > the notification is to be sent) for multiple devices per user. Is > this the requirement the WG wants to consider when thinking about > notifications? > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 09 20:45:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Forbd-0003ot-Ia; Fri, 09 Jun 2006 20:45:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Forbc-0003hz-72 for lemonade@ietf.org; Fri, 09 Jun 2006 20:45:36 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Forba-0000la-S1 for lemonade@ietf.org; Fri, 09 Jun 2006 20:45:36 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5A0jXp8005194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 9 Jun 2006 17:45:33 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5A0jTJA020160 for ; Fri, 9 Jun 2006 17:45:30 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <8863.1149687841.064414@peirce.dave.cridland.net> <8863.1149687945.612394@peirce.dave.cridland.net> References: <0FA975F2D8295A448BE3ADC16124465738EB31@esebe199.NOE.Nokia.com> <4486B40D.8040201@isode.com> <8863.1149687841.064414@peirce.dave.cridland.net> <0FA975F2D8295A448BE3ADC16124465738ED04@esebe199.NOE.Nokia.com> <4486C57E.30001@isode.com> <4FD6E8A97358AC98A137776C@Cyrus-Daboo.local> <8863.1149687945.612394@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 9 Jun 2006 17:45:23 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Use of \Draft flag to indicate message ready forsubmission Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 2:43 PM +0100 6/7/06, Dave Cridland wrote: > $Pending - "The message is intended to be sent, but has not yet > been submitted. Clients MUST NOT automatically send the message > without user interaction." > > That latter proscription to both allow uses other than purely > staging a message for immediate send, and prevent it from turning > into an ill-advised IMAP-based submission mechanism. I'd assume > that a client starting up might note the presence of $Pending > messages and offer to send them, however. I was going to suggest $pending, so I like your proposal of it. At 2:45 PM +0100 6/7/06, Dave Cridland wrote: > On Wed Jun 7 13:57:31 2006, Cyrus Daboo wrote: >> Actually, profilebis is using the \Draft flag (or rather the >> absence of the draft flag) as an indicator that the message was >> sent ... So with both \Draft and $Pending, we'd have a state transition of something like: New message is created on server with \Draft flag. User has started composition. User presses 'send' button. Client removes \Draft and sets $Pending. Client receives OK from submit server that message has been sent. Client removes $Pending. >> ...snip... >> ... I think what we actually want is a $Sent flag that the client >> can set once its fully completed the submission of the message. A $Sent flag would then be an optional state indicator that the message was successfully sent. The absence of any flag could not be used to know for sure that a message had been sent, but it would indicate that the message was not an active draft nor a pending message in use by a lemonade client. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There's nothing wrong with me. Maybe there's something wrong with the universe. --'Dr. Beverly Crusher' in ST:TNG _Remember Me_. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 09 20:48:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ForeW-0005nX-1M; Fri, 09 Jun 2006 20:48:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ForeU-0005l7-Ec for lemonade@ietf.org; Fri, 09 Jun 2006 20:48:34 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ForeT-0000xf-4H for lemonade@ietf.org; Fri, 09 Jun 2006 20:48:34 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5A0mUrL007079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jun 2006 17:48:31 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5A0mQ6f017837; Fri, 9 Jun 2006 17:48:29 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4486B2FA.907@isode.com> References: <4486B2FA.907@isode.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 9 Jun 2006 17:46:59 -0700 To: Alexey Melnikov , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:05 PM +0100 6/7/06, Alexey Melnikov wrote: > I believe this revision addresses all editorial comments from Dave > and Arnt. It also addresses most of the editorial comments from > Randy. Which editorial comments remain? (I was going to do a diff against -06 and check against my email, but if you have a list that is much easier) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Implementation is the sincerest form of flattery. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 09 20:57:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FornI-0005aY-9A; Fri, 09 Jun 2006 20:57:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FornG-0005Z2-KC for lemonade@ietf.org; Fri, 09 Jun 2006 20:57:38 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FornF-0002Nd-8p for lemonade@ietf.org; Fri, 09 Jun 2006 20:57:38 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5A0vZ9d007490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jun 2006 17:57:35 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5A0vV8v007921; Fri, 9 Jun 2006 17:57:34 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0FA975F2D8295A448BE3ADC161244657323A68@esebe199.NOE.Nokia.com> <44842B8F.20908@isode.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 9 Jun 2006 17:55:45 -0700 To: Alexey Melnikov , Zoltan.Ordogh@nokia.com From: Randall Gellens Subject: Re: [lemonade] Question on 'Sent Items' deposit Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:30 PM -0700 6/9/06, I wrote: > Long, long ago, in the dim, dark ages before we all had computers > on our desks (much less in our pockets), people who worked in > offices used a form of written communication called a "memo". By the way, one can learn all about this sort of ancient ritual from watching old movies and TV shows. It seems that in those days, almost anyone above the clerk level had his or her (but mostly his) own office that included a bar. When visitors dropped in to discuss business, drinks were consumed. In addition to an office complete with bar, a secretary was provided for his (or her) exclusive use. The secretary typed up letters and memos and filed them. Even though it seemed to take much longer, the person wishing to send a memo never typed it himself (or herself) but instead always summoned the secretary, composed it off the cuff aloud, then waited for the secretary to type it up. There were then rounds of edits. Seems very time-consuming to us! -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- In the beginning was the word...and it was the wrong length. --Bob Barton (Burroughs computer architect) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 09 21:05:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Forua-0001oi-Li; Fri, 09 Jun 2006 21:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ForuZ-0001od-Td for lemonade@ietf.org; Fri, 09 Jun 2006 21:05:11 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ForuY-0003ED-HS for lemonade@ietf.org; Fri, 09 Jun 2006 21:05:11 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5A158UK007104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jun 2006 18:05:09 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5A1562Y019912; Fri, 9 Jun 2006 18:05:07 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <7ED1AE38-5BA6-4100-B072-07B1397C8E95@osafoundation.org> References: <4486CC85.80400@isode.com> <7ED1AE38-5BA6-4100-B072-07B1397C8E95@osafoundation.org> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 9 Jun 2006 17:59:15 -0700 To: Lisa Dusseault , Alexey Melnikov From: Randall Gellens Subject: Re: [lemonade] Notifications for multiple devices per user Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 4:40 PM -0700 6/9/06, Lisa Dusseault wrote: > There's an alternative architecture for the same use case, and > that's to let the notification server (SIP or XMPP, in particular) > do fanout. Then the IMAP server simply sends the notification to > the user's notification address (plus some application field if > specified) and the user decides which devices subscribe to those > notifications. > > I could be wrong but I think some of those kinds of servers can > gateway to SMS so that would even work in. > > lisa > > On Jun 7, 2006, at 5:54 AM, Alexey Melnikov wrote: > >> In my private discussion with Zoltan he raised a question about >> IMAP server ability to store notification information (i.e. where >> the notification is to be sent) for multiple devices per user. Is >> this the requirement the WG wants to consider when thinking about >> notifications? Depending on the device capability, it is conceivable that the user might want different criteria. So the more capable the device, the more state changes and new messages it is aware of, but the more limited devices would only know about the most urgent messages. I had been thinking that this would be handled by Sieve, with various rules sending notifications to different devices. This would imply that the rules would need to be updated as devices change. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Chance that an American cannot name a single right protected by the First Amendment: 1 in 3. (Harper's Index) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 09 21:55:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fosh7-0000dD-RL; Fri, 09 Jun 2006 21:55:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fosh6-0000d8-Mz for lemonade@ietf.org; Fri, 09 Jun 2006 21:55:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ForZm-0000Ob-Tj for lemonade@ietf.org; Fri, 09 Jun 2006 20:43:42 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ForN9-0002Fx-Bx for lemonade@ietf.org; Fri, 09 Jun 2006 20:30:41 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5A0UYQ6005870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jun 2006 17:30:34 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5A0UV1t012497; Fri, 9 Jun 2006 17:30:32 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 9 Jun 2006 17:22:09 -0700 To: Curtis King , Arnt Gulbrandsen From: Randall Gellens Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: -2.6 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 2:15 PM -0600 6/2/06, Curtis King wrote: > I doubt know if you can, but servers are being force to store more > information for a VFOLDER than a real mailbox. That just doesn't > seem like the right design. > > Why not have named searches which can be used as FILTERS when > selecting a mailbox to provide the desired view? Clients can handle > an UID going out and in of view because they will expect that > behavior. I think there was a draft along these lines a few years ago. From Cyrus maybe? > For things like multi-mailbox vfolders why not use a named search > and copy to populate a new mailbox from the source mailboxes? This > may require some extensions to search and some way of storing the > last uid used int the search. Now, the clients can decide when to > update the mailbox and what messages and flags are synchronized > between the mailboxes. > > This isn't any more work than vfolder, but you can sure do more with it. Copying feels like the wrong approach (although some servers may have mail stores that allow them to populate the new mailbox with pointers to the original message, along with reference counts to handle deletion). What about servers that would have to actually do a copy? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- When news of Alexander Graham Bell's invention reached the United Kingdom, the chief engineer of the British Post Office failed to be impressed. "The Americans," he said loftily, "have need of the telephone -- but we do not. We have plenty of messenger boys..." _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Jun 10 19:49:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpDCc-0007bJ-FR; Sat, 10 Jun 2006 19:49:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpDCa-0007b9-W4 for lemonade@ietf.org; Sat, 10 Jun 2006 19:49:12 -0400 Received: from mail2.panix.com ([166.84.1.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpDCZ-0003JK-P6 for lemonade@ietf.org; Sat, 10 Jun 2006 19:49:12 -0400 Received: from mailspool3.panix.com (mailspool3.panix.com [166.84.1.78]) by mail2.panix.com (Postfix) with ESMTP id 6FD419D88F for ; Sat, 10 Jun 2006 19:49:07 -0400 (EDT) Received: from [192.168.1.11] (ool-45749fe3.dyn.optonline.net [69.116.159.227]) by mailspool3.panix.com (Postfix) with ESMTP id A8650C371C0 for ; Sat, 10 Jun 2006 19:49:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: Message-Id: In-Reply-To: References: <0FA975F2D8295A448BE3ADC161244657323A68@esebe199.NOE.Nokia.com> <44842B8F.20908@isode.com> X-Mailer: Eudora for Mac OS X 6.2.3 (MacOS 10.3) Date: Sat, 10 Jun 2006 16:40:07 -0400 To: lemonade@ietf.org From: "Robert A. Rosenberg" Subject: Re: [lemonade] Question on 'Sent Items' deposit Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:30 -0700 on 06/09/2006, Randall Gellens wrote about Re: [lemonade] Question on 'Sent Items' deposit: >When email was developed it naturally used the memo as a model. >Hence we still use the term "cc". (Those being sent a copy without >the knowledge of the others are referred to as "blind carbon copy" >recipients or "bcc".) In Email usage, the first C in Cc and Bcc represents Courtesy not the old Carbon (although the Carbon is often used for historical/homage purposes). To add to the historical description of memos in the prior message, I will add that when Photocopies came into use, the names in the Cc were often replaced with a group description of why they were getting a copy (ie: Department A, Department B, etc.) with a separate list of Who was in that Group and thus would get a copy. For Email this became the Group Nickname/Persona which when listed would either expand into a list of the members of that Group or would be a mailing address that would (via a .forward list) echo the incoming message to the relevant email addresses. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Jun 11 19:08:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZ2z-0006ls-TB; Sun, 11 Jun 2006 19:08:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZ2x-0006lg-R1 for lemonade@ietf.org; Sun, 11 Jun 2006 19:08:43 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZ2t-0001p8-Jr for lemonade@ietf.org; Sun, 11 Jun 2006 19:08:43 -0400 X-IronPort-AV: i="4.05,228,1146456000"; d="scan'208"; a="34001571:sNHT35489012" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Jun 2006 19:08:37 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470303B15A@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LEMONADE - Requested sessions have been scheduled for IETF 66 Thread-Index: AcaNm5K2C3wwZqxdTryWyDdZ8dQ9lAAEEh1Q From: "Burger, Eric" To: "Enhancements to Internet email to support diverse service enivronments" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [lemonade] FW: LEMONADE - Requested sessions have been scheduled for IETF 66 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Of course, subject to change with little notice, but here is our first pass at a schedule. -----Original Message----- From: IETF Secretariat [mailto:agenda@ietf.org]=20 Sent: Sunday, June 11, 2006 5:10 PM To: Burger, Eric Dear Eric Burger, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by=20 the information of sessions that you have requested. LEMONADE Session 1 (2 hours) Monday, Afternoon Session II 1520-1720 Room Name: Room 513B ---------------------------------------------- LEMONADE Session 2 (2 hours) Tuesday, Afternoon Session I 1300-1500 Room Name: Room 513B ---------------------------------------------- _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 12 05:42:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpivq-0008Uq-Qh; Mon, 12 Jun 2006 05:42:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpivp-0008U7-J5 for lemonade@ietf.org; Mon, 12 Jun 2006 05:42:01 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpivl-0001zh-2I for lemonade@ietf.org; Mon, 12 Jun 2006 05:42:01 -0400 Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 12 Jun 2006 10:41:38 +0100 Message-ID: <448C275F.4080602@isode.com> Date: Sun, 11 Jun 2006 15:23:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt References: <4486B2FA.907@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > At 12:05 PM +0100 6/7/06, Alexey Melnikov wrote: > >> I believe this revision addresses all editorial comments from Dave >> and Arnt. It also addresses most of the editorial comments from Randy. > > Which editorial comments remain? (I was going to do a diff against > -06 and check against my email, but if you have a list that is much > easier) I have not addressed the following issues (I am still thinking if they should be addressed and how): Randall Gellens wrote: > Section 3.2: > If the provided UIDVALIDITY doesn't match the UIDVALIDITY > for the currently selected mailbox, the server MUST send the NEWSID > response containing the SID of the resumed session. > > Maybe add clarifying text to say that the NEWSID response contains the > same SID, that is, that the server doesn't abandon the resumed SID and > generate a new one? > Section 3.2: > Example: Resuming an old session in selected state with the INBOX > selected, but where the server could not cache all the events since > the specified modification sequence. The server sends the NEWSID > response, which means that the client should perform full > resynchronization. > > Might be good to note that in this example the server elected to > generate a new SID (since as I understand the text the server can also > keep the same SID). > > Section 3.2: > Example: Resuming an old session in selected state with the mailbox > Drafts selected, but the mailbox was deleted and another one was > renamed to become Drafts, while the client was offline. The server > chooses to keep the Drafts mailbox open, however it sends the NEWSID > response, which means that the client should perform full > resynchronization. > > C: A02 SID Frt-egf-779 6896834 11 20:35 > S: * NEWSID Frt-egf-779 > S: * FOLDER Drafts > S: * OK [UIDVALIDITY 1098183472] Current UIDValidity > S: * OK [UIDNEXT 12] Next available UID > S: * OK [HIGHESTMODSEQ 54] S: * 7 EXISTS > S: * 0 RECENT > S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) > S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft > \Deleted \Seen \*)] Permanent flags > S: A02 OK [READ-WRITE] session created > > Nit: Since the server elected to reuse the same SID, maybe the server > should say "session resumed" instead of "session created"? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 12 05:42:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpivv-00006H-0T; Mon, 12 Jun 2006 05:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpivu-00006C-7q for lemonade@ietf.org; Mon, 12 Jun 2006 05:42:06 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpivp-0001zh-Ln for lemonade@ietf.org; Mon, 12 Jun 2006 05:42:06 -0400 Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 12 Jun 2006 10:41:46 +0100 Message-ID: <448C72A1.2010706@isode.com> Date: Sun, 11 Jun 2006 20:44:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt References: <0FA975F2D8295A448BE3ADC16124465738F444@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC16124465738F444@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan.Ordogh@nokia.com wrote: >Thank You for the update Alexey, >I have a few comments: > - " state is deleted. While there is no required minimum expiration > timeout, server implementations are encouraged to support as long a > time as possible, subject to denial-of-service and related concerns." This is something I have commented before. I do not know if the idea has been discussed. It would be very beneficial for the client to know how long the server keeps the sessions, even better if the client could negotiate this setting. Has this been discussed during the interim? > No it hasn't. I've read both your message and Randy's reply to it. I think Randy argued against the need for the server to advertise/be able to change any limit. If you disagree, can you please reply to Randy's message and we will continue the discussion. >Was there any conclusion? > - " previous, active resumable session is available. If an active > session is already available and a new one can be created, the" What happens when a new session cannot be created? > The server would reply NO and the current active session remains active. I guess this can be spelled out in the document. >Who says it cannot be created and why? > Server can have a policy limiting number of available sessions per user, per IP or other factors. This can be done in order to limit DoS attacks. Server can have a global limit on number of sessions it can serve. At the end this is dictated by available resources. >What is the server/client behaviour if it could not be created? > > Client needs to fallback to using regular IMAP, as if the quick reconnect extension is not available. In theory the client can do something differently if it expects, say, 3 resumable sessions and only got 2. > - " In order to limit Denial of Service attacks a server implementation > SHOULD have a per-user limit on maximum number of resumable sessions." If the server imposes such limit, what is the way to communicate the number of current sessions and the limit to the client? > > There is currently no way to communicate the number of sessions available to a user. This was discussed during the recent interim and Eric convinced me that a). specifying any limit in the document wouldn't help, as multiple clients acting on behalf of a single user would be able to exceed any limit. b). advertising any limit (or remaining number of sessions) would not help, as there is a race condition between the moment when the server advertises the remaining number and the moment when the client can create a new session. So the client would have to be able to deal with server saying "I can't create any more sessions" anyway. > - " server then checks the last known modification sequence." MODSEQ? > > Yes. > - " [[anchor8: This section clearly assumes voluntarily disconnect]]" should it be described instead having it as an anchor? It is already described - except the voluntary part - so it could simply be removed. > > Yes, this will be deleted. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 12 05:42:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpiwV-0000Ko-8R; Mon, 12 Jun 2006 05:42:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpiwT-0000Kj-Gs for lemonade@ietf.org; Mon, 12 Jun 2006 05:42:41 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpiwO-00020x-Uj for lemonade@ietf.org; Mon, 12 Jun 2006 05:42:41 -0400 Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 12 Jun 2006 10:42:15 +0100 Message-ID: <448C801B.1010207@isode.com> Date: Sun, 11 Jun 2006 21:42:03 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randall Gellens Subject: Re: [lemonade] Notifications References: <0FA975F2D8295A448BE3ADC1612446570C6DD4@esebe199.NOE.Nokia.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable X-Encoded: Changed encoding from 8bit for 7bit transmission X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: lemonade@ietf.org, Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > At 11:25 AM +0300 5/26/06, wrote: > >> -----Original Message----- >> From: ext Randall Gellens [mailto:randy@qualcomm.com] >> Sent: 25 May, 2006 04:45 >> To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); dave@cridland.net; = >> lemonade@ietf.org >> Subject: RE: [lemonade] Notifications >> >> At 12:09 PM +0300 5/22/06, wrote: >> >>> My understanding is that SIEVE or VFOLDER are simply filters - they >>> do not provide notifications, they simply filter which emails need to >>> be notified to the client (either online or offline) and if something >>> has passed the filter, the server will send the notification about >>> those emails that passed the filters. >> >> Not exactly. Sieve has rules that trigger actions. One of the = >> actions can be to send a notification. >> >> [Z=D6r] SIEVE is responsible for triggering the notification only - = >> not for sending it, right? > > My understanding is that the Sieve implementation will send = > notifications. Sieve extensions are used to indicate that a = > notification is to be sent. How it is sent will depend on the Sieve = > implementation, for example, it might support SMS. The current Sieve notifications draft include URI that would describe = how notification is to be sent (i.e. SMS notifications would use SMS URI) Some Sieve implementations might try to send notifications while = executing the script. Others would note that a notification is to be sent and will try to send = it later. >>> So, in the end, when an email has passed the notification filters, >>> the server will check whether the client is online or offline. If >>> online: no problem with inband notification; if offline: the server >>> will look up the client's offline notification settings, and send the >>> notification accordingly. >> >> I'm not aware that Sieve has any knowledge of the connected state of = >> any client. My understanding is that Sieve rules might say "send = >> notification to address foo", regardless if a client at address foo = >> happens to be connected to the IMAP server at that moment. >> >> [Z=D6r] SIEVE triggers the notification only, isn't it? When the = >> server is told that some mail needs to be notified, the server will = >> check the online/offline state (not the SIEVE script). However, the = >> SIEVE script could be also enhanced with built-in variables (like = >> HAS_SESSION, IS_CONNECTED, etc whatever the syntax of SIEVE is) > Yes, that would be possible. I think Cyrus Daboo has already suggested to use presence with = notifications. >> and then the SIEVE script could make the decisions as well. Server = >> implementation people have more experience about which one would be = >> better and why. > > Enhancements to Sieve should be discussed in the Sieve group. I agree. > But there are always edge cases in doing this, for example, the client = > could connect or disconnect to the IMAP server immediately after the = > Sieve script has tested the condition. We'd want to make sure that any = > added complexity to Sieve is worth it. Right. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 12 05:42:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpiwY-0000NI-Dt; Mon, 12 Jun 2006 05:42:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpiwX-0000NC-48 for lemonade@ietf.org; Mon, 12 Jun 2006 05:42:45 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpiwT-00020x-Jj for lemonade@ietf.org; Mon, 12 Jun 2006 05:42:45 -0400 Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 12 Jun 2006 10:42:19 +0100 Message-ID: <448C80DA.5010305@isode.com> Date: Sun, 11 Jun 2006 21:45:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Cyrus Daboo Subject: Re: [Lemonade] Discussion items from thsimorning on VFOLDER and WITHIN References: <20060601070749343.00000000428@smaes-lap3> <72FDD20C56FDCB399E7AAF41@Cyrus-Daboo.local> In-Reply-To: <72FDD20C56FDCB399E7AAF41@Cyrus-Daboo.local> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-15"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Cyrus Daboo wrote: > Hi Randall, > > --On June 1, 2006 12:02:47 PM -0700 Randall Gellens > wrote: > >> But if a message goes in and out of view, and gets a new UID each >> time it >> reappears, wouldn't it get downloaded multiple times? > > Yes. The current drafts says this: > > Future versions of VFOLDER may introduce a new server supported > mechanism for efficiently determining the original mailbox and UID of > a message > > I think THIS version of VFOLDER should provide such a mechanism. A new > OUID fetch parameter that returns a relative imap url with the > mailbox, uidvalidty and uid of the underlying message would be one > simple solution. The other would be a more general GUID mechanism - > but that may be going too far... The server would also need to return OUIDVALIDITY (UIDVALIDITY of the original mailbox). I think using relative IMAP URLs would be best. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 12 05:42:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpiwb-0000Qo-Kj; Mon, 12 Jun 2006 05:42:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpiwZ-0000Pc-Nk for lemonade@ietf.org; Mon, 12 Jun 2006 05:42:47 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpiwV-00021B-9b for lemonade@ietf.org; Mon, 12 Jun 2006 05:42:47 -0400 Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 12 Jun 2006 10:42:23 +0100 Message-ID: <448C8193.3060102@isode.com> Date: Sun, 11 Jun 2006 21:48:19 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen Subject: Re: [lemonade] Notifications for multiple devices per user References: <4486CC85.80400@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen wrote: > Alexey Melnikov writes: > >> In my private discussion with Zoltan he raised a question about IMAP >> server ability to store notification information (i.e. where the >> notification is to be sent) for multiple devices per user. Is this >> the requirement the WG wants to consider when thinking about >> notifications? > > Isn't this a given? I didn't think that would be the common case. Other opinions? The reason why this is important, is because this requirement would dictate how mailbox annotations related to notifications are structured (named). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 12 17:56:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpuOk-00080Q-E4; Mon, 12 Jun 2006 17:56:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpuOj-00080L-9g for lemonade@ietf.org; Mon, 12 Jun 2006 17:56:37 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpuOh-0006xo-UO for lemonade@ietf.org; Mon, 12 Jun 2006 17:56:37 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5CLuXSO026315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Jun 2006 14:56:34 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5CLuTlH022853; Mon, 12 Jun 2006 14:56:32 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <448C72A1.2010706@isode.com> References: <0FA975F2D8295A448BE3ADC16124465738F444@esebe199.NOE.Nokia.com> <448C72A1.2010706@isode.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 12 Jun 2006 14:56:16 -0700 To: Alexey Melnikov , Zoltan.Ordogh@nokia.com From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 8:44 PM +0100 6/11/06, Alexey Melnikov wrote: >> What is the server/client behaviour if it could not be created? >> > Client needs to fallback to using regular IMAP, as if the quick > reconnect extension is not available. > > In theory the client can do something differently if it expects, > say, 3 resumable sessions and only got 2. Why would a client want to have more than one saved or active session to the same server? To have multiple mailboxes selected (one per session)? Is this still needed with condstore? If so, maybe we do need to provide guidance to client authors as to what to expect and to server authors as to a minimum per-user to support. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Artificial intelligence is no match for natural stupidity. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 12 18:47:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpvCQ-00081I-45; Mon, 12 Jun 2006 18:47:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpvCO-00081D-S4 for lemonade@ietf.org; Mon, 12 Jun 2006 18:47:56 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpvCN-0001Fa-H6 for lemonade@ietf.org; Mon, 12 Jun 2006 18:47:56 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id E58CA272A7; Mon, 12 Jun 2006 16:47:52 -0600 (MDT) In-Reply-To: References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C041CB4-9A26-402E-97BD-45DD6EC82CAE@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Date: Mon, 12 Jun 2006 16:47:51 -0600 To: Randall Gellens X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Enhancements to Internet email to support diverse serviceenivronments , Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 9-Jun-06, at 6:22 PM, Randall Gellens wrote: > At 2:15 PM -0600 6/2/06, Curtis King wrote: > >> I doubt know if you can, but servers are being force to store >> more information for a VFOLDER than a real mailbox. That just >> doesn't seem like the right design. >> >> Why not have named searches which can be used as FILTERS when >> selecting a mailbox to provide the desired view? Clients can >> handle an UID going out and in of view because they will expect >> that behavior. > > I think there was a draft along these lines a few years ago. From > Cyrus maybe? I think so. > >> For things like multi-mailbox vfolders why not use a named search >> and copy to populate a new mailbox from the source mailboxes? This >> may require some extensions to search and some way of storing the >> last uid used int the search. Now, the clients can decide when to >> update the mailbox and what messages and flags are synchronized >> between the mailboxes. >> >> This isn't any more work than vfolder, but you can sure do more >> with it. > > Copying feels like the wrong approach (although some servers may > have mail stores that allow them to populate the new mailbox with > pointers to the original message, along with reference counts to > handle deletion). What about servers that would have to actually > do a copy? I agree. I was trying address the multiple mailbox issue which was a mistake. VMAILBOX is trying to add a feature best done by the client. Be that I mean IMAP is a set of tools which you can do things with, VMAILBOX is trying to move a client operation to the server. VMAILBOX in it's current form is forcing servers to use a database to store uid pairings which raises the implementation bar. Is VMAILBOX worth it? A number of years back I worked for Esys which produced an MUA (Simeon/Execmail) which had virtual mailboxes using IMAP search. VMAILBOX can be done today using plain old SEARCH with out much difference in performance from what I can see. Wouldn't be better to enhance the existing IMAP tools to make this easier? For example: - save the named searches using METADATA the same way you need to save other NOTIFICATION information. - extend IDLE to filter using a saved search and possible watch multiple mailboxes at the same time. - union searches even from different mailboxes. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 12 18:53:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpvHv-0002aR-Dm; Mon, 12 Jun 2006 18:53:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpvHt-0002RP-9r for lemonade@ietf.org; Mon, 12 Jun 2006 18:53:37 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpvHs-0001vL-16 for lemonade@ietf.org; Mon, 12 Jun 2006 18:53:37 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id B5E30272A7; Mon, 12 Jun 2006 16:53:35 -0600 (MDT) In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Mon, 12 Jun 2006 16:53:34 -0600 To: Randall Gellens X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org, Arnt Gulbrandsen , "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 8-Jun-06, at 4:00 PM, Randall Gellens wrote: > On the COPY/APPEND issue, if vfolders are distinguishable, then > perhaps it is OK if a COPY/APPEND might seem to vanish. Having a message disappear which you just copied/appended will be very confusing to people. No matter how the mailbox is marked. If the client controls the view it can add appended messages to view if needed. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 12 19:25:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpvmn-0000Nd-7m; Mon, 12 Jun 2006 19:25:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpvmm-0000MX-1j for lemonade@ietf.org; Mon, 12 Jun 2006 19:25:32 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpvmk-0004rf-NK for lemonade@ietf.org; Mon, 12 Jun 2006 19:25:32 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5CNPPTK009004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Jun 2006 16:25:26 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5CNPMI5019269; Mon, 12 Jun 2006 16:25:23 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 12 Jun 2006 16:24:40 -0700 To: Curtis King From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: lemonade@ietf.org, Arnt Gulbrandsen , "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 4:53 PM -0600 6/12/06, Curtis King wrote: > On 8-Jun-06, at 4:00 PM, Randall Gellens wrote: > >> On the COPY/APPEND issue, if vfolders are distinguishable, then >> perhaps it is OK if a COPY/APPEND might seem to vanish. > > Having a message disappear which you just copied/appended will be > very confusing to people. No matter how the mailbox is marked. Confusing to *people* yes. But the *client* needn't be confused, and if the client isn't confused, then the user doesn't need to be confused either. What I was suggesting was that if the client knows it has selected a vmailbox, and it does a copy or append, then as long as it gets an OK response it can present the message to the user as being part of the mailbox. Especially if it has received the UID of the appended/copied message in the command response. > If the client controls the view it can add appended messages to > view if needed. A good point, but it would be awkward for the client to need to update the vmailbox filter criteria each time it does a copy or append. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- If A = B and B = C, then A = C, except where void or prohibited by law. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 12 20:37:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpwuS-0000HE-EQ; Mon, 12 Jun 2006 20:37:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpwuR-0000H9-P7 for lemonade@ietf.org; Mon, 12 Jun 2006 20:37:31 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpwuQ-000474-CG for lemonade@ietf.org; Mon, 12 Jun 2006 20:37:31 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5D0bQTp016368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Jun 2006 17:37:27 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5D0bNtk028557; Mon, 12 Jun 2006 17:37:25 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 12 Jun 2006 17:34:49 -0700 To: Alexey Melnikov , "Stephane H. Maes" , Dave Cridland From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org In Section 1: It is based on LEMONADE profile [profile]. This document describes the lemonade profile-bis that includes: I don't think we should use the term "bis" anywhere in the document (just the title), since this document is an update to the previous profile document and hence replaces it. Likewise, I wouldn't say "It is based on LEMONADE profile [profile]" but perhaps "is an update of" or something like that. Similarly, the text (which is later in the same section) "are summarized in the LEMONADE profile [profile]" is confusing because this document is the lemonade profile. I suggest deleting the text (later in this same section): and mechanisms of the OMA MEM Architecture [MEM-arch], following the LEMONADE point of view described in the OMA MEM realization internet draft [OMAMEMrealization]. I think it might be confusing to readers who aren't looking to implement OMA MEM, but just want to support email or mobile email. I don't think this text is needed. The earlier part of the sentence makes it clear that this supports OMA MEM. The reference to the OMA MEM realization Internet Draft would be a problem if that draft is not published as an RFC. Likewise, the following text should be either deleted or moved to a new section to be called something like "Notes on Supporting OMA MEM", making clear that the section is to aid the working relationship between lemonade and OMA MEM, and is to be deleted by the RFC Editor prior to publication: Also, it is to be noted that this document solely describes normatively the LEMONADE profile bis. It discusses LEMONADE understanding of the work in progress at OMA MEM ([MEM-req] and [MEM- arch] but does not provide a normative reading of these documents. Readers MUST refer to the Open Mobile Alliance web site for normative references on the Mobile Email Enabler (OMA MEM). LEMONADE assumes that the LEMONADE profile bis can be used as basis for an OMA technical specification of a realization based on LEMONADE of the OMA MEM enabler. Section 3: Should BURL be here as well as in Section 2? At least a short mention with reference to Section 2? In Section 3.3, I don't like the quotes around 'expand' in 'MUST "expand" all BURL'. I'd suggest either removing them, or change 'expand' to 'dereference'. Although, in thinking about it, the wording could be taken the wrong way. If the size of a message already exceeds a limit and there are still BURL parts not yet expanded, there is no need for the server to expand them. Perhaps something along the lines of "When including a message size in the MAIL FROM command, clients MUST use a value that is at least as large as the size of the message after expansion of all BURL parts. Servers MUST NOT consider a message's size to be acceptable if it has not expanded all BURL parts." Section 4.3: I think we agreed to go with the alternate paragraph that says "MUST provide [COMPRESS] support". Sections 6-9 should, I think, be moved to the new section I propose above ("Notes on Supporting OMA MEM"). I don't want to confuse non-OMA readers. In Section 9, the text "additional security measures like object level encryption" is asking for trouble (I was going to say "raw meat for the Security folks" but some of them may be vegetarian). Perhaps it should be changed to "significant additional security considerations" (although that too is really hand-waving). I like Section 10, but Sections 11-13 are difficult because they are so intertwined with OMA references and considerations. I'm all for making it clear how our model and protocols fit into OMA MEM, but I also want to produce a stand-alone profile document that makes sense to non-OMA people. I had been assuming that this document served that purpose. In Section 14.3, "traverse firewalls" should be "deceive firewalls" since firewalls can be traversed with no additional security considerations. That's the job of the firewall. It's only when you try to fool the firewall in order to subvert its configured policy that you get into the additional issues. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Once I make up my mind, I'm full of indecision. --Oscar Levant _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 01:33:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq1Wy-0004bh-Qj; Tue, 13 Jun 2006 01:33:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq1Wx-0004Vf-BY for lemonade@ietf.org; Tue, 13 Jun 2006 01:33:35 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq1Ww-0005fl-1K for lemonade@ietf.org; Tue, 13 Jun 2006 01:33:35 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 8FC35272A7; Mon, 12 Jun 2006 23:33:31 -0600 (MDT) In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Mon, 12 Jun 2006 23:33:31 -0600 To: Randall Gellens X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: lemonade@ietf.org, Arnt Gulbrandsen , "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 12-Jun-06, at 5:24 PM, Randall Gellens wrote: > At 4:53 PM -0600 6/12/06, Curtis King wrote: > >> On 8-Jun-06, at 4:00 PM, Randall Gellens wrote: >> >>> On the COPY/APPEND issue, if vfolders are distinguishable, then >>> perhaps it is OK if a COPY/APPEND might seem to vanish. >> >> Having a message disappear which you just copied/appended will be >> very confusing to people. No matter how the mailbox is marked. > > Confusing to *people* yes. But the *client* needn't be confused, > and if the client isn't confused, then the user doesn't need to be > confused either. > > What I was suggesting was that if the client knows it has selected > a vmailbox, and it does a copy or append, then as long as it gets > an OK response it can present the message to the user as being part > of the mailbox. Especially if it has received the UID of the > appended/copied message in the command response. Ok - Then what does VMAILBOX get me? If I have to merge a view and the append uid on the client side, why not do that from the start using search? > >> If the client controls the view it can add appended messages to >> view if needed. > > A good point, but it would be awkward for the client to need to > update the vmailbox filter criteria each time it does a copy or > append. We are suggesting the same thing, I was thinking the client would merge the results of the search with uid returned from the copy or append. We can do this now using SEARCH and UIDPLUS. VMAILBOX does not make this any easier than the standard IMAP commands. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 04:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kO-000530-3i; Tue, 13 Jun 2006 04:59:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kM-0004xl-MA for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:38 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4kM-0001nw-C3 for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:38 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061462:sNHT48602232" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Date: Tue, 13 Jun 2006 05:00:52 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FEA@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Thread-Index: AcaOBKiq/myVf+z0RTe6CanH4mm3kQATdHgQ From: "Burger, Eric" To: "Alexey Melnikov" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Also don't forget that under any circumstance, the server could decide 'later' that it cannot honor a request. This is independent of whether we have the server say, "I might have so many sessions available for you" when asked or if the server doesn't say anything about how many sessions are (could be) available. Once you have to write the code for the client to handle that situation, it turns out there is no value to the server giving an indication as to how many sessions are available for you. Thus we took out reporting on the number of available server sessions from the specification. -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: Sunday, June 11, 2006 3:45 PM To: Zoltan.Ordogh@nokia.com Cc: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Zoltan.Ordogh@nokia.com wrote: >Thank You for the update Alexey, >I have a few comments: > - " state is deleted. While there is no required minimum expiration > timeout, server implementations are encouraged to support as long a > time as possible, subject to denial-of-service and related concerns." This is something I have commented before. I do not know if the idea has been discussed. It would be very beneficial for the client to know how long the server keeps the sessions, even better if the client could negotiate this setting. Has this been discussed during the interim? > No it hasn't. I've read both your message and Randy's reply to it. I think Randy=20 argued against the need for the server to advertise/be able to change=20 any limit. If you disagree, can you please reply to Randy's message and=20 we will continue the discussion. >Was there any conclusion? > - " previous, active resumable session is available. If an active > session is already available and a new one can be created, the" What happens when a new session cannot be created? > The server would reply NO and the current active session remains active. I guess this can be spelled out in the document. >Who says it cannot be created and why? > Server can have a policy limiting number of available sessions per user, per IP or other factors. This can be done in order to limit DoS attacks. Server can have a global limit on number of sessions it can serve. At the end this is dictated by available resources. >What is the server/client behaviour if it could not be created? > =20 > Client needs to fallback to using regular IMAP, as if the quick=20 reconnect extension is not available. In theory the client can do something differently if it expects, say, 3=20 resumable sessions and only got 2. > - " In order to limit Denial of Service attacks a server implementation > SHOULD have a per-user limit on maximum number of resumable sessions." If the server imposes such limit, what is the way to communicate the number of current sessions and the limit to the client? > =20 > There is currently no way to communicate the number of sessions=20 available to a user. This was discussed during the recent interim and Eric convinced me that a). specifying any limit in the document wouldn't help, as multiple=20 clients acting on behalf of a single user would be able to exceed any limit. b). advertising any limit (or remaining number of sessions) would not=20 help, as there is a race condition between the moment when the server=20 advertises the remaining number and the moment when the client can=20 create a new session. So the client would have to be able to deal with=20 server saying "I can't create any more sessions" anyway. > - " server then checks the last known modification sequence." MODSEQ? > =20 > Yes. > - " [[anchor8: This section clearly assumes voluntarily disconnect]]" should it be described instead having it as an anchor? It is already described - except the voluntary part - so it could simply be removed. > =20 > Yes, this will be deleted. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 04:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kQ-00053I-7z; Tue, 13 Jun 2006 04:59:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kP-00053C-Hj for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:41 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4kO-0001nw-Bo for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:41 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061466:sNHT39822616" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Draft name (was RE: [lemonade] COMPRESS Thoughts) Date: Tue, 13 Jun 2006 05:00:54 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FEC@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft name (was RE: [lemonade] COMPRESS Thoughts) Thread-Index: AcaFAtdDlH1xsEcTT9+pqiC7CVGJLQJUI/WQ From: "Burger, Eric" To: "Dave Cridland" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org There is a purely procedural reason for reusing the old draft name. It buys us a week. Blame the chair :) -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net]=20 Sent: Wednesday, May 31, 2006 6:36 PM To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] COMPRESS Thoughts On Wed May 31 20:29:26 2006, Burger, Eric wrote: [snip] > (3) Basis for COMPRESS document is Arnt's imap-deflate-02 > [compress=3Ddeflate]. We will call the new document > draft-ietf-lemonade-compress-04 (delete existing compress text) >=20 >=20 Why? It's obviously not a revision of that document. Is there a=20 procedural reason for this? [snip] _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 04:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kR-00054M-QX; Tue, 13 Jun 2006 04:59:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kQ-00053U-GI for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:42 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4kP-0001o3-9J for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:42 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061468:sNHT28365528" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Submit Direction (was RE: [lemonade] COMPRESS Thoughts) Date: Tue, 13 Jun 2006 05:00:55 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FED@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Submit Direction (was RE: [lemonade] COMPRESS Thoughts) Thread-Index: AcaFAtdDlH1xsEcTT9+pqiC7CVGJLQJURV7A From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mea Culpa: I used poor language when attempting to describe the asymmetrical nature of compression. Re-reading what I wrote, and the subsequent thread, it is apparent that what I wrote made it sound like we were ONLY going to have compression in the Server->Client direction, and we would NOT have compression in the Client->Server direction. Thing 1: That was not the consensus. The consensus was there could be situations where you would want compression all the time in both directions (the typical case); there could be situations where you would want compression only Server->Client but not Client->Server; for that matter, there theoretically could be situations where you would want compression only Client->Server (although I cannot think of any). The point I was trying to make is that we needed to handle compression in one direction, AS WELL AS compression in both directions. Thing 2: The entire discussion revolved around IMAP. As has been pointed out on the list, compression would be an incredibly useful feature for SUBMIT. Thing 3: Compression on SUBMIT does not depend on compression for IMAP. Thing 4: Lemonade does not strictly depend on compression to get published. Thing 5: I don't want to expand our work before we finish our committed work. Given these Things, I would offer we work out Compression for IMAP first. We need data collection (what resources get saved, what resources get spent, is CPU really that much more expensive than Radio [I thought not :->], etc.). Once we finish Compression for IMAP, doing a Compression for SUBMIT should be a trivial exercise for the reader. OK? On Wed May 31 20:29:26 2006, Burger, Eric wrote: [snip] > (2) Consensus that compression is directional, i.e., downstream > compressed, upstream uncompressed. This is because IMAP upstream > commands may be real short (meaning compression actually adds CPU=20 > *and* bits used), while content may be real long. [snip] _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 04:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kO-000530-3i; Tue, 13 Jun 2006 04:59:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kM-0004xl-MA for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:38 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4kM-0001nw-C3 for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:38 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061462:sNHT48602232" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Date: Tue, 13 Jun 2006 05:00:52 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FEA@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Thread-Index: AcaOBKiq/myVf+z0RTe6CanH4mm3kQATdHgQ From: "Burger, Eric" To: "Alexey Melnikov" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Also don't forget that under any circumstance, the server could decide 'later' that it cannot honor a request. This is independent of whether we have the server say, "I might have so many sessions available for you" when asked or if the server doesn't say anything about how many sessions are (could be) available. Once you have to write the code for the client to handle that situation, it turns out there is no value to the server giving an indication as to how many sessions are available for you. Thus we took out reporting on the number of available server sessions from the specification. -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: Sunday, June 11, 2006 3:45 PM To: Zoltan.Ordogh@nokia.com Cc: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Zoltan.Ordogh@nokia.com wrote: >Thank You for the update Alexey, >I have a few comments: > - " state is deleted. While there is no required minimum expiration > timeout, server implementations are encouraged to support as long a > time as possible, subject to denial-of-service and related concerns." This is something I have commented before. I do not know if the idea has been discussed. It would be very beneficial for the client to know how long the server keeps the sessions, even better if the client could negotiate this setting. Has this been discussed during the interim? > No it hasn't. I've read both your message and Randy's reply to it. I think Randy=20 argued against the need for the server to advertise/be able to change=20 any limit. If you disagree, can you please reply to Randy's message and=20 we will continue the discussion. >Was there any conclusion? > - " previous, active resumable session is available. If an active > session is already available and a new one can be created, the" What happens when a new session cannot be created? > The server would reply NO and the current active session remains active. I guess this can be spelled out in the document. >Who says it cannot be created and why? > Server can have a policy limiting number of available sessions per user, per IP or other factors. This can be done in order to limit DoS attacks. Server can have a global limit on number of sessions it can serve. At the end this is dictated by available resources. >What is the server/client behaviour if it could not be created? > =20 > Client needs to fallback to using regular IMAP, as if the quick=20 reconnect extension is not available. In theory the client can do something differently if it expects, say, 3=20 resumable sessions and only got 2. > - " In order to limit Denial of Service attacks a server implementation > SHOULD have a per-user limit on maximum number of resumable sessions." If the server imposes such limit, what is the way to communicate the number of current sessions and the limit to the client? > =20 > There is currently no way to communicate the number of sessions=20 available to a user. This was discussed during the recent interim and Eric convinced me that a). specifying any limit in the document wouldn't help, as multiple=20 clients acting on behalf of a single user would be able to exceed any limit. b). advertising any limit (or remaining number of sessions) would not=20 help, as there is a race condition between the moment when the server=20 advertises the remaining number and the moment when the client can=20 create a new session. So the client would have to be able to deal with=20 server saying "I can't create any more sessions" anyway. > - " server then checks the last known modification sequence." MODSEQ? > =20 > Yes. > - " [[anchor8: This section clearly assumes voluntarily disconnect]]" should it be described instead having it as an anchor? It is already described - except the voluntary part - so it could simply be removed. > =20 > Yes, this will be deleted. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 04:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kQ-00053I-7z; Tue, 13 Jun 2006 04:59:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kP-00053C-Hj for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:41 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4kO-0001nw-Bo for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:41 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061466:sNHT39822616" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Draft name (was RE: [lemonade] COMPRESS Thoughts) Date: Tue, 13 Jun 2006 05:00:54 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FEC@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft name (was RE: [lemonade] COMPRESS Thoughts) Thread-Index: AcaFAtdDlH1xsEcTT9+pqiC7CVGJLQJUI/WQ From: "Burger, Eric" To: "Dave Cridland" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org There is a purely procedural reason for reusing the old draft name. It buys us a week. Blame the chair :From lemonade-bounces@ietf.org Tue Jun 13 04:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kO-000530-3i; Tue, 13 Jun 2006 04:59:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kM-0004xl-MA for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:38 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4kM-0001nw-C3 for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:38 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061462:sNHT48602232" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Date: Tue, 13 Jun 2006 05:00:52 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FEA@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Thread-Index: AcaOBKiq/myVf+z0RTe6CanH4mm3kQATdHgQ From: "Burger, Eric" To: "Alexey Melnikov" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Also don't forget that under any circumstance, the server could decide 'later' that it cannot honor a request. This is independent of whether we have the server say, "I might have so many sessions available for you" when asked or if the server doesn't say anything about how many sessions are (could be) available. Once you have to write the code for the client to handle that situation, it turns out there is no value to the server giving an indication as to how many sessions are available for you. Thus we took out reporting on the number of available server sessions from the specification. -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: Sunday, June 11, 2006 3:45 PM To: Zoltan.Ordogh@nokia.com Cc: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Zoltan.Ordogh@nokia.com wrote: >Thank You for the update Alexey, >I have a few comments: > - " state is deleted. While there is no required minimum expiration > timeout, server implementations are encouraged to support as long a > time as possible, subject to denial-of-service and related concerns." This is something I have commented before. I do not know if the idea has been discussed. It would be very beneficial for the client to know how long the server keeps the sessions, even better if the client could negotiate this setting. Has this been discussed during the interim? > No it hasn't. I've read both your message and Randy's reply to it. I think Randy=20 argued against the need for the server to advertise/be able to change=20 any limit. If you disagree, can you please reply to Randy's message and=20 we will continue the discussion. >Was there any conclusion? > - " previous, active resumable session is available. If an active > session is already available and a new one can be created, the" What happens when a new session cannot be created? > The server would reply NO and the current active session remains active. I guess this can be spelled out in the document. >Who says it cannot be created and why? > Server can have a policy limiting num) -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net]=20 Sent: Wednesday, May 31, 2006 6:36 PM To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] COMPRESS Thoughts On Wed May 31 20:29:26 2006, Burger, Eric wrote: [snip] > (3) Basis for COMPRESS document is Arnt's imap-deflate-02 > [compress=3Ddeflate]. We will call the new document > draft-ietf-lemonade-compress-04 (delete existing compress text) >=20 >=20 Why? It's obviously not a revision of that document. Is there a=20 procedural reason for this? [snip] _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 04:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kR-00054M-QX; Tue, 13 Jun 2006 04:59:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kQ-00053U-GI for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:42 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4kP-0001o3-9J for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:42 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061468:sNHT28365528" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Submit Direction (was RE: [lemonade] COMPRESS Thoughts) Date: Tue, 13 Jun 2006 05:00:55 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FED@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Submit Direction (was RE: [lemonade] COMPRESS Thoughts) Thread-Index: AcaFAtdDlH1xsEcTT9+pqiC7CVGJLQJURV7A From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mea Culpa: I used poor language when attempting to describe the asymmetrical nature of compression. Re-reading what I wrote, and the subsequent thread, it is apparent that what I wrote made it sound like we were ONLY going to have compression in the Server->Client direction, and we would NOT have compression in the Client->Server direction. Thing 1: That was not the consensus. The consensus was there could be situations where you would want compression all the time in both directions (the typical case); there could be situations where you would want compression only Server->Client but not Client->Server; for that matter, there theoretically could be situations where you would want compression only Client->Server (although I cannot think of any). The point I was trying to make is that we needed to handle compression in one direction, AS WELL AS compression in both directions. Thing 2: The entire discussion revolved around IMAP. As has been pointed out on the list, compression would be an incredibly useful feature for SUBMIT. Thing 3: Compression on SUBMIT does not depend on compression for IMAP. Thing 4: Lemonade does not strictly depend on compression to get published. Thing 5: I don't want to expand our work before we finish our committed work. Given these Things, I would offer we work out Compression for IMAP first. We need data collection (what resources get saved, what resources get spent, is CPU really that much more expensive than Radio [I thougber of available sessions per user, per IP or other factors. This can be done in order to limit DoS attacks. Server can have a global limit on number of sessions it can serve. At the end this is dictated by available resources. >What is the server/client behaviour if it could not be created? > =20 > Client needs to fallback to using regular IMAP, as if the quick=20 reconnect extension is not available. In theory the client can do something differently if it expects, say, 3=20 resumable sessions and only got 2. > - " In order to limit Denial of Service attacks a server implementation > SHOULD have a per-user limit on maximum number of resumable sessions." If the server imposes such limit, what is the way to communicate the number of current sessions and the limit to the client? > =20 > There is currently no way to communicate the number of sessions=20 available to a user. This was discussed during the recent interim and Eric convinced me that a). specifying any limit in the document wouldn't help, as multiple=20 clients acting on behalf of a single user would be able to exceed any limit. b). advertising any limit (or remaining number of sessions) would not=20 help, as there is a race condition between the moment when the server=20 advertises the remaining number and the moment when the client can=20 create a new session. So the client would have to be able to deal with=20 server saying "I can't create any more sessions" anyway. > - " server then checks the last known modification sequence." MODSEQ? > =20 > Yes. > - " [[anchor8: This section clearly assumes voluntarily disconnect]]" should it be described instead having it as an anchor? It is already described - except the voluntary part - so it could simply be removed. > =20 > Yes, this will be deleted. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 04:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kQ-00053I-7z; Tue, 13 Jun 2006 04:59:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kP-00053C-Hj for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:41 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4kO-0001nw-Bo for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:41 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061466:sNHT39822616" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Draft name (was RE: [lemonade] COMPRESS Thoughts) Date: Tue, 13 Jun 2006 05:00:54 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FEC@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft name (was RE: [lemonade] COMPRESS Thoughts) Thread-Index: AcaFAtdDlH1xsEcTT9+pqiC7CVGJLQJUI/WQ From: "Burger, Eric" To: "Dave Cridland" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org There is a purely procedural reason for reusing the old draft name. It buys us a week. Blame the chair :ht not :->], etc.). Once we finish Compression for IMAP, doing a Compression for SUBMIT should be a trivial exercise for the reader. OK? On Wed May 31 20:29:26 2006, Burger, Eric wrote: [snip] > (2) Consensus that compression is directional, i.e., downstream > compressed, upstream uncompressed. This is because IMAP upstream > commands may be real short (meaning compression actually adds CPU=20 > *and* bits used), while content may be real long. [snip] _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade ) -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net]=20 Sent: Wednesday, May 31, 2006 6:36 PM To: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] COMPRESS Thoughts On Wed May 31 20:29:26 2006, Burger, Eric wrote: [snip] > (3) Basis for COMPRESS document is Arnt's imap-deflate-02 > [compress=3Ddeflate]. We will call the new document > draft-ietf-lemonade-compress-04 (delete existing compress text) >=20 >=20 Why? It's obviously not a revision of that document. Is there a=20 procedural reason for this? [snip] _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 04:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kR-00054M-QX; Tue, 13 Jun 2006 04:59:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kQ-00053U-GI for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:42 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4kP-0001o3-9J for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:42 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061468:sNHT28365528" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Submit Direction (was RE: [lemonade] COMPRESS Thoughts) Date: Tue, 13 Jun 2006 05:00:55 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FED@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Submit Direction (was RE: [lemonade] COMPRESS Thoughts) Thread-Index: AcaFAtdDlH1xsEcTT9+pqiC7CVGJLQJURV7A From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mea Culpa: I used poor language when attempting to describe the asymmetrical nature of compression. Re-reading what I wrote, and the subsequent thread, it is apparent that what I wrote made it sound like we were ONLY going to have compression in the Server->Client direction, and we would NOT have compression in the Client->Server direction. Thing 1: That was not the consensus. The consensus was there could be situations where you would want compression all the time in both directions (the typical case); there could be situations where you would want compression only Server->Client but not Client->Server; for that matter, there theoretically could be situations where you would want compression only Client->Server (although I cannot think of any). The point I was trying to make is that we needed to handle compression in one direction, AS WELL AS compression in both directions. Thing 2: The entire discussion revolved around IMAP. As has been pointed out on the list, compression would be an incredibly useful feature for SUBMIT. Thing 3: Compression on SUBMIT does not depend on compression for IMAP. Thing 4: Lemonade does not strictly depend on compression to get published. Thing 5: I don't want to expand our work before we finish our committed work. Given these Things, I would offer we work out Compression for IMAP first. We need data collection (what resources get saved, what resources get spent, is CPU really that much more expensive than Radio [I thought not :->], etc.). Once we finish Compression for IMAP, doing a Compression for SUBMIT should be a trivial exercise for the reader. OK? On Wed May 31 20:29:26 2006, Burger, Eric wrote: [snip] > (2) Consensus that compression is directional, i.e., downstream > compressed, upstream uncompressed. This is because IMAP upstream > commands may be real short (meaning compression actually adds CPU=20 > *and* bits used), while content may be real long. [snip] _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 04:59:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kS-00056K-Vr; Tue, 13 Jun 2006 04:59:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kS-00054x-4Z for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:44 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4kQ-0001oQ-Sb for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:44 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061469:sNHT39551088" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] COMPRESS Thoughts Date: Tue, 13 Jun 2006 05:00:56 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FEE@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] COMPRESS Thoughts Thread-Index: AcaFZvyBLqlJZXQnTQ+Is5/RLlDJ1AI7k4sQ From: "Burger, Eric" To: "Arnt Gulbrandsen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Question: what is the round-trip latency to wait for the untagged OK? If it is two round-trips at 750ms each, that would be "less than ideal." If we have to wait a long time before we say "turn off compression," then I would offer that implementers suck it up. Then again, that could be the reason to say, "just compress everything." :)=20 -----Original Message----- From: Arnt Gulbrandsen [mailto:arnt@gulbrandsen.priv.no]=20 Sent: Thursday, June 01, 2006 6:31 AM To: lemonade@ietf.org Subject: Re: [lemonade] COMPRESS Thoughts Eric Burger writes: > (4) Protocol allows for client to turn it on or off at will (not per=20 > body part, but point in time in session) There's a performance gotcha to this, I realized while changing my=20 daughter's nappies at 6am this morning. The compression library likes to read in big chunks. Everyone likes to=20 do I/O in big chunks. Reading network input one byte at a time is such=20 a performance drag. If the client tells the server that starting with=20 the next command, its commands are uncompressed, the server's=20 compression library has to stop reading at the right byte. It can't=20 simply read all it can eat. Ditto for responses. This should fix it: 1. The client cannot send any other commands until the server has sent a tagged OK for the 'disable upstream compression' command. 2. The server disables compression after sending the tagged OK for that=20 command (including the CRLF). 3. The server cannot send any unsolicited responses after sending that=20 tagged OK and before receiving the next command. The last introduces a new server mode and gets in the way of extending=20 IDLE... right now, I think that server mode is more trouble than it's=20 worth. What is the problem if compression stays on once it's turned on? I can't recall any relevant problems with STARTTLS, which behaves that way. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 04:59:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kU-000585-53; Tue, 13 Jun 2006 04:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kT-00057y-Be for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:45 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4kS-0001oQ-5o for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:45 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061470:sNHT37266240" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Examples (was RE: [lemonade] Question on 'Sent Items' deposit) Date: Tue, 13 Jun 2006 05:00:57 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FEF@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Examples (was RE: [lemonade] Question on 'Sent Items' deposit) Thread-Index: AcaInYl+TnDkrY5USKyG8pJN1JhjuwF6ruTg From: "Burger, Eric" To: "Alexey Melnikov" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org If the examples are short (~ 1 page each), then sure. However, if we're talking about a cookbook of examples, I think it should be a separate document, in order not to hold up the protocol.=20 -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: Monday, June 05, 2006 8:40 AM Subject: Re: [lemonade] Question on 'Sent Items' deposit Dave Cridland wrote: [snip] > I might alter the title if it makes this easier to find. I am wondering if Profile bis should have a section with several simple=20 examples, that would help to understand the more detailed explanation? [snip] _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 04:59:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kW-00059K-Ao; Tue, 13 Jun 2006 04:59:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kU-00059F-La for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:46 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4kT-0001oQ-Cx for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:46 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061471:sNHT48681792" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt Date: Tue, 13 Jun 2006 05:00:58 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FF0@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt Thread-Index: AcZ7KvWhMH5SLE5+SIyxoTbAWZTn9gIUu9UAADN23uABokMg4ADs+Pjg From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I would offer that we just state DRM is up to the IMAP server. It is = way beyond lemonade scope to figure out and replicate full DRM. Rather, = let's do butt simple DRM: if the client has the right to copy an object, = they can do whatever they want with it. The implementation is in = URLAUTH. If you cannot copy an object, for whatever reason, determined = way outside the protocol, the server will not generate a URLAUTH token. = The converse holds, as well. If the server generates a URLAUTH token, = the client can do whatever it wants with the object. The client can = forward the object (BURL), stream the object (streaming), or eat the = object (URLFETCH). We should explicitly say that (1) this provides = greater than or equal to DRM semantics with respect to existing e-mail = and (2) if you want real DRM, implement a real DRM system. Comments? -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com]=20 Sent: Thursday, June 08, 2006 4:31 AM To: lemonade@ietf.org Subject: RE: [lemonade] draft-cook-lemonade-streaming-00.txt I think it's looking good and simple: we generate a URL withing the IMAP = session for the media, then client connects directly to media server to = start streaming. Comments/questions: - URLAUTH is RFC 4467 now, not a draft, so the reference should be = updated. - There is no mentioning of DRM. Should there be? Has it been = considered at all? Or we do not need to because we leave it up to the = client and the media server to sort it out? Can an IMAP server create an = authorized URL for a DRMed content without any problem? (I'm not an = expert on DRM, but I do know that it has been problematic in other = messaging systems). Thank You, a good draft once again. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Burger, Eric [mailto:eburger@cantata.com]=20 Sent: 31 May, 2006 03:48 To: Enhancements to Internet email to support diverse = serviceenivronments Subject: [lemonade] draft-cook-lemonade-streaming-00.txt Until it hits the archives, here is a copy of the outline for the = streaming services draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 04:59:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kY-0005Hj-HV; Tue, 13 Jun 2006 04:59:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kW-0005En-ND for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:48 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4kV-0001oQ-HF for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:48 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061474:sNHT40012640" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt Date: Tue, 13 Jun 2006 05:01:01 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FF2@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt Thread-Index: AcaEO55OQHzzHme/SmWEI/8W20rNUAF5MwKQARo/KVA= From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I agree -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com]=20 Sent: Wednesday, June 07, 2006 8:02 AM To: lemonade@ietf.org Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt=20 [snip] - Section 4.3 general. This section is confusing. Would it be possible to describe things from the compression level point of view saying this is low-level, that is application-level, and that is object-level compression. This is believed to be better for this, that is believed to be better for that. For low-level use this and that, for application-level use this and that, and for object-level use this and that. This is mandatory, while that is optional for the server. Clients to evaluate which is available and best used according to their capabilities and the current network conditions. [snip] _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 04:59:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4ke-0005KV-QH; Tue, 13 Jun 2006 04:59:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4kd-0005KL-4r for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:55 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4kb-0001op-Rm for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:55 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061483:sNHT42892032" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Notifications for multiple devices per user Date: Tue, 13 Jun 2006 05:01:07 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FF8@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: AcaMKhrhhAKGUPKVRym3wD651H6R4QCYKhxQ From: "Burger, Eric" To: "Randall Gellens" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I would offer that nothing changes for VFOLDERs referencing VFOLDERs. Take the case of MIDDLE referencing BOTTOM, where BOTTOM is a real mailbox. In order to do the right thing when BOTTOM is manipulated (renamed or deleted), the server has to have a data structure with all of the VFOLDERs that reference the base folder. In other words, the server needs to keep track of VFOLDER dependencies, whether we allow recursive VFOLDER definition or not. For example, if the user renames BOTTOM to BASE, the expression calculating MIDDLE needs to be updated to reference BASE. Once that infrastructure is in place, then recursion happens for free if we treat VFOLDERs as mailboxes. In the example given below, we have TOP referencing the VFOLDER MIDDLE referencing the real mailbox BOTTOM. If we manipulate MIDDLE, like deleting it, it would take the appropriate action on TOP. In this case, it would delete TOP. Likewise, if we delete BOTTOM, that deletes MIDDLE, which deletes TOP. -----Original Message----- From: Randall Gellens [mailto:randy@qualcomm.com]=20 Sent: Friday, June 09, 2006 8:59 PM To: Lisa Dusseault; Alexey Melnikov Cc: Lemonade WG Subject: Re: [lemonade] Notifications for multiple devices per user At 4:40 PM -0700 6/9/06, Lisa Dusseault wrote: > There's an alternative architecture for the same use case, and=20 > that's to let the notification server (SIP or XMPP, in particular)=20 > do fanout. Then the IMAP server simply sends the notification to=20 > the user's notification address (plus some application field if=20 > specified) and the user decides which devices subscribe to those=20 > notifications. > > I could be wrong but I think some of those kinds of servers can=20 > gateway to SMS so that would even work in. > > lisa > > On Jun 7, 2006, at 5:54 AM, Alexey Melnikov wrote: > >> In my private discussion with Zoltan he raised a question about=20 >> IMAP server ability to store notification information (i.e. where=20 >> the notification is to be sent) for multiple devices per user. Is=20 >> this the requirement the WG wants to consider when thinking about=20 >> notifications? Depending on the device capability, it is conceivable that the user=20 might want different criteria. So the more capable the device, the=20 more state changes and new messages it is aware of, but the more=20 limited devices would only know about the most urgent messages. I had been thinking that this would be handled by Sieve, with various=20 rules sending notifications to different devices. This would imply=20 that the rules would need to be updated as devices change. --=20 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Chance that an American cannot name a single right protected by the First Amendment: 1 in 3. (Harper's Index) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 05:11:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4vf-0002Wb-Fj; Tue, 13 Jun 2006 05:11:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4vd-0002WW-IP for lemonade@ietf.org; Tue, 13 Jun 2006 05:11:17 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4vc-00032J-3o for lemonade@ietf.org; Tue, 13 Jun 2006 05:11:17 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1Fq4va-0005g8-K9; Tue, 13 Jun 2006 09:11:14 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 0E410498003; Tue, 13 Jun 2006 10:16:45 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21098-04; Tue, 13 Jun 2006 10:16:34 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id D840C498002; Tue, 13 Jun 2006 10:16:34 +0100 (BST) Date: Tue, 13 Jun 2006 10:11:03 +0100 Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt References: <330A23D8336C0346B5C1A5BB1966664703074FF2@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664703074FF2@ATLANTIS.Brooktrout.com> MIME-Version: 1.0 Message-Id: <16208.1150189864.040403@peirce.dave.cridland.net> From: Dave Cridland To: "Burger\, Eric" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Enhancements to Internet email to support diverse service enivronments , "Zoltan.Ordogh@nokia.com" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Jun 13 10:01:01 2006, Burger, Eric wrote: > I agree > > So do I - it's a combination of two people authoring, one of whom deliberately put in alternate paragraphs. > -----Original Message----- > From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] > Sent: Wednesday, June 07, 2006 8:02 AM > To: lemonade@ietf.org > Subject: RE: [lemonade] I-D > ACTION:draft-ietf-lemonade-profile-bis-02.txt > [snip] > - Section 4.3 general. This section is confusing. Would it be > possible > to describe things from the compression level point of view saying > this > is low-level, that is application-level, and that is object-level > compression. This is believed to be better for this, that is > believed to > be better for that. For low-level use this and that, for > application-level use this and that, and for object-level use this > and > that. This is mandatory, while that is optional for the server. > Clients > to evaluate which is available and best used according to their > capabilities and the current network conditions. > [snip] > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 05:37:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq5LD-0005zI-Lf; Tue, 13 Jun 2006 05:37:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq5LC-0005sa-58 for lemonade@ietf.org; Tue, 13 Jun 2006 05:37:42 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq5LA-00054g-NT for lemonade@ietf.org; Tue, 13 Jun 2006 05:37:42 -0400 Received: from [172.16.2.198] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 13 Jun 2006 10:37:39 +0100 Message-ID: <448E875E.30509@isode.com> Date: Tue, 13 Jun 2006 10:37:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lemonade WG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [lemonade] Re: I-D ACTION:draft-melnikov-imap-expunged-01.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IMAP4 extension for reporting expunged messages > Author(s) : A. Melnikov > Filename : draft-melnikov-imap-expunged-01.txt > Pages : 12 > Date : 2006-6-12 > >This document defines an IMAP extension, which gives a disconnected > client ability to quickly learn about expunged messages. This > extension also introduces a new response that allows for a more > compact representation for a list of expunged messages. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-melnikov-imap-expunged-01.txt > > This draft is a dependency for [server side] quick reconnect draft. I think it is ready for Last Call, and I am planning on sending it to IESG no matter what the Lemonade WG decides on client side versa server side quick reconnect. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 05:49:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq5Wz-0001ff-Nj; Tue, 13 Jun 2006 05:49:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq5Wy-0001fF-0J for lemonade@ietf.org; Tue, 13 Jun 2006 05:49:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4zL-0003Wz-5C for lemonade@ietf.org; Tue, 13 Jun 2006 05:15:07 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fq4kU-00020d-Kf for lemonade@ietf.org; Tue, 13 Jun 2006 04:59:50 -0400 X-IronPort-AV: i="4.06,125,1149480000"; d="scan'208"; a="34061473:sNHT53629968" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt Date: Tue, 13 Jun 2006 05:01:00 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703074FF1@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt Thread-Index: AcaKbDhOytIIioFxSSyhTSUeAE6IfQAa6nRQAOxcSCA= From: "Burger, Eric" To: X-Spam-Score: -2.4 (--) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Any comments on Zoltan's comments? -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com]=20 Sent: Thursday, June 08, 2006 4:58 AM To: lemonade@ietf.org Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt=20 Hi all, A few comments/questions: - General: it is unclear which events will go to the clients and which = ones for admins (or both). Take OverQuota or Login as an example. = Perhaps the reason is that this draft is simply a collection of event = definitions without context? If so, it is fine, but then the bis (or the = notification draft needs to put each and every one of these into = context). - OverQuota and UnderQuota does not quite belong to "4.1. Message = Addition and Deletion" . Should we move it to "4.3. Access Accounting"? - Can we add more events? Like MailboxCreated (name), MailboxRenamed = (name, newname), MailboxDeleted (name), MailboxMoved (name, = targetmailbox)? - This is for 'folder' management, but there could be a = lot more. - Extension mechanism? (To define custom events and parameters when = needed?) Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20 Sent: 07 June, 2006 22:50 To: i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF. Title : Internet Message Store Events Author(s) : C. Newman Filename : draft-ietf-lemonade-msgevent-00.txt Pages : 14 Date : 2006-6-7 =09 One of the missing features in the existing Internet mail and messaging = standards is a facility for server-to-server and server-to- client event = notifications related to message store events. As the scope of Internet = mail expands to support more diverse media (such as voice mail), devices = (such as cell phones) and to provide rich interactions with other = services (such as web portals and legal compliance systems), the need = for an interoperable notification system increases. This document = attempts to enumerate the types of events which interest real-world = consumers of such a system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-00.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-msgevent-00.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-msgevent-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 11:15:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqAc1-0001p4-PW; Tue, 13 Jun 2006 11:15:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqAc0-0001ow-CZ for lemonade@ietf.org; Tue, 13 Jun 2006 11:15:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq9dG-0007Lw-SR for lemonade@ietf.org; Tue, 13 Jun 2006 10:12:38 -0400 Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fq9OC-0006dP-Uq for lemonade@ietf.org; Tue, 13 Jun 2006 09:57:07 -0400 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id B6A8ED6AD5F; Tue, 13 Jun 2006 09:57:03 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Tue, 13 Jun 2006 09:57:06 -0400 X-Sasl-enc: G6I/o7XanuyrI5HGiTUd/wYAxfyiF+mxpY5bzquONm5N 1150207026 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id C6AFC6CBA; Tue, 13 Jun 2006 09:57:02 -0400 (EDT) Date: Tue, 13 Jun 2006 09:56:58 -0400 From: Cyrus Daboo To: Curtis King , Randall Gellens Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Message-ID: In-Reply-To: <1C041CB4-9A26-402E-97BD-45DD6EC82CAE@mumbo.ca> References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com > <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> <1C041CB4-9A26-402E-97BD-45DD6EC82CAE@mumbo.ca> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -1.8 (-) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Enhancements to Internet email to support diverse serviceenivronments , Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Curtis, --On June 12, 2006 4:47:51 PM -0600 Curtis King wrote: >> I think there was a draft along these lines a few years ago. From >> Cyrus maybe? > > I think so. Expired, but available here: Also along the same vein: Note that both of these were also trying to deal with the problem of so called 'scalability' issues with SORT and THREAD (the fact that a client has to issue a SORT/THREAD every time the mailbox changes). That issue lead to the level of complexity that ultimately stifled the work. Its seems that now that is not as much of a concern (at least the current lemonade drafts don't really discuss interaction with SORT/THREAD). It would certainly be possible to re-do VIEW as a much simpler 'static' view of a mailbox without all the extra VIEW id stuff etc and come up with something as 'simple' as VMAILBOX. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 13:53:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqD55-0004eU-7O; Tue, 13 Jun 2006 13:53:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqD53-0004eP-Bd for lemonade@ietf.org; Tue, 13 Jun 2006 13:53:33 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqD52-0005xl-1k for lemonade@ietf.org; Tue, 13 Jun 2006 13:53:33 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DHrQ88026876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jun 2006 10:53:28 -0700 Received: from [10.0.1.5] (vpn-10-50-16-49.qualcomm.com [10.50.16.49]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DHrOKo028548; Tue, 13 Jun 2006 10:53:25 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <330A23D8336C0346B5C1A5BB1966664703074FED@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664703074FED@ATLANTIS.Brooktrout.com> Date: Tue, 13 Jun 2006 10:53:23 -0700 To: "Burger, Eric" , From: Ted Hardie Subject: Re: Submit Direction (was RE: [lemonade] COMPRESS Thoughts) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 5:00 AM -0400 6/13/06, Burger, Eric wrote: >. > >Thing 5: I don't want to expand our work before we finish our committed >work. > > >Given these Things, I would offer we work out Compression for IMAP >first. We need data collection (what resources get saved, what >resources get spent, is CPU really that much more expensive than Radio >[I thought not :->], etc.). Once we finish Compression for IMAP, doing >a Compression for SUBMIT should be a trivial exercise for the reader. > >OK? Speaking as a technical contributor, I think it is better to consider at least one aspect of the problem together: the compression and decompression costs. There are, for example, algorithms like Deflate that use a single-pass deflation but require two passes for compression. If we don't take into account now the likelihood that there will be compression in the terminal, we may end up preferring methods or algorithms that have different trade-offs when the terminal is doing the compression. regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 15:00:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqE82-000808-Od; Tue, 13 Jun 2006 15:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqE81-000800-Ls for lemonade@ietf.org; Tue, 13 Jun 2006 15:00:41 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqE7z-0003cP-A0 for lemonade@ietf.org; Tue, 13 Jun 2006 15:00:41 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DJ0bYk003375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jun 2006 12:00:38 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DJ0Z9k026364; Tue, 13 Jun 2006 12:00:36 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 13 Jun 2006 11:59:21 -0700 To: Curtis King From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:33 PM -0600 6/12/06, Curtis King wrote: >>>> On the COPY/APPEND issue, if vfolders are distinguishable, then >>>> perhaps it is OK if a COPY/APPEND might seem to vanish. >>> >>> Having a message disappear which you just copied/appended will >>> be very confusing to people. No matter how the mailbox is marked. >> >> Confusing to *people* yes. But the *client* needn't be confused, >> and if the client isn't confused, then the user doesn't need to be >> confused either. >> >> What I was suggesting was that if the client knows it has selected >> a vmailbox, and it does a copy or append, then as long as it gets >> an OK response it can present the message to the user as being >> part of the mailbox. Especially if it has received the UID of the >> appended/copied message in the command response. > > Ok - Then what does VMAILBOX get me? If I have to merge a view and > the append uid on the client side, why not do that from the start > using search? > >> >>> If the client controls the view it can add appended messages to >>> view if needed. >> >> A good point, but it would be awkward for the client to need to >> update the vmailbox filter criteria each time it does a copy or >> append. > > We are suggesting the same thing, I was thinking the client would > merge the results of the search with uid returned from the copy or > append. We can do this now using SEARCH and UIDPLUS. VMAILBOX does > not make this any easier than the standard IMAP commands. Can you maybe write up a quick proto-draft that proposes this? I think we should go with whichever approach is simpler for the client and hopefully also easier for the server to support. Because time is an issue I think the group needs to see the counter-proposal right away. My understanding is that vmailbox has two primary use cases: (1) allowing a client to get notifications only for state changes to a subset of "interesting" messages, and (2) allowing a client to conceive of a mailbox as a subset of "interesting" messages to reduce the size of its cache and the amount of traffic exchanged with the server. If this understanding is correct, and your counter-proposal supports both uses but has advantages, I'd strongly support us adopting it. We are in a hurry, but we also want the best solution. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Arithmetic is being able to count up to twenty without taking off your shoes. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 15:13:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEKI-0004Om-8D; Tue, 13 Jun 2006 15:13:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEKH-0004Nn-96 for lemonade@ietf.org; Tue, 13 Jun 2006 15:13:21 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqEKF-0004BO-T8 for lemonade@ietf.org; Tue, 13 Jun 2006 15:13:21 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DJDB39004406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jun 2006 12:13:12 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DJD98q010985; Tue, 13 Jun 2006 12:13:11 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <330A23D8336C0346B5C1A5BB1966664703074FED@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664703074FED@ATLANTIS.Brooktrout.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 13 Jun 2006 12:12:34 -0700 To: "Burger, Eric" , From: Randall Gellens Subject: Re: Submit Direction (was RE: [lemonade] COMPRESS Thoughts) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 5:00 AM -0400 6/13/06, Eric Burger wrote: > Mea Culpa: I used poor language when attempting to describe the > asymmetrical nature of compression. Re-reading what I wrote, and the > subsequent thread, it is apparent that what I wrote made it sound like > we were ONLY going to have compression in the Server->Client direction, > and we would NOT have compression in the Client->Server direction. > > Thing 1: That was not the consensus. The consensus was there could be > situations where you would want compression all the time in both > directions (the typical case); there could be situations where you would > want compression only Server->Client but not Client->Server; for that > matter, there theoretically could be situations where you would want > compression only Client->Server (although I cannot think of any). The > point I was trying to make is that we needed to handle compression in > one direction, AS WELL AS compression in both directions. True, but subsequent discussion has led me to doubt this requirement. That is, I think we need to consider the additional complexity and any other costs of allowing for compression in only one direction against its utility. If a client, especially on a mobile device, which is capable of compression (and decompression) would always want it enabled, then there may not be any use in adding additional complexity and commands to negotiate compression in each direction separately. > Thing 2: The entire discussion revolved around IMAP. As has been > pointed out on the list, compression would be an incredibly useful > feature for SUBMIT. During the discussion I think there was mention of the benefit for submission. My recollection is that it was mentioned as one of the main benefits of client to server compression (the other being the fact that many IMAP clients compose command sequences such that only a few items differ between them). > > Thing 3: Compression on SUBMIT does not depend on compression for IMAP. Depends what is meant by "depend" -- I think the mechanisms and negotiation should be as similar as possible. > > Thing 4: Lemonade does not strictly depend on compression to get > published. You mean that we can publish profile-bis and the other work that is referenced by it before compression is finished. I'd agree with that. We can always do another update of profile to include compression. > Thing 5: I don't want to expand our work before we finish our committed > work. I'd agree, but I thought compression was in our work, and compression includes message submission as well as retrieval. > Given these Things, I would offer we work out Compression for IMAP > first. We need data collection (what resources get saved, what > resources get spent, is CPU really that much more expensive than Radio > [I thought not :->], etc.). Once we finish Compression for IMAP, doing > a Compression for SUBMIT should be a trivial exercise for the reader. > > OK? I'd rather consider both submission and retrieval together. If that means we publish profile-bis before publishing compression, that would be OK. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Who tells the stories of a culture really governs human behavior. It used to be the parent, the school, the church, the community. Now it's a handful of global conglomerates that have nothing to tell, but a great deal to sell. --George Gerbner, dean of Annenberg School of Communication _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 15:36:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEgC-0005vx-1Q; Tue, 13 Jun 2006 15:36:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEgA-0005vs-Ot for lemonade@ietf.org; Tue, 13 Jun 2006 15:35:58 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqEg8-0005IB-8B for lemonade@ietf.org; Tue, 13 Jun 2006 15:35:58 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id DDB6D4AC74; Tue, 13 Jun 2006 21:35:54 +0200 (CEST) Message-Id: Date: Tue, 13 Jun 2006 21:37:29 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens writes, answering Curtis King: > Can you maybe write up a quick proto-draft that proposes this? Seconded. Strongly. > I think we should go with whichever approach is simpler for the client > and hopefully also easier for the server to support. Because time is > an issue I think the group needs to see the counter-proposal right > away. I agree. > My understanding is that vmailbox has two primary use cases: (1) > allowing a client to get notifications only for state changes to a > subset of "interesting" messages, and (2) allowing a client to > conceive of a mailbox as a subset of "interesting" messages to reduce > the size of its cache and the amount of traffic exchanged with the > server. If this understanding is correct, and your counter-proposal > supports both uses but has advantages, I'd strongly support us > adopting it. FWIW, I have users for whom a goal is to share vfolders among clients, zero or more of which aren't going to support lemonade in a hurry. The latter may seem necessarily irrelevant to lemonade, but I think it's worth keeping in mind: People won't ditch their desktop clients just because they get a new mobile device, and for a desktop client, implementing lemonade is not going to be a very a high priority. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 15:38:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEid-0006lk-LY; Tue, 13 Jun 2006 15:38:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEic-0006lf-Md for lemonade@ietf.org; Tue, 13 Jun 2006 15:38:30 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqEib-0005TA-3J for lemonade@ietf.org; Tue, 13 Jun 2006 15:38:30 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FqEiV-0004VT-I7; Tue, 13 Jun 2006 19:38:23 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 889D0498002; Tue, 13 Jun 2006 20:43:58 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28882-03; Tue, 13 Jun 2006 20:43:53 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 6A5E3498003; Tue, 13 Jun 2006 20:43:53 +0100 (BST) Date: Tue, 13 Jun 2006 20:38:17 +0100 Subject: Re: Submit Direction (was RE: [lemonade] COMPRESS Thoughts) References: <330A23D8336C0346B5C1A5BB1966664703074FED@ATLANTIS.Brooktrout.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <16208.1150227498.261524@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Jun 13 20:12:34 2006, Randall Gellens wrote: > At 5:00 AM -0400 6/13/06, Eric Burger wrote: > >> Mea Culpa: I used poor language when attempting to describe the >> asymmetrical nature of compression. Re-reading what I wrote, and >> the >> subsequent thread, it is apparent that what I wrote made it sound >> like >> we were ONLY going to have compression in the Server->Client >> direction, >> and we would NOT have compression in the Client->Server direction. >> >> Thing 1: That was not the consensus. The consensus was there >> could be >> situations where you would want compression all the time in both >> directions (the typical case); there could be situations where >> you would >> want compression only Server->Client but not Client->Server; for >> that >> matter, there theoretically could be situations where you would >> want >> compression only Client->Server (although I cannot think of any). >> The >> point I was trying to make is that we needed to handle >> compression in >> one direction, AS WELL AS compression in both directions. > > True, but subsequent discussion has led me to doubt this > requirement. That is, I think we need to consider the additional > complexity and any other costs of allowing for compression in only > one direction against its utility. If a client, especially on a > mobile device, which is capable of compression (and decompression) > would always want it enabled, then there may not be any use in > adding additional complexity and commands to negotiate compression > in each direction separately. > > Something Ted said made me think - not only might there be (non-mobile) cases where compression is too expensive for the device, but there might also be cases where a different algorithm could be used in each direction. >> Thing 2: The entire discussion revolved around IMAP. As has been >> pointed out on the list, compression would be an incredibly useful >> feature for SUBMIT. > > During the discussion I think there was mention of the benefit for > submission. My recollection is that it was mentioned as one of the > main benefits of client to server compression (the other being the > fact that many IMAP clients compose command sequences such that > only a few items differ between them). > > FWIW, I've implemented this, and will happily provide xml2rfc or text defining it for ESMTP and ACAP, too. >> Thing 3: Compression on SUBMIT does not depend on compression for >> IMAP. > > Depends what is meant by "depend" -- I think the mechanisms and > negotiation should be as similar as possible. > > I think they're so astoundingly simple to define for IMAP, ACAP and ESMTP all on one document that we might as well. (I know ACAP isn't required for Lemonade, it's just sufficiently simple to define all three in one place. POP3 could also be added sanely). >> Thing 4: Lemonade does not strictly depend on compression to get >> published. > > You mean that we can publish profile-bis and the other work that is > referenced by it before compression is finished. I'd agree with > that. We can always do another update of profile to include > compression. > > We have a generally good specification for compression in IMAP. While I agree that we wouldn't want to hold up Profile bis "just" for compression, I also think it's worth getting compression done, and I believe compression to be pretty much ready. As I see compression, bar some formality of reapplying the whole thing to ESMTP etc, the only remaining open issues are: a) if, and how, we turn compression off on a running connection, b) if we allow assymetric compression algorithms (including no compression), c) whether we can apply compression before SASL (yes please), and if so, whether we can then retrospectively apply a SASL encryption/integrity layer. (Up to server implementors, I think it's easy, I may be deluded - this requires insertion of a layer into the stack at runtime, I think it can be specified safely and negotiated by both ends at runtime). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 15:45:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEpN-00016P-LH; Tue, 13 Jun 2006 15:45:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEpM-00016K-BN for lemonade@ietf.org; Tue, 13 Jun 2006 15:45:28 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqEpL-0006oj-1b for lemonade@ietf.org; Tue, 13 Jun 2006 15:45:28 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DJjM4C007292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jun 2006 12:45:23 -0700 Received: from [10.0.1.5] (vpn-10-50-16-49.qualcomm.com [10.50.16.49]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DJjJGF012118; Tue, 13 Jun 2006 12:45:20 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <16208.1150227498.261524@peirce.dave.cridland.net> References: <330A23D8336C0346B5C1A5BB1966664703074FED@ATLANTIS.Brooktrout.com> <16208.1150227498.261524@peirce.dave.cridland.net> Date: Tue, 13 Jun 2006 12:45:18 -0700 To: Dave Cridland , Randall Gellens From: Ted Hardie Subject: Re: Submit Direction (was RE: [lemonade] COMPRESS Thoughts) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 8:38 PM +0100 6/13/06, Dave Cridland wrote: >O >> >Something Ted said made me think - not only might there be (non-mobile) cases where compression is too expensive for the device, but there might also be cases where a different algorithm could be used in each direction. That's certainly true, and it may mean we don't need to be too concerned about picking a single compression algorithm for both directions. If the numbers support that, I would certainly be fine with that result. I just think it is more sensible to consider them at the same, since that allows us to take into account all of the variable (compression and decompression efficiency, plus total number of methods for which support is needed). Just my opinion, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 18:09:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqH4k-0004xY-5I; Tue, 13 Jun 2006 18:09:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqH4j-0004xS-7o for lemonade@ietf.org; Tue, 13 Jun 2006 18:09:29 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqH4h-0006Er-5t for lemonade@ietf.org; Tue, 13 Jun 2006 18:09:29 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FqH4f-0003vM-25; Tue, 13 Jun 2006 22:09:25 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id D38FF498003; Tue, 13 Jun 2006 23:15:00 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29566-10; Tue, 13 Jun 2006 23:14:52 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id A8CAA498002; Tue, 13 Jun 2006 23:14:51 +0100 (BST) Date: Tue, 13 Jun 2006 23:09:14 +0100 Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> In-Reply-To: MIME-Version: 1.0 Message-Id: <10595.1150236555.436597@peirce.dave.cridland.net> From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: multipart/mixed; boundary="10595.1150236554.438109@peirce.dave.cridland.net" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: f9c0d585568a86447c98453afdf94aa0 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --10595.1150236554.438109@peirce.dave.cridland.net Content-Type: text/plain; charset="us-ascii"; format="flowed" On Tue Jun 13 20:37:29 2006, Arnt Gulbrandsen wrote: > Randall Gellens writes, answering Curtis King: >> Can you maybe write up a quick proto-draft that proposes this? > > Seconded. Strongly. > > Done - attached is what Curtis and myself thrashed out as something that was essentially optimizing what clients can do already. >> My understanding is that vmailbox has two primary use cases: (1) >> allowing a client to get notifications only for state changes to a >> subset of "interesting" messages, and (2) allowing a client to >> conceive of a mailbox as a subset of "interesting" messages to >> reduce the size of its cache and the amount of traffic exchanged >> with the server. If this understanding is correct, and your >> counter-proposal supports both uses but has advantages, I'd >> strongly support us adopting it. > > This is primarily aimed at item (2). I don't perceive getting state changes for messages outside the criteria to be a problem, I simply don't think mailboxes with sufficient activity for this to be a problem exist such that they're likely to be looked at on a mobile device. It can be used to provide a client-side virtual mailbox "user experience", if desired. Polymer, my own client, is already doing something fairly similar to provide filtered views onto mailboxes - if this extension were supported, I could do it much more efficiently. Internally, Polymer actually treats these views as a mailbox. There are other uses I've not fully considered - it's possible to have multiple "virtual mailboxes" selected concurrently with this extension in a single connection, in effect, and it's also possible to use the extension for colourizing summary listings, for instance. The extension as described is intended to be fitted onto both SEARCH and SORT, incidentally, and as such, exceeds the capability of the current VFOLDER draft in some respects. I'm afraid I've not devoted much time into the Extended SORT, but if you look closely, all the hooks are there. We haven't considered THREAD, although I'd be interested in exploring that, but I don't think we have the time to nail it. > FWIW, I have users for whom a goal is to share vfolders among > clients, zero or more of which aren't going to support lemonade in > a hurry. The latter may seem necessarily irrelevant to lemonade, > but I think it's worth keeping in mind: People won't ditch their > desktop clients just because they get a new mobile device, and for > a desktop client, implementing lemonade is not going to be a very a > high priority. Yes, there's a considerable number of use-cases for which you do need a real virtual mailbox - if you'll pardon the expression. I'm quite confident that virtual mailboxes are a useful area of research, and a useful feature to have. I have been convinced by Curtis and others, though, that they're sufficiently complex that they are inadvisable to mandate in Lemonade. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade --10595.1150236554.438109@peirce.dave.cridland.net Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-cridland-imap-contexts.txt" Network Working Group D. Cridland Internet-Draft Inventure Systems Ltd Expires: December 15, 2006 C. King Isode Limited June 13, 2006 Contexts for IMAP4 draft-cridland-imap-context Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 15, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, and a similarly powerful SORT extension, but lacks the ability to create live, updated results which can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. Cridland & King Expires December 15, 2006 [Page 1] Internet-Draft IMAP CONTEXT June 2006 Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Changes . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Extended SORT . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Context Hint . . . . . . . . . . . . . . . . . . . . . . . 4 3.4. Notifications of changes . . . . . . . . . . . . . . . . . 4 3.4.1. ADDTO Response . . . . . . . . . . . . . . . . . . . . 4 3.4.2. REMOVEFROM Response . . . . . . . . . . . . . . . . . 5 3.5. Partial results . . . . . . . . . . . . . . . . . . . . . 5 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Virtual Mailboxes . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Cridland & King Expires December 15, 2006 [Page 2] Internet-Draft IMAP CONTEXT June 2006 1. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client messaging user agent and IMAP4rev1 ([RFC3501]) server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Other capitalised words are typically names of IMAP extensions or commands - these are uppercased for clarity only, and are case- insensitive. [[ Editorial comments are like this. XML2RFC working source is held at http://svn.dave.cridland.net/svn/ietf-drafts/ draft-cridland-imap-contexts.xml ]] 2. Introduction Although the basic SEARCH command defined in [RFC3501], as enhanced by [I-D.melnikov-imap-search-ret], is relatively compact in its representation, this reduction only saves a certain amount of data, and huge mailboxes can overwhelm the storage available for results on even relatively high-end desktop machines. For SORT, as defined in [I-D.ietf-imapext-sort], use of set-syntax saves considerably less, and so the problem is more acute. This memo borrows concepts from [RFC2244], providing a windowed view onto search and sort results, as well as low-bandwidth updates. 3. Protocol Changes 3.1. Overview This extension is present in any IMAP4rev1 server which includes the string "CONTEXTS", or any string beginning "CONTEXTS=", within its advertised capabilities. These servers handle an extended form of the SORT command accepting return options similar to SEARCH, and an extended sorted results response ESORT, described in Section 3.2, which mirrors the extended SEARCH described in [RFC4466]. [[ Of course, if this were moved to SORT, we'd be happy. ]] Such servers also accept three additional return options, and provide Cridland & King Expires December 15, 2006 [Page 3] Internet-Draft IMAP CONTEXT June 2006 one new result data item, and two new responses. The first search return option is CONTEXT, an optional hint that the criteria will be used repeatedly, and is defined in Section 3.3. The second is NOTIFY, which causes the server to provide efficient notifications of changes to the results. This is defined in Section 3.4. Finally, the PARTIAL return specifier causes the server to return a subset of the results in set-syntax. This allows for "virtual scrollbars" and other UI conveniences to be achieved without having to preload the entire result set, and is described in Section 3.5. 3.2. Extended SORT [[ This needs to describe extended SORT in the same terms as RFC4466. For now, just close your eyes and imagine something largely similar to ESEARCH and SEARCH return options. ]] 3.3. Context Hint The search return option CONTEXT SHOULD be used by a client to indicate that subsequent use of the criteria (and sort order, for SORT) are likely. Servers MAY ignore this return option, or use it as a hint to maintain a full result set, or index. 3.4. Notifications of changes The search return option NOTIFY, if used by a client, causes the server to issue unsolicited notifications containing updates to the SEARCH or SORT results. These results are carried in ADDTO and REMOVEFROM responses. Both ADDTO and REMOVEFROM responses SHOULD be delivered to clients in a timely manner, as and when results changes, whether by new messages arriving in the mailbox, metadata such as flags being changed, or messages being expunged. Unlike [RFC2244], there is no requirement that a context need be created with CONTEXT to use NOTIFY. 3.4.1. ADDTO Response The ADDTO response contains, as payload, a search correlator (defined in [RFC4466]), an optional UID indicator, a position and a set of results to be inserted at the position. For SEARCH results, the position MAY be zero, and MAY be ignored by clients. For SORT results, the position MUST be the position of the first message Cridland & King Expires December 15, 2006 [Page 4] Internet-Draft IMAP CONTEXT June 2006 referred to in the sequence-set of results, counting 1 as the first position. 3.4.2. REMOVEFROM Response The REMOVEFROM response contains, as payload, a search correlator, an optional UID indicator, and a set of results to be removed. The results to be removed are referenced by message number or UID, as appropriate, and need not be in the same order as the results. Servers SHOULD sort the results in order to use the sequence-set syntax as efficiently as possible. 3.5. Partial results The PARTIAL search return option causes the server to provide in an ESEARCH or ESORT response the range from the results denoted by the sequence range given as the mandatory argument. The first result is 1, thus the first 500 results would be obtained by a return option of "PARTIAL 1:500", and the second 500 by "PARTIAL 501:1000". The subset of results are returned in sequence-set syntax, and servers SHOULD order results from a SEARCH for maximum efficiency. Clients need not request PARTIAL results in any particular order. Server implementations MAY cache results from a PARTIAL search in order to make subsequent PARTIAL searches more efficient, perhaps by recommencing a subsequent PARTIAL search where a previous search left off, however servers MUST behave identically whether or not internal caching is taking place, therefore any such cache is required to be updated as changes to the mailbox occur. Cridland & King Expires December 15, 2006 [Page 5] Internet-Draft IMAP CONTEXT June 2006 4. Formal Syntax The collected formal syntax. This includes definitions from [RFC3501] and [RFC4466], and uses ABNF as defined in [RFC4234]. addto-position = number ;; Number can be 0 for SEARCH result additions. ;; number from RFC3501 addto-response = "ADDTO" search-correlator [ SP UID ] SP addto-position SP sequence-set ;; search-correlator from RFC4466. removefrom-response = "REMOVEFROM" search-correlator [ SP UID ] SP sequence-set ;; REMOVEFROM response only contains removed UIDs ;; sequence-set from RFC3501 modifier-context = "CONTEXT" modifier-partial = "PARTIAL" SP seq-range ;; seq-range from RFC3501 modifier-notify = "NOTIFY" search-return-opt =/ modifier-context / modifier-partial / modifier-notify ;; All conform to search-return-opt, from RFC4466 ret-data-partial = "PARTIAL" SP "(" seq-range SP sequence-set ")" ;; sequence-set from RFC3501 search-return-data =/ ret-data-partial ;; Conforms to search-return-data, from RFC4466. 5. Security Considerations The authors cannot think of any. 6. IANA Considerations [[ The extension needs registering - TODO: find correct text for this bit. ]] Cridland & King Expires December 15, 2006 [Page 6] Internet-Draft IMAP CONTEXT June 2006 7. Acknowledgements Much of the design of this extension can be found in ACAP. Valuable comments, both in agreement and in dissent, were received from YOUR_NAME_HERE, and many of these comments have had significant influence on the design or the text. The authors are grateful to all those involved, including those not mentioned here. 8. References 8.1. Normative References [I-D.ietf-imapext-sort] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION", draft-ietf-imapext-sort-17 (work in progress), May 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006. 8.2. Informative References [I-D.melnikov-imap-search-ret] Melnikov, A. and D. Cridland, "IMAP4 extension to SEARCH command for controlling what kind of information is returned", draft-melnikov-imap-search-ret-02 (work in progress), October 2005. [RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997. Appendix A. Virtual Mailboxes It is possible to use the facilities described within this memo to create a facility largely similar to a virtual mailbox, but handled on the client side. Because the messages are still referred to by their native UIDs, and there is no constraint to fit the IMAP mailbox Cridland & King Expires December 15, 2006 [Page 7] Internet-Draft IMAP CONTEXT June 2006 interface, this is a simpler method without the potential pitfalls of stretching metaphors. In lieu of a SELECT, the client performs a SEARCH RETURN (COUNT NOTIFY), which provides a count, and requests updates to the results. For whichever area is currently in view in the summary window, it can then perform a SEARCH RETURN (PARTIAL from:to), which will return the required results. There is no SELECT from the client, and no possibility of duplicate message downloads, and therefore this method of providing virtual mailboxes is actually more efficient. Cridland & King Expires December 15, 2006 [Page 8] Internet-Draft IMAP CONTEXT June 2006 Authors' Addresses Dave Cridland Inventure Systems Ltd 21, Heol Bronwydd Caerfyrddin, Cymru SA31 2AJ GB Email: dave.cridland@invsys.co.uk Curtis King Isode Limited 5 Castle Business Village 36, Station Road Hampton, Middlesex TW12 2BX GB Email: cking@mumbo.ca Cridland & King Expires December 15, 2006 [Page 9] Internet-Draft IMAP CONTEXT June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Cridland & King Expires December 15, 2006 [Page 10] --10595.1150236554.438109@peirce.dave.cridland.net Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --10595.1150236554.438109@peirce.dave.cridland.net-- From lemonade-bounces@ietf.org Tue Jun 13 18:25:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHKg-0003lB-JG; Tue, 13 Jun 2006 18:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHKg-0003kz-1l for lemonade@ietf.org; Tue, 13 Jun 2006 18:25:58 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHKe-0007CA-ME for lemonade@ietf.org; Tue, 13 Jun 2006 18:25:58 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DMPpOs026205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jun 2006 15:25:52 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DMPdqg008678; Tue, 13 Jun 2006 15:25:40 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <330A23D8336C0346B5C1A5BB1966664703074FEA@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664703074FEA@ATLANTIS.Brooktrout.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 13 Jun 2006 15:12:21 -0700 To: "Burger, Eric" , "Alexey Melnikov" , From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 5:00 AM -0400 6/13/06, Eric Burger wrote: > Also don't forget that under any circumstance, the server could decide > 'later' that it cannot honor a request. This is independent of whether > we have the server say, "I might have so many sessions available for > you" when asked or if the server doesn't say anything about how many > sessions are (could be) available. Once you have to write the code for > the client to handle that situation, it turns out there is no value to > the server giving an indication as to how many sessions are available > for you. Thus we took out reporting on the number of available server > sessions from the specification. If we expect clients to maintain multiple active sessions, then there may be some benefit in providing guidance (not a requirement) as to how many sessions a server should permit and a client can expect. Guidance as to what is reasonable. Informative, not normative. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- We adore chaos because we love to produce order. --M. C. Escher _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHKj-0003mU-QR; Tue, 13 Jun 2006 18:26:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHKi-0003mP-8v for lemonade@ietf.org; Tue, 13 Jun 2006 18:26:00 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHKg-0007CM-To for lemonade@ietf.org; Tue, 13 Jun 2006 18:26:00 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DMPrTZ026220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jun 2006 15:25:54 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DMPdqk008678; Tue, 13 Jun 2006 15:25:52 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 13 Jun 2006 15:24:57 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 9:37 PM +0200 6/13/06, Arnt Gulbrandsen wrote: > for a desktop client, implementing lemonade is not going to be a > very a high priority. This may depend on what advantages lemonade offers. Forward-without-download is not likely to be something most desktop clients would be interested in, because they would still need to support old servers and they already have a composition and submission model. However, anything that speeds up resynchronizing large mailboxes might be beneficial enough that desktop clients implement the new extensions. Compression is another extension that would be helpful, especially when users have dial-up. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The budget should be balanced. The treasury should be refilled. Public debt should be reduced. The arrogance of public officials should be controlled. --Marcus Tullius Cicero (106-43 B.C.) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 18:33:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHSC-0007Oz-Hi; Tue, 13 Jun 2006 18:33:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHSB-0007Or-Ha for lemonade@ietf.org; Tue, 13 Jun 2006 18:33:43 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHSA-0000DG-6z for lemonade@ietf.org; Tue, 13 Jun 2006 18:33:43 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DMXbtT028826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jun 2006 15:33:38 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5DMXZD0004645; Tue, 13 Jun 2006 15:33:36 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <16208.1150227498.261524@peirce.dave.cridland.net> References: <330A23D8336C0346B5C1A5BB1966664703074FED@ATLANTIS.Brooktrout.com> <16208.1150227498.261524@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 13 Jun 2006 15:32:10 -0700 To: Dave Cridland From: Randall Gellens Subject: Re: Submit Direction (was RE: [lemonade] COMPRESS Thoughts) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 8:38 PM +0100 6/13/06, Dave Cridland wrote: > a) if, and how, we turn compression off on a running connection, > > b) if we allow assymetric compression algorithms (including no compression), > > c) whether we can apply compression before SASL (yes please), and > if so, whether we can then retrospectively apply a SASL > encryption/integrity layer. (Up to server implementors, I think > it's easy, I may be deluded - this requires insertion of a layer > into the stack at runtime, I think it can be specified safely and > negotiated by both ends at runtime). This last one scares me. I think we need to be clear on how compression, SASL, and TLS work together and in what order they are negotiated. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Green light in A.M. for new projects. Red light in P.M. for traffic tickets. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 18:39:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHXw-0001CL-GK; Tue, 13 Jun 2006 18:39:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHXv-0001BK-0E for lemonade@ietf.org; Tue, 13 Jun 2006 18:39:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHXu-0002RM-SH for lemonade@ietf.org; Tue, 13 Jun 2006 18:39:38 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqHXs-0005Q3-UV for lemonade@ietf.org; Tue, 13 Jun 2006 18:39:38 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FqHXr-0002Ku-EJ; Tue, 13 Jun 2006 22:39:35 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id E3FCD498003; Tue, 13 Jun 2006 23:45:10 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29769-09; Tue, 13 Jun 2006 23:45:06 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 41A4E498002; Tue, 13 Jun 2006 23:45:06 +0100 (BST) Date: Tue, 13 Jun 2006 23:39:28 +0100 Subject: Re: Submit Direction (was RE: [lemonade] COMPRESS Thoughts) References: <330A23D8336C0346B5C1A5BB1966664703074FED@ATLANTIS.Brooktrout.com> <16208.1150227498.261524@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <10595.1150238369.793108@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: -2.6 (--) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Jun 13 23:32:10 2006, Randall Gellens wrote: > At 8:38 PM +0100 6/13/06, Dave Cridland wrote: > >> a) if, and how, we turn compression off on a running connection, >> >> b) if we allow assymetric compression algorithms (including no >> compression), >> >> c) whether we can apply compression before SASL (yes please), and >> if so, whether we can then retrospectively apply a SASL >> encryption/integrity layer. (Up to server implementors, I think >> it's easy, I may be deluded - this requires insertion of a layer >> into the stack at runtime, I think it can be specified safely and >> negotiated by both ends at runtime). > > This last one scares me. I think we need to be clear on how > compression, SASL, and TLS work together and in what order they are > negotiated. Well, here's my view: Compressing before SASL yields a marked saving for the SASL exchanges, especially for exchanges like DIGEST-MD5 where there's significant chatter. So I want this facility. I don't think it's a big deal to insert an encryption layer underneath a running compression layer, as long as the point where that happens is clearly specified. I think it's probably a layer violating hack, but equally I don't think it'd cause anyone any problems. However, if the consensus is that it's too scary, I'd be content with specifying that SASL MUST NOT negotiate an encryption or integrity layer if compression has already been negotiated. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 13 19:21:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqICl-0001Zd-MB; Tue, 13 Jun 2006 19:21:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqICk-0001Wa-BY for lemonade@ietf.org; Tue, 13 Jun 2006 19:21:50 -0400 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHyw-0005hn-AJ for lemonade@ietf.org; Tue, 13 Jun 2006 19:07:35 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39165) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1FqHyo-0003MM-Nn (Exim 4.54) (return-path ); Wed, 14 Jun 2006 00:07:26 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FqHyl-00008h-NQ (Exim 4.53) (return-path ); Wed, 14 Jun 2006 00:07:23 +0100 Date: Wed, 14 Jun 2006 00:07:23 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Randall Gellens Subject: Re: Submit Direction (was RE: [lemonade] COMPRESS Thoughts) In-Reply-To: Message-ID: References: <330A23D8336C0346B5C1A5BB1966664703074FED@ATLANTIS.Brooktrout.com> <16208.1150227498.261524@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 13 Jun 2006, Randall Gellens wrote: > At 8:38 PM +0100 6/13/06, Dave Cridland wrote: > > > > c) whether we can apply compression before SASL (yes please), and if so, > > whether we can then retrospectively apply a SASL encryption/integrity layer. > > (Up to server implementors, I think it's easy, I may be deluded - this > > requires insertion of a layer into the stack at runtime, I think it can be > > specified safely and negotiated by both ends at runtime). > > This last one scares me. I think we need to be clear on how compression, > SASL, and TLS work together and in what order they are negotiated. It's probably worth looking at http://www.jabber.org/jeps/jep-0170.html since XMPP already has TLS, SASL, and compression layers, and documented layer ordering. If lemonade decides differently the JEP may be updated to follow suit. Given that you know fairly early on whether SASL is going to result in an encryption layer, based on the mechanism you choose and perhaps mechanism-specific options, it might be worth varying the recommended order accordingly. Tony. -- f.a.n.finch http://dotat.at/ BAILEY: WEST OR NORTHWEST 5 OR 6, VEERING NORTH 4 OR 5, THEN BACKING SOUTHWEST 5 OR 6 LATER. OCCASIONAL RAIN. MODERATE OR GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 14 03:37:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqPwB-0001Fr-5d; Wed, 14 Jun 2006 03:37:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqPwA-0001Fm-3e for lemonade@ietf.org; Wed, 14 Jun 2006 03:37:14 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqPw8-0000GL-MU for lemonade@ietf.org; Wed, 14 Jun 2006 03:37:14 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 8E2924AC4B; Wed, 14 Jun 2006 09:37:11 +0200 (CEST) Message-Id: Date: Wed, 14 Jun 2006 09:38:48 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> In-Reply-To: <10595.1150236555.436597@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I'll answer later today. But first: Dave Cridland writes: > I'm quite confident that virtual mailboxes are a useful area of > research, and a useful feature to have. I have been convinced by > Curtis and others, though, that they're sufficiently complex that > they are inadvisable to mandate in Lemonade. I don't have a strong opinion on whether they're advisable to mandate in lemonade. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 14 05:10:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqROH-00032o-Cp; Wed, 14 Jun 2006 05:10:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqROH-00032j-4G for lemonade@ietf.org; Wed, 14 Jun 2006 05:10:21 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqROF-0008Mo-MX for lemonade@ietf.org; Wed, 14 Jun 2006 05:10:21 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 90AFA4AC4B for ; Wed, 14 Jun 2006 11:10:18 +0200 (CEST) Message-Id: Date: Wed, 14 Jun 2006 11:11:55 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Draft Minutes, Interim Day 1 References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com> <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> <1C041CB4-9A26-402E-97BD-45DD6EC82CAE@mumbo.ca> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Cyrus Daboo writes: > Note that both of these were also trying to deal with the problem of > so called 'scalability' issues with SORT and THREAD (the fact that a > client has to issue a SORT/THREAD every time the mailbox changes). > That issue lead to the level of complexity that ultimately stifled > the work. Its seems that now that is not as much of a concern (at > least the current lemonade drafts don't really discuss interaction > with SORT/THREAD). Right. Because it's orthogonal. The SORT/THREAD problem applies to users.daboo.ypsilon in the same way whether that mailbox is "virtual" or "real". Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 14 12:01:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXna-0001go-Er; Wed, 14 Jun 2006 12:00:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXnN-00015L-UU for lemonade@ietf.org; Wed, 14 Jun 2006 12:00:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXHX-0003Q0-5H for lemonade@ietf.org; Wed, 14 Jun 2006 11:27:47 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqX2q-0004bC-3m for lemonade@ietf.org; Wed, 14 Jun 2006 11:12:38 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id D4EFB4AC74; Wed, 14 Jun 2006 17:12:28 +0200 (CEST) Message-Id: Date: Wed, 14 Jun 2006 17:14:05 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> In-Reply-To: <10595.1150236555.436597@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: -2.2 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > On Tue Jun 13 20:37:29 2006, Arnt Gulbrandsen wrote: >> Randall Gellens writes, answering Curtis King: >>> Can you maybe write up a quick proto-draft that proposes this? >> >> Seconded. Strongly. > > Done - attached is what Curtis and myself thrashed out as something > that was essentially optimizing what clients can do already. Here's how I read it, and what I've thought of: In the server's RAM, CONTEXTS and VFOLDER seem to be the same. In both cases, the server keeps track of modsequences and updates UID sets in RAM. For CONTEXTS, it's one UID set, for VFOLDER, it's two UID sets and a mailbox name. In VFOLDER, all that information is stored persistently on the server. In CONTEXTS, parts of it is stored on the client, and parts may not be stored at all, but instead recomputed. If the client uses CONDSTORE and stores the result sets persistently, performance at session start time is essentially the same for the two. If the client doesn't use CONDSTORE, or if it issues SEARCHes for all contexts when it SELECTs the backing mailbox, the server groans under the load. For CONTEXTS, there is a nice fallback to working with stock IMAP servers. For VFOLDER, there is none. For CONTEXTS, two clients don't stay in sync, unless the clients share state in some way outside the extension. VFOLDER works with vanilla and extended IMAP clients. VFOLDER access is governed by ACL, CONTEXTS avoids all that. When a mailbox is deleted or renamed, VFOLDER specifies a certain behaviour (which may or may not be considered good behaviour), CONTEXTS makes it depend on whether the rename/delete was issued by the context-owning client or some other. That's it, right? Have I missed anything? If I trust clients to use good IMAP, have decent caching and want to work with plain IMAP servers, I prefer CONTEXTS. If I don't, or I want the extension to be valuable to plain IMAP clients, I prefer VFOLDER. So what's most desirable within the charter of Lemonade? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 14 13:39:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqZL4-0005dc-Tk; Wed, 14 Jun 2006 13:39:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqZL4-0005dX-24 for lemonade@ietf.org; Wed, 14 Jun 2006 13:39:34 -0400 Received: from hideout.bfs.openwave.com ([193.129.95.230] helo=bfs-isa-in.openwave.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqZL2-00012k-Jh for lemonade@ietf.org; Wed, 14 Jun 2006 13:39:34 -0400 Received: from bfs-exch-prd1.myopwv.com ([10.20.249.141]) by bfs-isa-in.openwave.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 18:39:01 +0100 Received: from bfs-fe-prd1.myopwv.com ([10.20.249.143]) by bfs-exch-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 18:39:01 +0100 Received: from [127.0.0.1] ([10.16.81.129]) by bfs-fe-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 18:39:00 +0100 In-Reply-To: <330A23D8336C0346B5C1A5BB1966664703074FF0@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664703074FF0@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Neil Cook Subject: Re: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt Date: Wed, 14 Jun 2006 18:39:53 +0100 To: "Burger, Eric" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 14 Jun 2006 17:39:00.0971 (UTC) FILETIME=[6C06FBB0:01C68FD9] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: lemonade@ietf.org, Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric, I agree. If there's no objections, I'll put some verbage =20 incorporating the below comments in the next draft. Neil. On 13 Jun 2006, at 10:00, Burger, Eric wrote: > I would offer that we just state DRM is up to the IMAP server. It =20 > is way beyond lemonade scope to figure out and replicate full DRM. =20= > Rather, let's do butt simple DRM: if the client has the right to =20 > copy an object, they can do whatever they want with it. The =20 > implementation is in URLAUTH. If you cannot copy an object, for =20 > whatever reason, determined way outside the protocol, the server =20 > will not generate a URLAUTH token. The converse holds, as well. =20 > If the server generates a URLAUTH token, the client can do whatever =20= > it wants with the object. The client can forward the object =20 > (BURL), stream the object (streaming), or eat the object =20 > (URLFETCH). We should explicitly say that (1) this provides =20 > greater than or equal to DRM semantics with respect to existing e-=20 > mail and (2) if you want real DRM, implement a real DRM system. > > Comments? > > -----Original Message----- > From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] > Sent: Thursday, June 08, 2006 4:31 AM > To: lemonade@ietf.org > Subject: RE: [lemonade] draft-cook-lemonade-streaming-00.txt > > I think it's looking good and simple: we generate a URL withing the =20= > IMAP session for the media, then client connects directly to media =20 > server to start streaming. > Comments/questions: > - URLAUTH is RFC 4467 now, not a draft, so the reference should be =20= > updated. > - There is no mentioning of DRM. Should there be? Has it been =20 > considered at all? Or we do not need to because we leave it up to =20 > the client and the media server to sort it out? Can an IMAP server =20 > create an authorized URL for a DRMed content without any problem? =20 > (I'm not an expert on DRM, but I do know that it has been =20 > problematic in other messaging systems). > Thank You, a good draft once again. > > Best regards: Zolt=E1n =D6rd=F6gh > E-mail: zoltan dot ordogh at nokia dot com > Phone: +358 50 386 0566 > > > -----Original Message----- > From: ext Burger, Eric [mailto:eburger@cantata.com] > Sent: 31 May, 2006 03:48 > To: Enhancements to Internet email to support diverse =20 > serviceenivronments > Subject: [lemonade] draft-cook-lemonade-streaming-00.txt > > Until it hits the archives, here is a copy of the outline for the =20 > streaming services draft. > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 14 16:42:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqcC3-00063T-Ju; Wed, 14 Jun 2006 16:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqZP3-0007YL-QI for lemonade@ietf.org; Wed, 14 Jun 2006 13:43:41 -0400 Received: from hideout.bfs.openwave.com ([193.129.95.230] helo=bfs-isa-in.openwave.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqZP2-0001ju-Fl for lemonade@ietf.org; Wed, 14 Jun 2006 13:43:41 -0400 Received: from bfs-exch-prd1.myopwv.com ([10.20.249.141]) by bfs-isa-in.openwave.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 18:43:09 +0100 Received: from bfs-fe-prd1.myopwv.com ([10.20.249.143]) by bfs-exch-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 18:43:09 +0100 Received: from [127.0.0.1] ([10.16.81.129]) by bfs-fe-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 18:43:08 +0100 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <256618E0-70A1-4508-805A-D551E7B5C293@noware.co.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: lemonade@ietf.org From: Neil Cook Date: Wed, 14 Jun 2006 18:44:04 +0100 X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 14 Jun 2006 17:43:09.0297 (UTC) FILETIME=[000A8610:01C68FDA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Wed, 14 Jun 2006 16:42:26 -0400 Subject: [lemonade] Locating media servers for streaming X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org All, Been thinking about the potential problem of lemonade clients locating a media server to use in reference to streaming a multimedia attachment. There are several scenarios where media server location is *required*: 1) Discovery of media servers if client doesn't know *any* already. (How likely is this scenario? You would need a SIP-capable client that is not configured with any media servers, which doesn't seem incredibly likely) 2) Discovery of media servers that are authorised to access an IMAP server, because it is configured to accept URLFETCH requests only from certain media servers. There are also several scenarios where media server location is a nice-to-have for other reasons such as security. I'm thinking of the security implications of pawn-ticket URLs. The IMAP server could return a media server address together with the username that the media server uses to access the IMAP server, and thus the client could generate a URL which was secure in that it could *only* be accessed by the media server in question. Any thoughts? Neil. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 14 21:02:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqgFa-0000Ka-5Y; Wed, 14 Jun 2006 21:02:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqgFZ-0000KV-Me for lemonade@ietf.org; Wed, 14 Jun 2006 21:02:21 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqgFY-0004IN-B9 for lemonade@ietf.org; Wed, 14 Jun 2006 21:02:21 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5F12Gbs011083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Jun 2006 18:02:17 -0700 Received: from [129.46.172.15] (vpn-10-50-16-41.qualcomm.com [10.50.16.41]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5F12EIC015312; Wed, 14 Jun 2006 18:02:15 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <10595.1150236555.436597@peirce.dave.cridland.net> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 14 Jun 2006 17:58:47 -0700 To: Dave Cridland , Enhancements to Internet email to support diverse service enivronments From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org In Section 3.4. Notifications of changes, there should perhaps be a mention of the interaction with reconnect. Specifically, if the client requests notification of changes and then preserves the session, it will get those notifications when it resumes the session? n Appendix A you say: In lieu of a SELECT, the client performs a SEARCH RETURN (COUNT NOTIFY), which provides a count, and requests updates to the results. For whichever area is currently in view in the summary window, it can then perform a SEARCH RETURN (PARTIAL from:to), which will return the required results. There is no SELECT from the client, and no possibility of duplicate message downloads, and therefore this method of providing virtual mailbox But in RFC 3501, SEARCH is only valid in SELECTED state, so the client would have to first SELECT the target mailbox. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Secrecy is as essential to Intelligence as vestments and incense to a Mass, or darkness to a Spiritualist seance, and must at all costs be maintained, quite irrespective of whether or not it serves any purpose. --Malcolm Muggeridge _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 02:21:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqlEk-0000BZ-B4; Thu, 15 Jun 2006 02:21:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqlEj-0000BU-Cn for lemonade@ietf.org; Thu, 15 Jun 2006 02:21:49 -0400 Received: from pathbreaker.com ([64.71.130.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FqlEh-00006D-Um for lemonade@ietf.org; Thu, 15 Jun 2006 02:21:49 -0400 Received: (qmail 12988 invoked by uid 89); 15 Jun 2006 06:20:57 -0000 Received: from localhost (HELO ?192.168.1.101?) (ray%logicaldepth.com@127.0.0.1) by 0 with SMTP; 15 Jun 2006 06:20:57 -0000 Message-ID: <4490FC6F.1050500@pathbreaker.com> Date: Wed, 14 Jun 2006 23:21:35 -0700 From: Ray Cromwell User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Cridland Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> In-Reply-To: <10595.1150236555.436597@peirce.dave.cridland.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > This is primarily aimed at item (2). I don't perceive getting state > changes for messages outside the criteria to be a problem, I simply > don't think mailboxes with sufficient activity for this to be a > problem exist such that they're likely to be looked at on a mobile > device. > The original motivation for VFOLDER was an attempt to solve multiple use case issues, such as #1 and #2, and handle legacy clients, among other things. It is true that separate mechanisms can be designed for this (notifications), but I am concerned about duplicating effort and complicating the job that the mobile client has to do to provide the illusion that they are not separate (to the user) (i.e. messages grouped into a "folder" on the client for reasons of client-side cache and network traffic, and messages grouped into a "folder" on the client for reasons for notifications) I had thought that there was consensus that out-of-band notifications were important for several reasons, such as satisfying OMA requirements and enhancing battery life on mobile clients. The work done on notifications so far has assumed the existence of something like VFOLDER in its architecture, because the assumption is that users do want to control the set of messages and events which generate out-of-band notifications. I disagree that mailboxes with sufficient activity for this to be a problem don't exist, in fact, a mailbox that gets only a few dozen messages and state changes per day would still be a candidate, depending on the cost of out-of-band notifications. The use case for vfolders and notifications goes something like this: 1) user wants "push-like" mobile experience for some category of messages 2) user tells server which criteria it wants for these mobile messages (e.g. create a vfolder that includes only those messages) 3) user tells server which events in this folder it wants to receive notifications for So VFOLDER fulfills dual purposes in use case #2, it allows reduction of client cache and network traffic, but it also provided a named grouping which could have attached notification semantics (#3). We haven't yet decided how #3 works (sieve?) but part of the motiviation for making vfolders behave like ordinary folders was that presumably, whatever notification mechanisms the group decided on would work equally well with regular folders and with vfolders, so there wouldn't be a need for separate mechanisms for each. So my concern is, how do out-of-band notifications work with the context proposal? And secondly, how does inband notifications in the context proposal, and IDLE, and the msgevents draft go together? Are we heading along the way of having 3 separate in-band mechanisms for delivering state changes? -Ray (ray.cromwell at oracle dot com via private SMTP server for spam catching reasons) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 02:37:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqlTQ-0001YP-W9; Thu, 15 Jun 2006 02:37:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqlTQ-0001YK-8p for lemonade@ietf.org; Thu, 15 Jun 2006 02:37:00 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqlTO-0000xc-Q6 for lemonade@ietf.org; Thu, 15 Jun 2006 02:37:00 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 5725F272A7; Thu, 15 Jun 2006 00:36:56 -0600 (MDT) In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Thu, 15 Jun 2006 00:37:00 -0600 To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 14-Jun-06, at 9:14 AM, Arnt Gulbrandsen wrote: > Dave Cridland writes: >> On Tue Jun 13 20:37:29 2006, Arnt Gulbrandsen wrote: >>> Randall Gellens writes, answering Curtis King: >>>> Can you maybe write up a quick proto-draft that proposes this? >>> >>> Seconded. Strongly. >> >> Done - attached is what Curtis and myself thrashed out as >> something that was essentially optimizing what clients can do >> already. > > Here's how I read it, and what I've thought of: > > In the server's RAM, CONTEXTS and VFOLDER seem to be the same. In > both cases, the server keeps track of modsequences and updates UID > sets in RAM. For CONTEXTS, it's one UID set, for VFOLDER, it's two > UID sets and a mailbox name. > > In VFOLDER, all that information is stored persistently on the > server. In CONTEXTS, parts of it is stored on the client, and parts > may not be stored at all, but instead recomputed. > > If the client uses CONDSTORE and stores the result sets > persistently, performance at session start time is essentially the > same for the two. If the client doesn't use CONDSTORE, or if it > issues SEARCHes for all contexts when it SELECTs the backing > mailbox, the server groans under the load. I would hate to create VMAILBOX on such a server ;) An index is an index the cost will be same, except with CONTEXT there will be 1 less for each "view". The performance issue is listing of all the mailboxes and vmailboxes, more so with clients than servers. This is one biggest problems with some existing clients today, vmailboxes will make the situation worst. > > For CONTEXTS, there is a nice fallback to working with stock IMAP > servers. For VFOLDER, there is none. > > For CONTEXTS, two clients don't stay in sync, unless the clients > share state in some way outside the extension. VFOLDER works with > vanilla and extended IMAP clients. What? Clients stay in sync using existing IMAP mechanisms. > > VFOLDER access is governed by ACL, CONTEXTS avoids all that. It avoids it by using the ACL of the backing mailbox. > When a mailbox is deleted or renamed, VFOLDER specifies a certain > behaviour (which may or may not be considered good behaviour), > CONTEXTS makes it depend on whether the rename/delete was issued by > the context-owning client or some other. Incorrect it should be handled the same way as having any other mailbox deleted or renamed currently. > > That's it, right? Have I missed anything? Yes, VMAILBOX while helping with one scaling problem can create an other. The number of items returned by LIST and the number mailboxes a client might want to STATUS. VMAILBOX doesn't help with improving SORT or THREAD update issues. CONTEXT can be extended to-do so which will be a great benefit to all clients. > > If I trust clients to use good IMAP, have decent caching and want > to work with plain IMAP servers, I prefer CONTEXTS. If I don't, or > I want the extension to be valuable to plain IMAP clients, I prefer > VFOLDER. So what's most desirable within the charter of Lemonade? Thinking you can solve poor client implementations by adding a feature to servers is overly optimisic. As I pointed out VMAILBOX can make some "plain IMAP" clients perform worst. We do need to trust developers will produce the best servers and clients they can. A great protocol doesn't prevent bad implementations. I prefer instead to give the client developers more tools to make better clients with. One problem when developing clients is the most you can expect a server to support is RFC3501 until now. LEMONADE sets a new standard which clients can expect from most major servers. I think most active desktop clients will start to use the tools set the by LEMONADE profile. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 03:52:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqmex-0006yY-4s; Thu, 15 Jun 2006 03:52:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqmev-0006yT-H3 for lemonade@ietf.org; Thu, 15 Jun 2006 03:52:57 -0400 Received: from pathbreaker.com ([64.71.130.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fqmeu-0003hn-5f for lemonade@ietf.org; Thu, 15 Jun 2006 03:52:57 -0400 Received: (qmail 20557 invoked by uid 89); 15 Jun 2006 07:52:05 -0000 Received: from localhost (HELO ?192.168.1.101?) (ray%logicaldepth.com@127.0.0.1) by 0 with SMTP; 15 Jun 2006 07:52:05 -0000 Message-ID: <449111CA.5040908@pathbreaker.com> Date: Thu, 15 Jun 2006 00:52:42 -0700 From: Ray Cromwell User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> In-Reply-To: <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: lemonade@ietf.org, Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King wrote: > Yes, VMAILBOX while helping with one scaling problem can create an > other. The number of items returned by LIST and the number mailboxes > a client might want to STATUS. VMAILBOX doesn't help with improving > SORT or THREAD update issues. CONTEXT can be extended to-do so which > will be a great benefit to all clients. > I don't see this being a problem for the client, unless users create dozens and dozens of vmailboxes and tells the client that all of them are interesting enough to sync. Yes, in a pathological case, CONTEXT would be more efficient since presumably the client would issue a single uber-search and parse out the results into individual 'vmailboxes' on the client side, rather than issue dozens of searches. But, what you see as a bug for a pathological case (vmailboxes show up in LIST) I see as a feature (clients can share vmailboxes easily) (What VMAILBOX currently doesn't do without extensions, and what CONTEXT could do with more extensions, I think isn't a valid comparison at this point. CONTEXT doesn't make it easy for two or more devices or users to share a 'virtual' view into a mailbox. Neither spec handles multiple mailbox searches which is clearly a highly desirable user feature, and CONTEXT doesn't handle, atleast in an obvious way, a crucial part of the Lemonade OMA MEM realization for notifications) Now, some of those problems could be fixed for CONTEXT, and if so, I'd have no problem supporting it, I just want to make sure that whatever gets adopted satisifies whats already been agreed upon as far as Lemonade and OMA realization. -Ray _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 07:24:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqpy4-0006vE-9o; Thu, 15 Jun 2006 07:24:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqpy3-0006v9-U8 for lemonade@ietf.org; Thu, 15 Jun 2006 07:24:55 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqpy2-0008Q8-My for lemonade@ietf.org; Thu, 15 Jun 2006 07:24:55 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 5A7194AC2E; Thu, 15 Jun 2006 13:24:53 +0200 (CEST) Message-Id: Date: Thu, 15 Jun 2006 13:26:35 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> In-Reply-To: <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King writes: > On 14-Jun-06, at 9:14 AM, Arnt Gulbrandsen wrote: >> In the server's RAM, CONTEXTS and VFOLDER seem to be the same. In >> both cases, the server keeps track of modsequences and updates UID >> sets in RAM. For CONTEXTS, it's one UID set, for VFOLDER, it's two >> UID sets and a mailbox name. >> >> In VFOLDER, all that information is stored persistently on the >> server. In CONTEXTS, parts of it is stored on the client, and parts >> may not be stored at all, but instead recomputed. >> >> If the client uses CONDSTORE and stores the result sets >> persistently, performance at session start time is essentially the >> same for the two. If the client doesn't use CONDSTORE, or if it >> issues SEARCHes for all contexts when it SELECTs the backing >> mailbox, the server groans under the load. > > I would hate to create VMAILBOX on such a server ;) An index is an > index the cost will be same, except with CONTEXT there will be 1 less > for each "view". I don't see that. The work required to update the index differs substantially. Take the case where a user read INBOX by mostly partitioning it into fifteen groups: Ten specific to a mailing list (SEARCH HEADER "List-ID" "lemonade.ietf.org" etc), one which catches other mailing lists, one which catches messages with the $Junk flag set, one which catches messages to/from the user's personal address, one which catches work mail (based on From/To domain), and one for the rest. Perfectly plausible. Just so I have some numbers, I'll say that the inbox contains 35,000 messages, of which 150 have been delivered since last time I read mail. (If you think 35,000 is a lot, use gmail for a while, it'll change your mind.) There are four costs to consider, at least that I can think of. 1. The amount of persistent storage required on the server. For VFOLDER, that's 15 sets of UID pairs, 15 mailbox names, 15 ACLs, etc. For CONTEXTS, nothing. Agreed? 2. Ditto on the client(s). For VFOLDER, nothing needs be stored. For CONTEXTS, the client must to store the search expression. If the client also stores the matching UID set and its highest modseq, that benefits the server greatly (but makes little difference to the client). 3. The amount of CPU/whatever required to start a session (SELECT or equivalent). For VFOLDER, the server must consider 150 messages every time the client SELECTs a VFOLDER. For CONTEXTS, the client affects that. In the lowest-server-load case, the client enables just one CONTEXT at a time and uses CONDSTORE optimally, so the server needs to consider 150 messages each time the client switches context. In the worst case, the client enables all 15 contexts after issuing SELECT INBOX and does not use CONDSTORE, and the server has to consider each of the 35,000 messages 15 times. I suspect that a good client author such as Dave will enable most/all of the 15 and use CONDSTORE, so the server has to process each of 150 messages 15 times. 4. The amount of CPU/whatever required when a message is injected into a mailbox and a client is looking at that mailbox. For VFOLDER, the server needs to consider whether the message matches either zero or one search expression(s): Zero if the client has INBOX selected, one if the client has one of the VFOLDERs selected. For CONTEXTS, it needs to consider as many search expressions as the client has enabled, 0-15. For three of these, IMO the two are nearly the same, and for one, VFOLDER wins by a significant margin. Depending on what's expensive in your architecture, your conclusion may be different. > The performance issue is listing of all the mailboxes and vmailboxes, > more so with clients than servers. This is one biggest problems with > some existing clients today, vmailboxes will make the situation > worst. True. I disregarded this because I think LIST * is already a form of suicide. One might as well be hanged for a sheep as for a lamb. >> For CONTEXTS, there is a nice fallback to working with stock IMAP >> servers. For VFOLDER, there is none. >> >> For CONTEXTS, two clients don't stay in sync, unless the clients >> share state in some way outside the extension. VFOLDER works with >> vanilla and extended IMAP clients. > > What? Clients stay in sync using existing IMAP mechanisms. How does this work? It's not clear to me from the draft. Take the case where I read mail using my mobile device milonga and my office machine libertango. When I create, modify or delete a context on milonga, how does libertango learn about change context? It could be done. The two could use ACAP, IMAP METADATA, WebDAV or some other mechanism external to the CONTEXTS draft. IMAP doesn't have any such mechanisms now. To create one, you need to specify how to label and format the metadata, and also deal with concurrent update issues. >> VFOLDER access is governed by ACL, CONTEXTS avoids all that. > > It avoids it by using the ACL of the backing mailbox. (That's what I tried to say.) >> That's it, right? Have I missed anything? > > Yes, VMAILBOX while helping with one scaling problem can create an > other. The number of items returned by LIST and the number mailboxes > a client might want to STATUS. True. > VMAILBOX doesn't help with improving SORT or THREAD update issues. > CONTEXT can be extended to-do so which will be a great benefit to > all clients. > >> If I trust clients to use good IMAP, have decent caching and want to >> work with plain IMAP servers, I prefer CONTEXTS. If I don't, or I >> want the extension to be valuable to plain IMAP clients, I prefer >> VFOLDER. So what's most desirable within the charter of Lemonade? > > Thinking you can solve poor client implementations by adding a > feature to servers is overly optimisic. I agree... but we can make poor implementations worse by adding a badly-considered feature. > As I pointed out VMAILBOX can make some "plain IMAP" clients perform > worst. We do need to trust developers will produce the best servers > and clients they can. A great protocol doesn't prevent bad > implementations. So far, IMAP clients tend not to use SEARCH at all, but instead FETCH 1:* RFC822 and do the searching on the client. I've seen a mobile client written by people I personally know and respect do that. It takes some faith to assume that the average mobile client will begin to use SEARCH+CONDSTORE+CONTEXTS optimally. Instead of trusting implementers generally, I'd prefer to design the extension so that if a server implementation sucks, the pain is mostly on the server admin's side, and that if a client implementation sucks, the pain is mostly on the user's side. > I prefer instead to give the client developers more tools to make > better clients with. One problem when developing clients is the most > you can expect a server to support is RFC3501 until now. LEMONADE > sets a new standard which clients can expect from most major servers. > I think most active desktop clients will start to use the tools set > the by LEMONADE profile. I'll accept that if you can get a Microsoft person to step forward and say "Outlook and Outlook Express will be updated to use LEMONADE". Arnt (PS. I keep saying VFOLDER. Not because I think the name is good - I don't. Only because it's the name in the draft at hand. I would be happy if Stephane would update the draft, even if it's just to rename.) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 10:19:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqshO-0004vb-Rl; Thu, 15 Jun 2006 10:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqshM-0004vW-Ub for lemonade@ietf.org; Thu, 15 Jun 2006 10:19:52 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqshL-0002TF-DF for lemonade@ietf.org; Thu, 15 Jun 2006 10:19:52 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FqshI-0001Yv-U0; Thu, 15 Jun 2006 14:19:49 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id BD419498003; Thu, 15 Jun 2006 15:19:50 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08462-07; Thu, 15 Jun 2006 15:19:45 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 66F86498002; Thu, 15 Jun 2006 15:19:45 +0100 (BST) Date: Thu, 15 Jun 2006 15:19:42 +0100 References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> In-Reply-To: <449111CA.5040908@pathbreaker.com> MIME-Version: 1.0 Message-Id: <32502.1150381183.163313@peirce.dave.cridland.net> From: Dave Cridland To: Ray Cromwell Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Enhancements to Internet email to support diverse service enivronments , Arnt Gulbrandsen Subject: [lemonade] Contexts X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Jun 15 08:52:42 2006, Ray Cromwell wrote: > (What VMAILBOX currently doesn't do without extensions, and what > CONTEXT could do with more extensions, I think isn't a valid > comparison at this point. Well, it depends on how easily rectifiable they are as ommisions. FWIW, CONTEXTS already has the placeholder for handling SORT - to paraphrase Jefferson rather ominously, it's just a matter of typing, so if you were referring to that, Curtis slipped up, because CONTEXTS has been designed specifically with SORT in mind. Whether that's split off into a later document or not isn't important, I would insist of keeping the syntax support (which is in ADDTO). > CONTEXT doesn't make it easy for two or more devices or users to > share a 'virtual' view into a mailbox. No, but other existing mechanisms can be used to share preferences, such as ACAP (which Polymer uses for precisely this purpose) or ANNOTATEMORE/METADATA. > Neither spec handles multiple mailbox searches which is clearly a > highly desirable user feature, Multi-mailbox searching can actually be done now using multiple connections. Multi-mailbox SORT cannot. Multi-mailbox searching could be made better with a very small extension dealing with unsolicited STATUS responses, I think, and the use of the client-side-reconnect, which I'm working on today. > and CONTEXT doesn't handle, atleast in an obvious way, a crucial > part of the Lemonade OMA MEM realization for notifications) > > No, but I'm not convinced it needs to. Your approach is to create a mailbox from some live search results, then monitor it for notifications, which means that you have a situation where VMAILBOX is being used for (at least) two different and orthogonal problems. Nothing prevents you from monitoring the live search results directly, whether or not they're actually used as a view or not. (If they are, of course, by all means use the same cached set of results for both purposes). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 10:30:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqsrq-0001yh-7k; Thu, 15 Jun 2006 10:30:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqsro-0001yH-Jm for lemonade@ietf.org; Thu, 15 Jun 2006 10:30:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqsro-00033j-IL for lemonade@ietf.org; Thu, 15 Jun 2006 10:30:40 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqsiK-0000Cs-LW for lemonade@ietf.org; Thu, 15 Jun 2006 10:20:55 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FqsiJ-0006LV-Tr for lemonade@ietf.org; Thu, 15 Jun 2006 14:20:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id F36FB498003 for ; Thu, 15 Jun 2006 15:20:53 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08462-09 for ; Thu, 15 Jun 2006 15:20:49 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 31DA4498002 for ; Thu, 15 Jun 2006 15:20:49 +0100 (BST) Date: Thu, 15 Jun 2006 15:20:46 +0100 References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> In-Reply-To: MIME-Version: 1.0 Message-Id: <32502.1150381246.957176@peirce.dave.cridland.net> From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: -2.6 (--) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Subject: [lemonade] Contexts Implementation Issues. X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Jun 15 12:26:35 2006, Arnt Gulbrandsen wrote: > Curtis King writes: >> On 14-Jun-06, at 9:14 AM, Arnt Gulbrandsen wrote: >>> In the server's RAM, CONTEXTS and VFOLDER seem to be the same. In >>> both cases, the server keeps track of modsequences and updates >>> UID sets in RAM. For CONTEXTS, it's one UID set, for VFOLDER, >>> it's two UID sets and a mailbox name. >>> >>> In VFOLDER, all that information is stored persistently on the >>> server. In CONTEXTS, parts of it is stored on the client, and >>> parts may not be stored at all, but instead recomputed. >>> >>> If the client uses CONDSTORE and stores the result sets >>> persistently, performance at session start time is essentially >>> the same for the two. If the client doesn't use CONDSTORE, or if >>> it issues SEARCHes for all contexts when it SELECTs the backing >>> mailbox, the server groans under the load. >> >> I would hate to create VMAILBOX on such a server ;) An index is an >> index the cost will be same, except with CONTEXT there will be 1 >> less for each "view". > > I don't see that. The work required to update the index differs > substantially. > > Yes, since there's no UID allocation involved - maintaining a CONTEXTS index is marginally cheaper for a server. > Take the case where a user read INBOX by mostly partitioning it > into fifteen groups: Ten specific to a mailing list (SEARCH HEADER > "List-ID" "lemonade.ietf.org" etc), one which catches other mailing > lists, one which catches messages with the $Junk flag set, one > which catches messages to/from the user's personal address, one > which catches work mail (based on From/To domain), and one for the > rest. Perfectly plausible. Just so I have some numbers, I'll say > that the inbox contains 35,000 messages, of which 150 have been > delivered since last time I read mail. (If you think 35,000 is a > lot, use gmail for a while, it'll change your mind.) > > I think 35,000 is "moderate", and I don't use gmail. :-) > There are four costs to consider, at least that I can think of. > > 1. The amount of persistent storage required on the server. For > VFOLDER, that's 15 sets of UID pairs, 15 mailbox names, 15 ACLs, > etc. For CONTEXTS, nothing. Agreed? > > No. CONTEXTS does not mandate any persistent storage, but equally does not mandate against it. Typically, I'd expect the server to have built indices, so for sake of argument you're looking at - perhaps - 15 sets of UIDs. The wire-level efficiency is the same whatever is stored on the server. This contrasts with VFOLDER, since unless you effectively make it into a real mailbox with shared content, and persist UIDs, the wire efficiency of the protocol will suffer greatly. > 2. Ditto on the client(s). For VFOLDER, nothing needs be stored. > For CONTEXTS, the client must to store the search expression. If > the client also stores the matching UID set and its highest modseq, > that benefits the server greatly (but makes little difference to > the client). > > For VFOLDER on a client, a substantial amount of data must be stored for effective use, but nothing needs to be. For CONTEXTS on the client, the search criteria need to be available. The client can persist result sets, of course, and this not only makes a difference to the server, but to the client, too, because it affects wire efficiency. > 3. The amount of CPU/whatever required to start a session (SELECT > or equivalent). For VFOLDER, the server must consider 150 messages > every time the client SELECTs a VFOLDER. For CONTEXTS, the client > affects that. In the lowest-server-load case, the client enables > just one CONTEXT at a time and uses CONDSTORE optimally, so the > server needs to consider 150 messages each time the client switches > context. In the worst case, the client enables all 15 contexts > after issuing SELECT INBOX and does not use CONDSTORE, and the > server has to consider each of the 35,000 messages 15 times. I > suspect that a good client author such as Dave will enable most/all > of the 15 and use CONDSTORE, so the server has to process each of > 150 messages 15 times. > > To begin with, you're still considering all 35,000 messages - it's simply that you're using a MODSEQ index to first-cut the search range. I would probably not resynch all contexts, there's little point - Polymer does use the same view definitions for colourizing the display, but it can handle most criteria used for that locally, so there's little advantage. It'd most likely resynch - or refetch - the context results when that view was selected. But... There's nothing at all preventing the server from persistently caching the results from contexts, which turns the speed of context reaquisition to much the same as VMAILBOX resynch, but with less server-side state involved. The fun thing about CONTEXTS is that the server does not have to, and it makes no difference - at all - to the client. > 4. The amount of CPU/whatever required when a message is injected > into a mailbox and a client is looking at that mailbox. For > VFOLDER, the server needs to consider whether the message matches > either zero or one search expression(s): Zero if the client has > INBOX selected, one if the client has one of the VFOLDERs selected. > For CONTEXTS, it needs to consider as many search expressions as > the client has enabled, 0-15. > > Ah, wait... A client can equally well SELECT all the real virtual mailboxes in the system, and doing this will mean multiple connections, etc. Acquisition of every context is less work than this. What you're basically saying is that it's practical for a client to acquire every context defined for the currently selected mailbox at low cost. This to my mind is an advantage. >> The performance issue is listing of all the mailboxes and >> vmailboxes, more so with clients than servers. This is one >> biggest problems with some existing clients today, vmailboxes >> will make the situation worst. > > True. I disregarded this because I think LIST * is already a form > of suicide. One might as well be hanged for a sheep as for a lamb. > > I've already had complaints from users noting that "LISTing is slow", due to large numbers of mailbox on the same heirarchy level. > How does this work? It's not clear to me from the draft. Take the > case where I read mail using my mobile device milonga and my office > machine libertango. When I create, modify or delete a context on > milonga, how does libertango learn about change context? > > It's not covered by the draft at all. > It could be done. The two could use ACAP, IMAP METADATA, WebDAV or > some other mechanism external to the CONTEXTS draft. IMAP doesn't > have any such mechanisms now. To create one, you need to specify > how to label and format the metadata, and also deal with concurrent > update issues. > > Polymer uses ACAP right now. *shrugs* METADATA would work too. Either way, it's orthogonal to the protocol. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 10:30:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqsrq-0001ym-Bo; Thu, 15 Jun 2006 10:30:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqsro-0001yP-Lf for lemonade@ietf.org; Thu, 15 Jun 2006 10:30:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqsro-00033j-KK for lemonade@ietf.org; Thu, 15 Jun 2006 10:30:40 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fqsi6-0000Cc-UV for lemonade@ietf.org; Thu, 15 Jun 2006 10:20:41 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1Fqsi2-00069S-Vb; Thu, 15 Jun 2006 14:20:35 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 4967B498003; Thu, 15 Jun 2006 15:20:36 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08560-03; Thu, 15 Jun 2006 15:20:29 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 0060B498002; Thu, 15 Jun 2006 15:20:29 +0100 (BST) Date: Thu, 15 Jun 2006 15:20:26 +0100 References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <32502.1150381226.763216@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: -2.6 (--) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Enhancements to Internet email to support diverse service enivronments Subject: [lemonade] Contexts Draft, Resync. X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Jun 15 01:58:47 2006, Randall Gellens wrote: > In Section 3.4. Notifications of changes, there should perhaps be > a mention of the interaction with reconnect. Specifically, if the > client requests notification of changes and then preserves the > session, it will get those notifications when it resumes the > session? > > It would be nice if it did, wouldn't it? In practise, I suspect the server implementors would scream about a vast increase in server-side state. Server implementors have already expressed concern about maintaining a note of when a message was expunged, expecting them to recall when a message was removed from a context would be asking a bit much. However, I believe it is possible to resynchronize quite efficiently where CONDSTORE is available. I need to double check this, and it may only work in practise, rather than in theory. I'll most likely update the draft with an additional appendix describing how it can be done. > n Appendix A you say: > In lieu of a SELECT, the client performs a SEARCH RETURN (COUNT > NOTIFY), which provides a count, and requests updates to the > results. > For whichever area is currently in view in the summary window, > it can > then perform a SEARCH RETURN (PARTIAL from:to), which will > return the > required results. > > There is no SELECT from the client, and no possibility of > duplicate > message downloads, and therefore this method of providing virtual > mailbox > > But in RFC 3501, SEARCH is only valid in SELECTED state, so the > client would have to first SELECT the target mailbox. Yes, quite, it's very badly worded. You have to select what would be the backing mailbox, before you replace the select of the virtual mailbox with the SEARCH RETURN (ALL). Obviously you can't omit the select of the backing mailbox, nor can you really select the virtual mailbox, because, in this design, the virtual mailbox isn't a "real virtual mailbox", but a "virtual virtual mailbox". (To move from the sublime to the ridiculous, server implementors under this design have the choice of storing physical data about the virtual virtual mailbox or not, which probably further subdivides implementation options into virtual virtual virtual mailboxes and real virtual virtual mailboxes). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 11:01:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqtLy-00085q-OJ; Thu, 15 Jun 2006 11:01:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqtLx-00085l-Aw for lemonade@ietf.org; Thu, 15 Jun 2006 11:01:49 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqtLv-00085F-VJ for lemonade@ietf.org; Thu, 15 Jun 2006 11:01:49 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5FF1gpt025763; Thu, 15 Jun 2006 08:01:42 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5FF1apK023981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 08:01:42 -0700 Date: Thu, 15 Jun 2006 08:01:36 -0700 (PDT) From: Mark Crispin To: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt In-Reply-To: <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> Message-ID: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: lemonade@ietf.org, Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 15 Jun 2006, Curtis King wrote: > Thinking you can solve poor client implementations by adding a feature to > servers is overly optimisic. Indeed. That misguided thinking has caused far more problems than it has solved. It also leads to violations of RFC 3501, with the justification that the violation makes some broken client work better (at the cost of breaking some RFC 3501 compliant client). > One problem when developing clients is the most you can expect > a server to support is RFC3501 until now. LEMONADE sets a new standard which > clients can expect from most major servers. I think most active desktop > clients will start to use the tools set the by LEMONADE profile. I, on the other hand, hope that this does not happen. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 11:05:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqtPh-0001S3-Jt; Thu, 15 Jun 2006 11:05:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqtPg-0001Ry-2g for lemonade@ietf.org; Thu, 15 Jun 2006 11:05:40 -0400 Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqtPe-00006W-Rz for lemonade@ietf.org; Thu, 15 Jun 2006 11:05:40 -0400 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 6A146D6CC3B; Thu, 15 Jun 2006 11:05:03 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Thu, 15 Jun 2006 11:05:06 -0400 X-Sasl-enc: mSvP9wDuz9cjNKAOAR/74Fll2GokfG0OPhmyo/a7gBQE 1150383906 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 140926FA6; Thu, 15 Jun 2006 11:05:04 -0400 (EDT) Date: Thu, 15 Jun 2006 11:05:00 -0400 From: Cyrus Daboo To: Dave Cridland Subject: Re: [lemonade] Contexts Message-ID: <84C04EE87A2819D176ADB3AC@Cyrus-Daboo.local> In-Reply-To: <32502.1150381183.163313@peirce.dave.cridland.net> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <32502.1150381183.163313@peirce.dave.cridland.net> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dave, --On June 15, 2006 3:19:42 PM +0100 Dave Cridland wrote: >> (What VMAILBOX currently doesn't do without extensions, and what >> CONTEXT could do with more extensions, I think isn't a valid >> comparison at this point. > > Well, it depends on how easily rectifiable they are as ommisions. FWIW, > CONTEXTS already has the placeholder for handling SORT - to paraphrase > Jefferson rather ominously, it's just a matter of typing, so if you were > referring to that, Curtis slipped up, because CONTEXTS has been designed > specifically with SORT in mind. Whether that's split off into a later > document or not isn't important, I would insist of keeping the syntax > support (which is in ADDTO). As was pointed out many times during the VIEW/WINDOW debate, THREAD is just as important (if not more so) than SORT, so CONTEXT really ought to provide a way to update the THREAD tree. Unfortunately that is not trivial as there can be non trivial changes to the tree when messages are inserted or deleted. The simple case of an insert or delete in a 'branch' would be easy to handle, but merges/fragmentation of branches is harder - in the later case the simplest thing to do is probably just resend the entire THREAD response rather than attempt a diff. In any case I think you need to address THREAD is some fashion, as I believe those clients that are likely to use CONTEXT ("real" IMAP clients that like to take advantage of server-side processing) will also likely be using THREAD. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 11:19:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqtck-000195-1r; Thu, 15 Jun 2006 11:19:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqtci-00012p-6Q for lemonade@ietf.org; Thu, 15 Jun 2006 11:19:08 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqtcg-0001B6-Nu for lemonade@ietf.org; Thu, 15 Jun 2006 11:19:08 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1Fqtcf-0006B2-Ue; Thu, 15 Jun 2006 15:19:06 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id D25A0498004; Thu, 15 Jun 2006 16:19:07 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08842-07; Thu, 15 Jun 2006 16:18:59 +0100 (BST) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:3455:f4:b33:70e8]) by turner.dave.cridland.net (Postfix) with ESMTP id 61BF4498002; Thu, 15 Jun 2006 16:18:59 +0100 (BST) Date: Thu, 15 Jun 2006 16:18:37 +0100 Subject: Re: [lemonade] Contexts References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <32502.1150381183.163313@peirce.dave.cridland.net> <84C04EE87A2819D176ADB3AC@Cyrus-Daboo.local> In-Reply-To: <84C04EE87A2819D176ADB3AC@Cyrus-Daboo.local> MIME-Version: 1.0 Message-Id: <3400.1150384718.859000@JOHN> From: Dave Cridland To: Cyrus Daboo Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Jun 15 16:05:00 2006, Cyrus Daboo wrote: > Hi Dave, > > --On June 15, 2006 3:19:42 PM +0100 Dave Cridland > wrote: > >>> (What VMAILBOX currently doesn't do without extensions, and what >>> CONTEXT could do with more extensions, I think isn't a valid >>> comparison at this point. >> >> Well, it depends on how easily rectifiable they are as ommisions. >> FWIW, >> CONTEXTS already has the placeholder for handling SORT - to >> paraphrase >> Jefferson rather ominously, it's just a matter of typing, so if >> you were >> referring to that, Curtis slipped up, because CONTEXTS has been >> designed >> specifically with SORT in mind. Whether that's split off into a >> later >> document or not isn't important, I would insist of keeping the >> syntax >> support (which is in ADDTO). > > As was pointed out many times during the VIEW/WINDOW debate, THREAD > is just as important (if not more so) than SORT, so CONTEXT really > ought to provide a way to update the THREAD tree. Unfortunately > that is not trivial as there can be non trivial changes to the tree > when messages are inserted or deleted. The simple case of an insert > or delete in a 'branch' would be easy to handle, but > merges/fragmentation of branches is harder - in the later case the > simplest thing to do is probably just resend the entire THREAD > response rather than attempt a diff. > > In any case I think you need to address THREAD is some fashion, as > I believe those clients that are likely to use CONTEXT ("real" IMAP > clients that like to take advantage of server-side processing) will > also likely be using THREAD. I've "handled" THREAD by quite deliberately leaving expansion space in the CAPABILITY string, but that's as far as I'm really prepared to go in this iteration. SORT is there at all really because it's quite low-hanging fruit. Whether it's low enough, I don't know, but syntactically, it was terribly easy to put in. For THREAD, you not only have to deal with updates, you have to deal with partial trees, as well. I'd personally want to sit back and see what use-cases other than the obvious are made from CONTEXTS, first off. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 11:55:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquBt-00018W-Ov; Thu, 15 Jun 2006 11:55:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquBp-00015r-EG for lemonade@ietf.org; Thu, 15 Jun 2006 11:55:25 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqu5P-0003jc-7U for lemonade@ietf.org; Thu, 15 Jun 2006 11:48:48 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 8B2044AC6C; Thu, 15 Jun 2006 17:48:44 +0200 (CEST) Message-Id: <9UgYj8LhgiYlEcZRGD6tcA.md5@libertango.oryx.com> Date: Thu, 15 Jun 2006 17:50:23 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Contexts Implementation Issues. References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <32502.1150381246.957176@peirce.dave.cridland.net> In-Reply-To: <32502.1150381246.957176@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > On Thu Jun 15 12:26:35 2006, Arnt Gulbrandsen wrote: >> There are four costs to consider, at least that I can think of. >> >> 1. The amount of persistent storage required on the server. For >> VFOLDER, that's 15 sets of UID pairs, 15 mailbox names, 15 ACLs, >> etc. For CONTEXTS, nothing. Agreed? > > No. > > CONTEXTS does not mandate any persistent storage, but equally does not > mandate against it. Typically, I'd expect the server to have built > indices, so for sake of argument you're looking at - perhaps - 15 > sets of UIDs. The wire-level efficiency is the same whatever is > stored on the server. Yes. Sorry, I wasn't thorough enough. I only considered keying on search-correlator, and didn't realise until later that one can key on the verbatim search expression. But if you store on the server, you store the same information, do the same work, and all you get from CONTEXTS is incompatibility with Outlook. > This contrasts with VFOLDER, since unless you effectively make it into > a real mailbox with shared content, and persist UIDs, the wire > efficiency of the protocol will suffer greatly. Explain? I don't see that. The only inefficiency I know is that if you read both the vfolder and the backing mailbox, you lose, and in my experience, people hate doing that in the first place. (That's why I suggested INVFOLDER as a new search-key a few weeks ago.) >> 2. Ditto on the client(s). For VFOLDER, nothing needs be stored. For >> CONTEXTS, the client must to store the search expression. If the >> client also stores the matching UID set and its highest modseq, that >> benefits the server greatly (but makes little difference to the >> client). > > For VFOLDER on a client, a substantial amount of data must be stored > for effective use, but nothing needs to be. How? The client does some work to CREATE the thing, and after that, no client does anything particular. > To begin with, you're still considering all 35,000 messages - it's > simply that you're using a MODSEQ index to first-cut the search > range. The modseq search doesn't consider all 35,000. Depending on data structure, it's a loop downwards, a tree lookup, etc. In my case, the code would look at maybe 160 nodes. > I would probably not resynch all contexts, there's little point - > Polymer does use the same view definitions for colourizing the > display, but it can handle most criteria used for that locally, so > there's little advantage. > > It'd most likely resynch - or refetch - the context results when that > view was selected. > > But... There's nothing at all preventing the server from persistently > caching the results from contexts, which turns the speed of context > reaquisition to much the same as VMAILBOX resynch, but with less > server-side state involved. I looked at the code so see how I'd implement that. I would use the same classes that I already have, with pretty much the same member variables. Two variables would be replaced by two other variables. >> 4. The amount of CPU/whatever required when a message is injected >> into a mailbox and a client is looking at that mailbox. For VFOLDER, >> the server needs to consider whether the message matches either zero >> or one search expression(s): Zero if the client has INBOX selected, >> one if the client has one of the VFOLDERs selected. For CONTEXTS, it >> needs to consider as many search expressions as the client has >> enabled, 0-15. > > Ah, wait... A client can equally well SELECT all the real virtual > mailboxes in the system, and doing this will mean multiple > connections, etc. Yes. But none actually do ;) I've seen much broken use of IMAP, but I've never seen anyhing as broken as for all x send "SELECT x" Eventually, clients select most/all values of x, with some intervening FETCH commands etc. That's different, because there's no huge load peak. > Acquisition of every context is less work than this. What you're > basically saying is that it's practical for a client to acquire every > context defined for the currently selected mailbox at low cost. This > to my mind is an advantage. That's exactly what I meant to say. Now, whether it's an advantage... I can see the attraction, but I notice that despite repeated proposals, noone has done a MULTISELECT yet. So maybe the advantage isn't as large as one would think. (Is it more desirable to select multiple search results than multiple mailboxes? I can't see any reason for that, but I've never tried to find any.) >> How does this work? It's not clear to me from the draft. Take the >> case where I read mail using my mobile device milonga and my office >> machine libertango. When I create, modify or delete a context on >> milonga, how does libertango learn about change context? > > It's not covered by the draft at all. > >> It could be done. The two could use ACAP, IMAP METADATA, WebDAV or >> some other mechanism external to the CONTEXTS draft. IMAP doesn't >> have any such mechanisms now. To create one, you need to specify how >> to label and format the metadata, and also deal with concurrent >> update issues. > > Polymer uses ACAP right now. *shrugs* METADATA would work too. Either > way, it's orthogonal to the protocol. I sort of disagree strongly. Sort of. IMO it's extremely important to share this data among clients. On the other hand, a user with one mobile device and one stationary device (most commonly Outlook/OE) is important to me. Since CONTEXTS can't share in this case, there may not be much point in sharing. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 12:02:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquIn-0006De-KW; Thu, 15 Jun 2006 12:02:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquIl-0006D9-LS for lemonade@ietf.org; Thu, 15 Jun 2006 12:02:35 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FquIk-0005pE-D2 for lemonade@ietf.org; Thu, 15 Jun 2006 12:02:35 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id BBC09272A7; Thu, 15 Jun 2006 10:02:33 -0600 (MDT) In-Reply-To: <9UgYj8LhgiYlEcZRGD6tcA.md5@libertango.oryx.com> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <32502.1150381246.957176@peirce.dave.cridland.net> <9UgYj8LhgiYlEcZRGD6tcA.md5@libertango.oryx.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] Contexts Implementation Issues. Date: Thu, 15 Jun 2006 10:02:38 -0600 To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 15-Jun-06, at 9:50 AM, Arnt Gulbrandsen wrote: > Yes. But none actually do ;) I've seen much broken use of IMAP, but > I've never seen anyhing as broken as > > for all x > send "SELECT x" I sure have seen clients do: for all x send "STATUS x (..)" ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 12:12:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquSc-00042H-Hd; Thu, 15 Jun 2006 12:12:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquSa-000428-UG for lemonade@ietf.org; Thu, 15 Jun 2006 12:12:44 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FquSZ-0006fo-Jl for lemonade@ietf.org; Thu, 15 Jun 2006 12:12:44 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5FGCd9f005900; Thu, 15 Jun 2006 09:12:39 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5FGCcft032263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 09:12:38 -0700 Date: Thu, 15 Jun 2006 09:12:37 -0700 (PDT) From: Mark Crispin To: Curtis King Subject: Re: [lemonade] Contexts Implementation Issues. In-Reply-To: Message-ID: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <32502.1150381246.957176@peirce.dave.cridland.net> <9UgYj8LhgiYlEcZRGD6tcA.md5@libertango.oryx.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: lemonade@ietf.org, Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 15 Jun 2006, Curtis King wrote: > I sure have seen clients do: > for all x > send "STATUS x (..)" So have I. The reason that STATUS does not take a wildcard is to make it obvious to anyone who looks at the protocol transcript that the client is badly broken, and that the server is not to blame for the session being so slow. But that doesn't stop certain individuals from writing such programs. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 13:15:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvRV-0004MS-6g; Thu, 15 Jun 2006 13:15:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvRU-0004MN-7G for lemonade@ietf.org; Thu, 15 Jun 2006 13:15:40 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqvRS-0005aB-U8 for lemonade@ietf.org; Thu, 15 Jun 2006 13:15:40 -0400 Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0D240142336; Thu, 15 Jun 2006 10:15:38 -0700 (PDT) In-Reply-To: References: <4486CC85.80400@isode.com> <7ED1AE38-5BA6-4100-B072-07B1397C8E95@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2753C43F-FA4A-487B-8834-3650FC05A51E@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [lemonade] Notifications for multiple devices per user Date: Thu, 15 Jun 2006 10:15:32 -0700 To: Randall Gellens X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Lemonade WG , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Jun 9, 2006, at 5:59 PM, Randall Gellens wrote: > At 4:40 PM -0700 6/9/06, Lisa Dusseault wrote: > >> There's an alternative architecture for the same use case, and >> that's to let the notification server (SIP or XMPP, in particular) >> do fanout. Then the IMAP server simply sends the notification to >> the user's notification address (plus some application field if >> specified) and the user decides which devices subscribe to those >> notifications. >> >> I could be wrong but I think some of those kinds of servers can >> gateway to SMS so that would even work in. >> >> lisa >> >> On Jun 7, 2006, at 5:54 AM, Alexey Melnikov wrote: >> >>> In my private discussion with Zoltan he raised a question about >>> IMAP server ability to store notification information (i.e. where >>> the notification is to be sent) for multiple devices per user. Is >>> this the requirement the WG wants to consider when thinking about >>> notifications? > > Depending on the device capability, it is conceivable that the user > might want different criteria. So the more capable the device, the > more state changes and new messages it is aware of, but the more > limited devices would only know about the most urgent messages. > > I had been thinking that this would be handled by Sieve, with > various rules sending notifications to different devices. This > would imply that the rules would need to be updated as devices change. Right. That's difficult, particularly since various devices might not have the same understanding of Sieve rules and extensions. It's easier for the device to simply to subscribe, or no, to some address to which notifications are sent (not nonstop but whenever there's a receiver) according to a previously configured script or rule. Lisa _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 14:10:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwIh-0006V9-9M; Thu, 15 Jun 2006 14:10:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwIg-0006V4-SD for lemonade@ietf.org; Thu, 15 Jun 2006 14:10:38 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqwIg-0002dY-Cs for lemonade@ietf.org; Thu, 15 Jun 2006 14:10:38 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 0578E272A7; Thu, 15 Jun 2006 12:10:38 -0600 (MDT) In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Thu, 15 Jun 2006 12:10:42 -0600 To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 15-Jun-06, at 5:26 AM, Arnt Gulbrandsen wrote: > Curtis King writes: >> On 14-Jun-06, at 9:14 AM, Arnt Gulbrandsen wrote: >> >> I would hate to create VMAILBOX on such a server ;) An index is >> an index the cost will be same, except with CONTEXT there will be >> 1 less for each "view". > > I don't see that. The work required to update the index differs > substantially. Why not just create an index for each search for either VMAILBOX or CONTEXT and test each message when it's injected into the backing mailbox. VMAILBOX requires the server to have an index storing the fake VMAILBOX uids, CONTEXT does not. So, for servers which already have really good search performance VMAILBOX has higher requirements than CONTEXT. > >> The performance issue is listing of all the mailboxes and >> vmailboxes, more so with clients than servers. This is one >> biggest problems with some existing clients today, vmailboxes >> will make the situation worst. > > True. I disregarded this because I think LIST * is already a form > of suicide. One might as well be hanged for a sheep as for a lamb. I haven't seen clients do LIST * for long time. Clients trying to discover the whole mailbox hierarchy at every startup using LIST "" %, LIST "" foo/% which have the performance problems. In some cases issuing LIST * would be better than their existing behavior ;) > >>> For CONTEXTS, there is a nice fallback to working with stock >>> IMAP servers. For VFOLDER, there is none. >>> >>> For CONTEXTS, two clients don't stay in sync, unless the clients >>> share state in some way outside the extension. VFOLDER works >>> with vanilla and extended IMAP clients. >> >> What? Clients stay in sync using existing IMAP mechanisms. > > How does this work? It's not clear to me from the draft. Take the > case where I read mail using my mobile device milonga and my office > machine libertango. When I create, modify or delete a context on > milonga, how does libertango learn about change context? Why do I need to share the context? Isn't the client interested in the changes to message? Most likely I won't even want the same VMAILBOX on all my clients. I would argue it's better not to force clients to have the same view, but instead allow them to create the views which best suit their usage model. > >> VMAILBOX doesn't help with improving SORT or THREAD update >> issues. CONTEXT can be extended to-do so which will be a great >> benefit to all clients. >> >>> If I trust clients to use good IMAP, have decent caching and >>> want to work with plain IMAP servers, I prefer CONTEXTS. If I >>> don't, or I want the extension to be valuable to plain IMAP >>> clients, I prefer VFOLDER. So what's most desirable within the >>> charter of Lemonade? >> >> Thinking you can solve poor client implementations by adding a >> feature to servers is overly optimisic. > > I agree... but we can make poor implementations worse by adding a > badly-considered feature. Which I think VMAILBOX is. I have tried to implement it and there are too many holes in it. > >> As I pointed out VMAILBOX can make some "plain IMAP" clients >> perform worst. We do need to trust developers will produce the >> best servers and clients they can. A great protocol doesn't >> prevent bad implementations. > > So far, IMAP clients tend not to use SEARCH at all, but instead > FETCH 1:* RFC822 and do the searching on the client. I've seen a > mobile client written by people I personally know and respect do > that. It takes some faith to assume that the average mobile client > will begin to use SEARCH+CONDSTORE+CONTEXTS optimally. > > Instead of trusting implementers generally, I'd prefer to design > the extension so that if a server implementation sucks, the pain is > mostly on the server admin's side, and that if a client > implementation sucks, the pain is mostly on the user's side. Honestly I don't think thats achievable and history has shown opposite happens when you try to-do this. > >> I prefer instead to give the client developers more tools to make >> better clients with. One problem when developing clients is the >> most you can expect a server to support is RFC3501 until now. >> LEMONADE sets a new standard which clients can expect from most >> major servers. I think most active desktop clients will start to >> use the tools set the by LEMONADE profile. > > I'll accept that if you can get a Microsoft person to step forward > and say "Outlook and Outlook Express will be updated to use LEMONADE". Outlook is one of those clients which has problems when there are a large number of mailboxes. It's a hugh mistake to think VMAILBOX will make existing clients more usable. Just consider that existing clients will still select INBOX no matter what virtual mailboxes are defined. > > Arnt > > (PS. I keep saying VFOLDER. Not because I think the name is good - > I don't. Only because it's the name in the draft at hand. I would > be happy if Stephane would update the draft, even if it's just to > rename.) I don't think that will happen unless we refer to it as VMAILBOX. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 14:48:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqwtj-0001FQ-Cn; Thu, 15 Jun 2006 14:48:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqwth-0001FJ-JJ for lemonade@ietf.org; Thu, 15 Jun 2006 14:48:53 -0400 Received: from pathbreaker.com ([64.71.130.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fqwtg-0005q3-7G for lemonade@ietf.org; Thu, 15 Jun 2006 14:48:53 -0400 Received: (qmail 14709 invoked by uid 89); 15 Jun 2006 18:48:01 -0000 Received: from localhost (HELO ?192.168.1.101?) (ray%logicaldepth.com@127.0.0.1) by 0 with SMTP; 15 Jun 2006 18:48:01 -0000 Message-ID: <4491AB88.4060100@pathbreaker.com> Date: Thu, 15 Jun 2006 11:48:40 -0700 From: Ray Cromwell User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> In-Reply-To: <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: lemonade@ietf.org, Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King wrote: > > > Why not just create an index for each search for either VMAILBOX or > CONTEXT and test each message when it's injected into the backing > mailbox. VMAILBOX requires the server to have an index storing the > fake VMAILBOX uids, CONTEXT does not. So, for servers which already > have really good search performance VMAILBOX has higher requirements > than CONTEXT. I think this entire thread is predicated on the assumption that VMAILBOX mandates that servers must allow search criteria on dynamic attributes or criteria that create the need to assign new UIDs. The original VFOLDER proposal did not have this feature and we have not decided whether or not this feature is necessary for VFOLDERs or if it will be included in the final spec. It was made optional in the latest VFOLDER draft (adopted from Arnt's VIEW proposal) precisely so that a) we can have a discussion about the costs of implementing and b) some people could choose not to implement it. -Ray _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 15:26:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxU3-00039Q-7s; Thu, 15 Jun 2006 15:26:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxU2-00039L-Gj for lemonade@ietf.org; Thu, 15 Jun 2006 15:26:26 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqxU1-00011n-Dw for lemonade@ietf.org; Thu, 15 Jun 2006 15:26:26 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 4B8984AC83; Thu, 15 Jun 2006 21:26:24 +0200 (CEST) Message-Id: Date: Thu, 15 Jun 2006 21:28:08 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> In-Reply-To: <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King writes: > On 15-Jun-06, at 5:26 AM, Arnt Gulbrandsen wrote: >> Curtis King writes: >>> I would hate to create VMAILBOX on such a server ;) An index is an >>> index the cost will be same, except with CONTEXT there will be 1 >>> less for each "view". >> >> I don't see that. The work required to update the index differs >> substantially. > > Why not just create an index for each search for either VMAILBOX or > CONTEXT and test each message when it's injected into the backing > mailbox. VMAILBOX requires the server to have an index storing the > fake VMAILBOX uids, CONTEXT does not. That seems to be a big point for you. I really don't see why. Can you expla= in? To me, CONTEXT and VFOLDER seem essentially equivalent in this respect. VFOLDER needs to store two uints per match or else invent a new UIDVALIDITY and suffer recomputing, CONTEXT needs to store one uint per match or else suffer recomputing. What's the big deal? > So, for servers which already have really good search performance > VMAILBOX has higher requirements than CONTEXT. I doubt it. (My code goes to some effort to search fast, and it's all ineffective for a single message. The optimizations are more effective the bigger the mailbox is.) The performance issue of storing 1-2 uints is, well, not a factor for me. > I haven't seen clients do LIST * for long time. Clients trying to > discover the whole mailbox hierarchy at every startup using LIST "" > %, LIST "" foo/% which have the performance problems. In some cases > issuing LIST * would be better than their existing behavior ;) OK, OK, I should have said "LIST * or the equivalent series of LIST =2E..%... commands". >>>> For CONTEXTS, there is a nice fallback to working with stock IMAP >>>> servers. For VFOLDER, there is none. >>>> >>>> For CONTEXTS, two clients don't stay in sync, unless the clients >>>> share state in some way outside the extension. VFOLDER works with >>>> vanilla and extended IMAP clients. >>> >>> What? Clients stay in sync using existing IMAP mechanisms. >> >> How does this work? It's not clear to me from the draft. Take the >> case where I read mail using my mobile device milonga and my office >> machine libertango. When I create, modify or delete a context on >> milonga, how does libertango learn about change context? > > Why do I need to share the context? Isn't the client interested in > the changes to message? Every use case I've seen so far for vfolder was of a kind that's naturally shared, in the sense that if you have a certain vfolder on your desktop, you want the same on your laptop. Consider my message earlier today, where I mentioned 15 views. That contained five or six substantially different ones, all of which are naturally shared. Even the case where you don't want to read the mail is naturally shared. Suppose you don't want to read work mail when you're at home. If you don't have the "work mail" view on your home computer, the work mail shows up in "other nonspam". > Most likely I won't even want the same VMAILBOX on all my clients. I > would argue it's better not to force clients to have the same view, > but instead allow them to create the views which best suit their > usage model. (I like the term view, perhaps because it's what DB people use for this. Can we use it in this discussion?) Even if users.cking.workmail exists and is available on your office desktop, your computer at home, your laptop and your 770, you don't have to read it everywhere. >> I agree... but we can make poor implementations worse by adding a >> badly-considered feature. > > Which I think VMAILBOX is. I have tried to implement it and there are > too many holes in it. Tell more? I agree for the previous version of the draft. The current version includes lots of text from draft-gulbrandsen-imap-view, which I have implemented and I only know about one hole (regarding listext syntax). Of course, since I wrote that text I do suffer from a certain myopia. >>> I prefer instead to give the client developers more tools to make >>> better clients with. One problem when developing clients is the >>> most you can expect a server to support is RFC3501 until now. >>> LEMONADE sets a new standard which clients can expect from most >>> major servers. I think most active desktop clients will start to >>> use the tools set the by LEMONADE profile. >> >> I'll accept that if you can get a Microsoft person to step forward >> and say "Outlook and Outlook Express will be updated to use >> LEMONADE". > > Outlook is one of those clients which has problems when there are a > large number of mailboxes. It's a hugh mistake to think VMAILBOX will > make existing clients more usable. I'm not arguing that. I'm arguing that, unlike CONTEXT, it will not make them LESS usable by opening an unneeded gap between the mail you see on your mobile and that which you see on your desktop. Dave has convinced me that CONTEXT, well implemented, can have performance characteristics as good as VFOLDER. Not 100%, but close enough that I don't care. However, if it's implemented that well, the whole difference I see is that CONTEXT is incompatible with Outlook et al., and that CONTEXT offers the ability to select multiple views at a time. There are SORT/THREAD aspects. I think those are a little bit too airy at the moment, and I feel jeery about saying that views is how one does that. >> (PS. I keep saying VFOLDER. Not because I think the name is good - I >> don't. Only because it's the name in the draft at hand. I would be >> happy if Stephane would update the draft, even if it's just to >> rename.) > > I don't think that will happen unless we refer to it as VMAILBOX. Stephane's not stubborn or unwilling (or if he is I haven't noticed). He'll adapt to the consensus. It just takes a little while until he finds time to edit and submit the draft. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 15:32:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxaB-0006bZ-TV; Thu, 15 Jun 2006 15:32:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxaB-0006bT-2p for lemonade@ietf.org; Thu, 15 Jun 2006 15:32:47 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqxa9-0001pN-OT for lemonade@ietf.org; Thu, 15 Jun 2006 15:32:47 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5FJWf4P012167; Thu, 15 Jun 2006 12:32:41 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5FJWWw9007926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 12:32:39 -0700 Date: Thu, 15 Jun 2006 12:32:30 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt In-Reply-To: Message-ID: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NAME_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 15 Jun 2006, Arnt Gulbrandsen wrote: >> I haven't seen clients do LIST * for long time. Clients trying to >> discover the whole mailbox hierarchy at every startup using LIST "" >> %, LIST "" foo/% which have the performance problems. In some cases >> issuing LIST * would be better than their existing behavior ;) > OK, OK, I should have said "LIST * or the equivalent series of LIST > ...%... commands". So, are you saying that there are clients that walk the entire tree using % just to avoid doing a *? Unbelievable. The whole point of "LIST * is harmful" is that walking the entire tree is harmful. I can see a client doing "LIST %", followed by "LIST %/%" if the server does not advertise CHILDREN and needs to know that. But any further tree prowling should be deferred until the user actually looks in a name that has inferiors. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 15:46:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxnN-00051R-DP; Thu, 15 Jun 2006 15:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxnL-00051M-IO for lemonade@ietf.org; Thu, 15 Jun 2006 15:46:23 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqxnK-0002v7-41 for lemonade@ietf.org; Thu, 15 Jun 2006 15:46:23 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id A95E7272A7; Thu, 15 Jun 2006 13:46:19 -0600 (MDT) In-Reply-To: <449111CA.5040908@pathbreaker.com> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Thu, 15 Jun 2006 13:46:25 -0600 To: Ray Cromwell X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: lemonade@ietf.org, Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 15-Jun-06, at 1:52 AM, Ray Cromwell wrote: > Curtis King wrote: > >> Yes, VMAILBOX while helping with one scaling problem can create >> an other. The number of items returned by LIST and the number >> mailboxes a client might want to STATUS. VMAILBOX doesn't help >> with improving SORT or THREAD update issues. CONTEXT can be >> extended to-do so which will be a great benefit to all clients. >> > I don't see this being a problem for the client, unless users > create dozens and dozens of vmailboxes and tells the client that > all of them are interesting enough to sync. There will be clients which do this and it's the one on your desktop. > Yes, in a pathological case, CONTEXT would be more efficient since > presumably the client would issue a single uber-search and parse > out the results into individual 'vmailboxes' on the client side, > rather than issue dozens of searches. But, what you see as a bug > for a pathological case (vmailboxes show up in LIST) I see as a > feature (clients can share vmailboxes easily) Once again, what's the big deal with sharing vmailboxes? The point I'm trying to make is we need to drop the idea that we can improve existing clients with VMAILBOX. Let's drop backward compatibility, so we can get the correct solution in a timely manner. > > (What VMAILBOX currently doesn't do without extensions, and what > CONTEXT could do with more extensions, I think isn't a valid > comparison at this point. CONTEXT doesn't make it easy for two or > more devices or users to share a 'virtual' view into a mailbox. > Neither spec handles multiple mailbox searches which is clearly a > highly desirable user feature, and I would suggest we call it out of scope because the time constraints. Let's get the core right. > CONTEXT doesn't handle, atleast in an obvious way, a crucial part > of the Lemonade OMA MEM realization for notifications) True, but VMAILBOX has a high price to get filtered notifications. Here are a few of the problems I have run into so far and would like authors to explain what should happen. "For all intents and purposes, the virtual folder looks and behaves like a real IMAP4 folder, except that it does not contain any messages itself. " 1. If you delete a vmailbox, should it not remove all messages just like deleting a real mailbox? If not, this needs to be in the draft. 2. Expunging messages and the interaction between clients. The mobile client uses vmailbox for trash based on a message being marked \deleted. Now when I access the backing mailbox using a desktop client which does a SELECT and a CLOSE. All \deleted messages with be expunged and now on my mobile client it will look like my trash was magically emptied. Have fun figuring out that bug report ;) 3. " The EXPUNGE Command (RFC 3501 section 6.4.3) causes the underlying mailbox to be expunged when a view is expunged. Servers SHOULD expunge only the messages visible in the view, or MAY expunge the entire mailbox. The former is more desirable, if possible. " I have great mobile client which has this great option to show only unread messages which it does by creating a vmailbox. Now, I go back to my desktop and find a new mailbox which I don't remember creating and it has a bunch duplicate messages from my INBOX. I will just delete this junk mailbox using my desktop client, which does moves all messages to "Deleted Messages", then marks them \deleted and expunges. Hey where did all my new messages go? With the MAY expunge entire mailbox clause, there might even be more messages expunged before the client expects it. Not to mention all the UID games you have to play. I will be happy if we just drop the MAILBOX part and just have FILTERS for views and notifications. CONTENT can cover the view part. Yes? If no then what is missing or wrong. A new draft which applies a FILTER to IDLE. If a server always returns UID in the response then it should be easy for the client to track just the desired changes. C: A1 IDLE (FROM "isode.com") S: + idling S: * 852 EXISTS S: 1 RECENT S: * 924 FETCH (FLAGS (\RECENT) UID 36784) S: * 916 FETCH (FLAGS (\answered \deleted \seen NotJunk $NotJunk) UID 36776) C: done S: A1 OK Idle done C: UID FETCH 924 ... Saving SEARCH criteria can be done using METADATA like external notifications. Then CONTENT and IDLE can use those named searches if so desired. I think most criteria will be hard coded in clients. VMAILBOX is not needed for outband notifications as SIEVE can be used to filter these notifications. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 15:53:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqxtk-0002dS-CD; Thu, 15 Jun 2006 15:53:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqxtk-0002dN-38 for lemonade@ietf.org; Thu, 15 Jun 2006 15:53:00 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqxti-0003Ws-Pc for lemonade@ietf.org; Thu, 15 Jun 2006 15:53:00 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 7B5B7272A7; Thu, 15 Jun 2006 13:52:58 -0600 (MDT) In-Reply-To: <4491AB88.4060100@pathbreaker.com> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> <4491AB88.4060100@pathbreaker.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <69A8533D-F578-43D0-8C3D-2D9B89FB9834@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Thu, 15 Jun 2006 13:53:03 -0600 To: Ray Cromwell X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: lemonade@ietf.org, Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 15-Jun-06, at 12:48 PM, Ray Cromwell wrote: > Curtis King wrote: > >> >> >> Why not just create an index for each search for either VMAILBOX >> or CONTEXT and test each message when it's injected into the >> backing mailbox. VMAILBOX requires the server to have an index >> storing the fake VMAILBOX uids, CONTEXT does not. So, for servers >> which already have really good search performance VMAILBOX has >> higher requirements than CONTEXT. > > > I think this entire thread is predicated on the assumption that > VMAILBOX mandates that servers must allow search criteria on > dynamic attributes or criteria that create the need to assign new > UIDs. The original VFOLDER proposal did not have this feature and > we have not decided whether or not this feature is necessary for > VFOLDERs or if it will be included in the final spec. It was made > optional in the latest VFOLDER draft (adopted from Arnt's VIEW > proposal) precisely so that a) we can have a discussion about the > costs of implementing and b) some people could choose not to > implement it. Not having dynamic attributes makes VMAILBOX very weak especially for mobile clients, yes/no? On my mobile client I only want to see unread messages 90% of the time. We are arguing some fine points, but very important ones. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 16:02:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqy2k-0000wg-7V; Thu, 15 Jun 2006 16:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqy2i-0000wa-Et for lemonade@ietf.org; Thu, 15 Jun 2006 16:02:16 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqy2h-0004W5-09 for lemonade@ietf.org; Thu, 15 Jun 2006 16:02:16 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1Fqy2e-0001IM-Qy; Thu, 15 Jun 2006 20:02:13 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id EF352498003; Thu, 15 Jun 2006 21:02:14 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10266-08; Thu, 15 Jun 2006 21:02:06 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id E6B51498002; Thu, 15 Jun 2006 21:02:05 +0100 (BST) Date: Thu, 15 Jun 2006 21:01:59 +0100 Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> <4491AB88.4060100@pathbreaker.com> In-Reply-To: <4491AB88.4060100@pathbreaker.com> MIME-Version: 1.0 Message-Id: <32502.1150401721.279594@peirce.dave.cridland.net> From: Dave Cridland To: Ray Cromwell Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Enhancements to Internet email to support diverse service enivronments , Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Jun 15 19:48:40 2006, Ray Cromwell wrote: > Curtis King wrote: > > > >> Why not just create an index for each search for either VMAILBOX >> or CONTEXT and test each message when it's injected into the >> backing mailbox. VMAILBOX requires the server to have an index >> storing the fake VMAILBOX uids, CONTEXT does not. So, for servers >> which already have really good search performance VMAILBOX has >> higher requirements than CONTEXT. > > > I think this entire thread is predicated on the assumption that > VMAILBOX mandates that servers must allow search criteria on > dynamic attributes or criteria that create the need to assign new > UIDs. I should point out that currently, I have 10 views defined (aside from test ones). Of those, 3 use only static attribute searches. The other problem is that only takes into account the predefined views I do - I actually do a considerable amount of ad-hoc filtering, which really doesn't fit the VFOLDER model. A lot of this thread is about VFOLDER handling of dynamic criteria, true, but I don't think that a model that doesn't support that is actually viable. For what it's worth, virtual mailboxes do appeal to me, but I can't see them being truly useful unless they can handle multiple source mailboxes with dynamic criteria effectively. For single-mailbox cases, they're arguably useful for legacy client support, but that is a very different use-case to anything we're interested in for Lemonade settings. Unless you're counting Outlook as being a constrained platform, which in the sense of IMAP might arguably be the case. ;-) As I said when I sent the proto-draft to the list, my personal feeling about VFOLDER et al is that it's a good thing, but I'm hesitant to mandate it in Lemonade. (I will, of course, if consensus backs it). All of Lemonade's use-cases for virtual mailboxes can be met with CONTEXTS, and whilst it certainly increases client complexity by a small amount, it's not huge. Moreover, CONTEXTS can provide more than simply virtual mailboxing, it can be used to implement grouped views, summary colouring, and probably several things I haven't thought of. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 16:03:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqy3W-0001qb-GP; Thu, 15 Jun 2006 16:03:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqy3V-0001qF-Qt for lemonade@ietf.org; Thu, 15 Jun 2006 16:03:05 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqy3U-0004Xk-Bb for lemonade@ietf.org; Thu, 15 Jun 2006 16:03:05 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1Fqy3S-0008GW-RZ; Thu, 15 Jun 2006 20:03:02 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id E12BD498003; Thu, 15 Jun 2006 21:03:05 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10266-10; Thu, 15 Jun 2006 21:02:57 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 5E72E498002; Thu, 15 Jun 2006 21:02:57 +0100 (BST) Date: Thu, 15 Jun 2006 21:02:52 +0100 Subject: Re: [lemonade] Contexts Implementation Issues. References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <32502.1150381246.957176@peirce.dave.cridland.net> <9UgYj8LhgiYlEcZRGD6tcA.md5@libertango.oryx.com> In-Reply-To: <9UgYj8LhgiYlEcZRGD6tcA.md5@libertango.oryx.com> MIME-Version: 1.0 Message-Id: <32502.1150401772.762269@peirce.dave.cridland.net> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 2.3 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Jun 15 16:50:23 2006, Arnt Gulbrandsen wrote: >> Acquisition of every context is less work than this. What you're >> basically saying is that it's practical for a client to acquire >> every context defined for the currently selected mailbox at low >> cost. This to my mind is an advantage. > > That's exactly what I meant to say. Now, whether it's an > advantage... I can see the attraction, but I notice that despite > repeated proposals, noone has done a MULTISELECT yet. So maybe the > advantage isn't as large as one would think. > > Or maybe multiselect is just too much of a can of worms. :-) > (Is it more desirable to select multiple search results than > multiple mailboxes? I can't see any reason for that, but I've never > tried to find any.) > > Yes. Group-messages-by is quite a popular Outlook and Thunderbird feature, and involves maintaining multiple continuously presented filtered views of the same mailbox. I can see that, or something similar, being implemented using a couple of contexts in operation. >>> It could be done. The two could use ACAP, IMAP METADATA, WebDAV >>> or some other mechanism external to the CONTEXTS draft. IMAP >>> doesn't have any such mechanisms now. To create one, you need to >>> specify how to label and format the metadata, and also deal with >>> concurrent update issues. >> >> Polymer uses ACAP right now. *shrugs* METADATA would work too. >> Either way, it's orthogonal to the protocol. > > I sort of disagree strongly. Sort of. IMO it's extremely important > to share this data among clients. > > Yes, and I have a solution that I'm quite happy with. I'm quite happy to write a draft describing it, too, and I would be delighted if everyone stored their view criteria in ACAP. I wouldn't be so pleased if people moved this into METADATA, as that's much more limiting. > On the other hand, a user with one mobile device and one stationary > device (most commonly Outlook/OE) is important to me. Since > CONTEXTS can't share in this case, there may not be much point in > sharing. I appreciate that Outlook is a limited IMAP client with a large market share, but I'm afraid that much as I try, I have a client developer's head on today. For server implementors, you want flashy features to be available to even the worst of clients, but for client implements, we tend to want the flashier features available ubiquitously on servers. For you, CONTEXTS is equal complexity, and you could probably implement both without any problems. I happen to think that CONTEXTS has more utility than VIEW, overall, but I can certainly appreciate that VIEW has its uses, especially for legacy client support of course. I would heartily recommend that you implemented both. For some servers, however, CONTEXTS is significantly simpler to support. There are a range of potential implementation strategies - for instance, even a comparitively fast implementation does not need to store a full result set at any time. In general, it's much easier to get a bad implementation of CONTEXTS working, and it will yield the same wire-efficiency advantages to the client. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 16:05:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqy5T-0003pd-L4; Thu, 15 Jun 2006 16:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqy5R-0003pY-NY for lemonade@ietf.org; Thu, 15 Jun 2006 16:05:05 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqy5Q-0004fI-9m for lemonade@ietf.org; Thu, 15 Jun 2006 16:05:05 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 418744AC78; Thu, 15 Jun 2006 22:05:03 +0200 (CEST) Message-Id: Date: Thu, 15 Jun 2006 22:06:47 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> <4491AB88.4060100@pathbreaker.com> <69A8533D-F578-43D0-8C3D-2D9B89FB9834@mumbo.ca> In-Reply-To: <69A8533D-F578-43D0-8C3D-2D9B89FB9834@mumbo.ca> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King writes: > Not having dynamic attributes makes VMAILBOX very weak especially for > mobile clients, yes/no? Yes. > On my mobile client I only want to see unread messages 90% of the time. The "not spam" flag is another popular one. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 16:19:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyJU-0004uw-Sk; Thu, 15 Jun 2006 16:19:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyJT-0004ul-0q for lemonade@ietf.org; Thu, 15 Jun 2006 16:19:35 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqyJR-0005qa-FV for lemonade@ietf.org; Thu, 15 Jun 2006 16:19:35 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 3E62B4AC78; Thu, 15 Jun 2006 22:19:32 +0200 (CEST) Message-Id: Date: Thu, 15 Jun 2006 22:21:16 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Contexts Implementation Issues. References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <32502.1150381246.957176@peirce.dave.cridland.net> <9UgYj8LhgiYlEcZRGD6tcA.md5@libertango.oryx.com> <32502.1150401772.762269@peirce.dave.cridland.net> In-Reply-To: <32502.1150401772.762269@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > On Thu Jun 15 16:50:23 2006, Arnt Gulbrandsen wrote: >> (Is it more desirable to select multiple search results than multiple >> mailboxes? I can't see any reason for that, but I've never tried to >> find any.) > > Yes. Group-messages-by is quite a popular Outlook and Thunderbird > feature, and involves maintaining multiple continuously presented > filtered views of the same mailbox. > > I can see that, or something similar, being implemented using a couple > of contexts in operation. Or by the client, which has to fetch the information it groups by anyway, in order to display it. >> On the other hand, a user with one mobile device and one stationary >> device (most commonly Outlook/OE) is important to me. Since CONTEXTS >> can't share in this case, there may not be much point in sharing. > > I appreciate that Outlook is a limited IMAP client with a large market > share, but I'm afraid that much as I try, I have a client developer's > head on today. For server implementors, you want flashy features to > be available to even the worst of clients, but for client implements, > we tend to want the flashier features available ubiquitously on > servers. And I have my user experience head on... the very idea of opening an unneeded gap between how peoples' clients read mail in the most common configuration is abhorrent to me. > For you, CONTEXTS is equal complexity, and you could probably > implement both without any problems. Restating that: If I implement CONTEXTS and keep at it until it doesn't suck, I can do VFOLDER at no extra cost and get 100% reader compatibility. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 16:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyJV-0004v8-3a; Thu, 15 Jun 2006 16:19:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyJU-0004ur-B5 for lemonade@ietf.org; Thu, 15 Jun 2006 16:19:36 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqyJS-0005qd-TG for lemonade@ietf.org; Thu, 15 Jun 2006 16:19:36 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 624C9272A7; Thu, 15 Jun 2006 14:19:30 -0600 (MDT) In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Thu, 15 Jun 2006 14:19:35 -0600 To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 15-Jun-06, at 1:28 PM, Arnt Gulbrandsen wrote: > Curtis King writes: >> On 15-Jun-06, at 5:26 AM, Arnt Gulbrandsen wrote: >>> Curtis King writes: >>>> I would hate to create VMAILBOX on such a server ;) An index is an >>>> index the cost will be same, except with CONTEXT there will be 1 >>>> less for each "view". >>> >>> I don't see that. The work required to update the index differs >>> substantially. >> >> Why not just create an index for each search for either VMAILBOX or >> CONTEXT and test each message when it's injected into the backing >> mailbox. VMAILBOX requires the server to have an index storing the >> fake VMAILBOX uids, CONTEXT does not. > > That seems to be a big point for you. I really don't see why. Can > you explain? Because UIDs need to-be permanent, even more so with mobile clients to avoid download the same message more than once. This means UIDs need to be handled with special care. Search indexes, message caches, etc all can be lost from time to time with no impact to the client. To me this is a big point. > >> So, for servers which already have really good search performance >> VMAILBOX has higher requirements than CONTEXT. > > I doubt it. (My code goes to some effort to search fast, and it's all > ineffective for a single message. The optimizations are more effective > the bigger the mailbox is.) That's my point. If you already indexing new messages supporting CONTEXT is easy. >>>>> For CONTEXTS, there is a nice fallback to working with stock IMAP >>>>> servers. For VFOLDER, there is none. >>>>> >>>>> For CONTEXTS, two clients don't stay in sync, unless the clients >>>>> share state in some way outside the extension. VFOLDER works with >>>>> vanilla and extended IMAP clients. >>>> >>>> What? Clients stay in sync using existing IMAP mechanisms. >>> >>> How does this work? It's not clear to me from the draft. Take the >>> case where I read mail using my mobile device milonga and my office >>> machine libertango. When I create, modify or delete a context on >>> milonga, how does libertango learn about change context? >> >> Why do I need to share the context? Isn't the client interested in >> the changes to message? > > Every use case I've seen so far for vfolder was of a kind that's > naturally shared, in the sense that if you have a certain vfolder on > your desktop, you want the same on your laptop. This works best when you are using the same client. The longer the discussion goes on, the more I think we need ACAP light or IMSP. (I'm only half joking here) > > Consider my message earlier today, where I mentioned 15 views. That > contained five or six substantially different ones, all of which are > naturally shared. > > Even the case where you don't want to read the mail is naturally > shared. > Suppose you don't want to read work mail when you're at home. If you > don't have the "work mail" view on your home computer, the work mail > shows up in "other nonspam". Wouldn't the messages still be in my INBOX? Which clients insist on selecting no matter what ;) For clients to take advantage of views they need to-be updated to least let me set which mailbox to use as the INBOX. Which is one of the reason we should forget about trying to support non-lemonade clients. > >> Most likely I won't even want the same VMAILBOX on all my clients. I >> would argue it's better not to force clients to have the same view, >> but instead allow them to create the views which best suit their >> usage model. > > (I like the term view, perhaps because it's what DB people use for > this. > Can we use it in this discussion?) yes, there are two parts to all of this views and notifications. > > Even if users.cking.workmail exists and is available on your office > desktop, your computer at home, your laptop and your 770, you don't > have to read it everywhere. > >>> I agree... but we can make poor implementations worse by adding a >>> badly-considered feature. >> >> Which I think VMAILBOX is. I have tried to implement it and there are >> too many holes in it. > > Tell more? I agree for the previous version of the draft. The current > version includes lots of text from draft-gulbrandsen-imap-view, > which I > have implemented and I only know about one hole (regarding listext > syntax). Of course, since I wrote that text I do suffer from a certain > myopia. see the message I sent to Ray on how clients interact with messages being expunged. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 16:29:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyT7-000350-PO; Thu, 15 Jun 2006 16:29:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyT6-00033j-DU for lemonade@ietf.org; Thu, 15 Jun 2006 16:29:32 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqyT5-0006Ew-4j for lemonade@ietf.org; Thu, 15 Jun 2006 16:29:32 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id D1A43272A7; Thu, 15 Jun 2006 14:29:30 -0600 (MDT) In-Reply-To: References: <330A23D8336C0346B5C1A5BB1966664702F6D3C7@ATLANTIS.Brooktrout.com > <819071B2-926A-4A71-909E-D2D14697F9E6@mumbo.ca> <704E8D59-6D8F-4D53-B015-21B7458605A7@mumbo.ca> <54B49360-1AB8-49CC-B39E-EFE203A5AD56@mumbo.ca> <1C041CB4-9A26-402E-97BD-45DD6EC82CAE@mumbo.ca> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] Draft Minutes, Interim Day 1 Date: Thu, 15 Jun 2006 14:29:35 -0600 To: Cyrus Daboo X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Cyrus thanks for the links to those drafts there are very useful. On 13-Jun-06, at 7:56 AM, Cyrus Daboo wrote: > Note that both of these were also trying to deal with the problem > of so called 'scalability' issues with SORT and THREAD (the fact > that a client has to issue a SORT/THREAD every time the mailbox > changes). Now this is more useful than VMAILBOX. > > It would certainly be possible to re-do VIEW as a much simpler > 'static' view of a mailbox without all the extra VIEW id stuff etc > and come up with something as 'simple' as VMAILBOX. I agree. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 17:30:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqzPc-0008Nl-Ja; Thu, 15 Jun 2006 17:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqzPb-0008Ng-EF for lemonade@ietf.org; Thu, 15 Jun 2006 17:29:59 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqzPY-0006nH-V4 for lemonade@ietf.org; Thu, 15 Jun 2006 17:29:59 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FqzPX-0005Uo-J0; Thu, 15 Jun 2006 21:29:55 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 493A6498003; Thu, 15 Jun 2006 22:30:00 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10644-10; Thu, 15 Jun 2006 22:29:51 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 2E163498002; Thu, 15 Jun 2006 22:29:51 +0100 (BST) Date: Thu, 15 Jun 2006 22:29:45 +0100 Subject: Re: [lemonade] Contexts Implementation Issues. References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <32502.1150381246.957176@peirce.dave.cridland.net> <9UgYj8LhgiYlEcZRGD6tcA.md5@libertango.oryx.com> <32502.1150401772.762269@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <32502.1150406985.926672@peirce.dave.cridland.net> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Jun 15 21:21:16 2006, Arnt Gulbrandsen wrote: > Dave Cridland writes: >> On Thu Jun 15 16:50:23 2006, Arnt Gulbrandsen wrote: >>> (Is it more desirable to select multiple search results than >>> multiple mailboxes? I can't see any reason for that, but I've >>> never tried to find any.) >> >> Yes. Group-messages-by is quite a popular Outlook and Thunderbird >> feature, and involves maintaining multiple continuously presented >> filtered views of the same mailbox. >> >> I can see that, or something similar, being implemented using a >> couple of contexts in operation. > > Or by the client, which has to fetch the information it groups by > anyway, in order to display it. > > No it doesn't. :-) It only needs to fetch the entire summary data if it needs to display it all, and the grouping information may potentially not be within that data anyway. >>> On the other hand, a user with one mobile device and one >>> stationary device (most commonly Outlook/OE) is important to me. >>> Since CONTEXTS can't share in this case, there may not be much >>> point in sharing. >> >> I appreciate that Outlook is a limited IMAP client with a large >> market share, but I'm afraid that much as I try, I have a client >> developer's head on today. For server implementors, you want >> flashy features to be available to even the worst of clients, but >> for client implements, we tend to want the flashier features >> available ubiquitously on servers. > > And I have my user experience head on... the very idea of opening > an unneeded gap between how peoples' clients read mail in the most > common configuration is abhorrent to me. > > I will happily encourage you into doing VFOLDER, I think it's an excellent tool for providing legacy support, if carefully managed. >> For you, CONTEXTS is equal complexity, and you could probably >> implement both without any problems. > > Restating that: If I implement CONTEXTS and keep at it until it > doesn't suck, I can do VFOLDER at no extra cost and get 100% reader > compatibility. Probably, in your implementation, but not in others. In others, the cost of VFOLDER is higher. Consider: CONTEXT itself requires just parsing and ignoring. NOTIFY does not require the full set of results in memory for efficiency, all you need is the ability to detect, on a change in the mailbox, whether the criteria match before the change, and whether they match after the change. (One method of handling detection of whether criteria match before the change is to store the full set of results, of course, and this might even be the only practical method, depending on your implementation). PARTIAL does benefit from storage of results, generally from the beginning of the mailbox up to and including the highest matching message returned by a PARTIAL. In other words, you just iterate through the mailbox as required to satisfy PARTIAL, and no further. This is still much more efficient than performing the entire search each time. For SORT, things are a bit different, since both NOTIFY and PARTIAL require a full set of results, but that's a different state of affairs. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 19:04:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0t4-0006bQ-4S; Thu, 15 Jun 2006 19:04:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0t2-0006aL-L8 for lemonade@ietf.org; Thu, 15 Jun 2006 19:04:28 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr0t1-0008F3-7l for lemonade@ietf.org; Thu, 15 Jun 2006 19:04:28 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5FN4PAG017113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Jun 2006 16:04:26 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5FN4NuO017605; Thu, 15 Jun 2006 16:04:24 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 15 Jun 2006 16:01:17 -0700 To: Chris Newman From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Thanks, Chris, for (re)submitting this. A few requested clarifications for Section 5 (Event Parameters): The 'service' parameter is interesting in the case where the the user accesses the mail store via one protocol (such as HTTP) which itself accesses the mail store via another protocol (such as IMAP). As an example, there are a number of popular webmail products which use IMAP (or even POP!) to access mail. From the mail store's perspective, all such access is via IMAP and likely from an IP address that is not especially interesting (such as 127.0.0.1). I'm not sure how to accommodate this in a general event framework, though. A 'pass-through' parameter would be useful, but there isn't anything I can think of off-hand in IMAP to pass such information through, so it might be best left for future extension, perhaps with a note about it. The 'timestamp' parameter should be specified as to its form. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There will be no lasting peace on our earth as long as politicians and dictators continue to lead masses of people who are endemically neurotic and sexually sick. --Wilhelm Reich _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 19:09:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0xr-0001JT-Ti; Thu, 15 Jun 2006 19:09:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0xr-0001JO-19 for lemonade@ietf.org; Thu, 15 Jun 2006 19:09:27 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr0xp-0000Ss-MU for lemonade@ietf.org; Thu, 15 Jun 2006 19:09:27 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5FN9O5Z023166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 15 Jun 2006 16:09:24 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5FN9MvB002372 for ; Thu, 15 Jun 2006 16:09:23 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC16124465738F36E@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC16124465738F36E@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 15 Jun 2006 16:08:27 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:58 AM +0300 6/8/06, wrote: > Hi all, > A few comments/questions: > - General: it is unclear which events will go to the clients and > which ones for admins (or both). I think this is a question for the filtering mechanism, the subscribe/publish mechanism, and the event delivery protocol. > Take OverQuota or Login as an example. Perhaps the reason is that > this draft is simply a collection of event definitions without > context? If so, it is fine, but then the bis (or the notification > draft needs to put each and every one of these into context). As the Abstract mentions, this draft describes the events that real-world customers ask their mail stores to provide. How such events are used is the scope of the using protocols. > - OverQuota and UnderQuota does not quite belong to "4.1. Message > Addition and Deletion" . Should we move it to "4.3. Access > Accounting"? I don't much care in which section quota events go, but it seems most likely for these to be generated by the addition and deletion of messages. (The other cases include administrative changes to the quota, but those probably a lot of common.) > - Can we add more events? Like MailboxCreated (name), > MailboxRenamed (name, newname), MailboxDeleted (name), MailboxMoved > (name, targetmailbox)? - This is for 'folder' management, but there > could be a lot more. I'll let others comment on this. > - Extension mechanism? (To define custom events and parameters when needed?) It seems to me that new events and parameters can be created by additional documents, but perhaps an explicit mention of this would be a good idea. Are these events to be maintained in an IANA registry or simply in the published RFCs? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- "And what will you do when you grow up to be as big as me?" asked the father of his little son. "Diet." _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 20:25:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr29Q-0000M0-I7; Thu, 15 Jun 2006 20:25:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr29O-0000LA-KA for lemonade@ietf.org; Thu, 15 Jun 2006 20:25:26 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr29N-0000qm-4u for lemonade@ietf.org; Thu, 15 Jun 2006 20:25:26 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5G0PKUN024572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Jun 2006 17:25:21 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5G0PI8S023509; Thu, 15 Jun 2006 17:25:19 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4490FC6F.1050500@pathbreaker.com> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <4490FC6F.1050500@pathbreaker.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 15 Jun 2006 17:17:40 -0700 To: Ray Cromwell , Dave Cridland From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:21 PM -0700 6/14/06, Ray Cromwell wrote: > Dave Cridland wrote: > >> This is primarily aimed at item (2). I don't perceive getting >> state changes for messages outside the criteria to be a problem, I >> simply don't think mailboxes with sufficient activity for this to >> be a problem exist such that they're likely to be looked at on a >> mobile device. >> > The original motivation for VFOLDER was an attempt to solve > multiple use case issues, such as #1 and #2, and handle legacy > clients, among other things. It is true that separate mechanisms > can be designed for this (notifications), but I am concerned about > duplicating effort and complicating the job that the mobile client > has to do to provide the illusion that they are not separate (to > the user) (i.e. messages grouped into a "folder" on the client for > reasons of client-side cache and network traffic, and messages > grouped into a "folder" on the client for reasons for notifications) > > I had thought that there was consensus that out-of-band > notifications were important for several reasons, such as > satisfying OMA requirements and enhancing battery life on mobile > clients. The work done on notifications so far has assumed the > existence of something like VFOLDER in its architecture, because > the assumption is that users do want to control the set of messages > and events which generate out-of-band notifications. I disagree > that mailboxes with sufficient activity for this to be a problem > don't exist, in fact, a mailbox that gets only a few dozen messages > and state changes per day would still be a candidate, depending on > the cost of out-of-band notifications. Hi Ray, Reading Dave's reply to my message, and your reply to Dave, makes me think you misunderstood something Dave said. I had posited two use cases for vmailboxes: At 11:59 AM -0700 6/13/06, Randall Gellens wrote: > (1) allowing a client to get notifications only for state changes > to a subset of "interesting" messages, and (2) allowing a client to > conceive of a mailbox as a subset of "interesting" messages to > reduce the size of its cache and the amount of traffic exchanged > with the server. In Dave's reply, he suggested that, in the case of (2), that it wasn't a problem if clients got notifications of state changes for all messages in a mailbox, even those outside the subset of those that were "interesting": At 11:09 PM +0100 6/13/06, Dave Cridland wrote: > I don't perceive getting state changes for messages outside the > criteria to be a problem, I simply don't think mailboxes with > sufficient activity for this to be a problem exist such that > they're likely to be looked at on a mobile device. So Dave was talking about notifications for state changes to messages outside the selection criteria, that is, "uninteresting" ones. From your reply, it seemed to me that you may have misread Dave's reply as talking about notifications for messages inside the selection criteria, that is, "interesting" ones. As I read his reply, Dave was saying it was OK for clients to simply ignore notifications for messages outside the criteria. Your reply seemed to be based on an understanding that Dave was saying clients don't need to be notified of messages inside the selection criteria. Naturally, if I'm the one that misunderstood either your reply or Dave's, please correct me. > The use case for vfolders and notifications goes something like this: > > 1) user wants "push-like" mobile experience for some category of messages > 2) user tells server which criteria it wants for these mobile > messages (e.g. create a vfolder that includes only those messages) > 3) user tells server which events in this folder it wants to > receive notifications for > > So VFOLDER fulfills dual purposes in use case #2, it allows > reduction of client cache and network traffic, but it also provided > a named grouping which could have attached notification semantics > (#3). We haven't yet decided how #3 works (sieve?) but part of the > motiviation for making vfolders behave like ordinary folders was > that presumably, whatever notification mechanisms the group decided > on would work equally well with regular folders and with vfolders, > so there wouldn't be a need for separate mechanisms for each. > > So my concern is, how do out-of-band notifications work with the > context proposal? And secondly, how does inband notifications in > the context proposal, and IDLE, and the msgevents draft go > together? Are we heading along the way of having 3 separate in-band > mechanisms for delivering state changes? I think Dave's proposal covers in-band notifications, although there is still some discussion on how this interacts with reconnect, that is, what happens when the client disconnects and preserves the session. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Ignorance is nothing more than indifference to what is before us; we have only to pay attention--and we are paying attention in a way, but to pretty noise, the newer the better. --Wyatt Mason, review of E.E. Cummings biography, Harper's May 2005. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 20:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr2Sf-0008GJ-PY; Thu, 15 Jun 2006 20:45:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr2Sb-000857-OS; Thu, 15 Jun 2006 20:45:17 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr2SZ-0002ox-9F; Thu, 15 Jun 2006 20:45:17 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k5G0jEUE012679; Thu, 15 Jun 2006 17:45:14 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k5G0jEVR012678; Thu, 15 Jun 2006 17:45:14 -0700 Date: Thu, 15 Jun 2006 17:45:14 -0700 Message-Id: <200606160045.k5G0jEVR012678@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: lemonade@ietf.org, rfc-editor@rfc-editor.org Subject: [lemonade] RFC 4550 on Internet Email to Support Diverse Service Environments (Lemonade) Profile X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4550 Title: Internet Email to Support Diverse Service Environments (Lemonade) Profile Author: S. Maes, A. Melnikov Status: Standards Track Date: June 2006 Mailbox: stephane.maes@oracle.com, Alexey.melnikov@isode.com Pages: 23 Characters: 48790 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-lemonade-profile-07.txt URL: http://www.rfc-editor.org/rfc/rfc4550.txt This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server. The Internet Email to Support Diverse Service Environments (Lemonade) profile relies upon extensions to IMAP and Mail Submission protocols; specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) extensions and the BURL extension to the SUBMIT protocol (RFC 4409). [STANDARDS TRACK] This document is a product of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 21:48:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3Rp-0000eo-QS; Thu, 15 Jun 2006 21:48:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3Rn-0000cT-Ee for lemonade@ietf.org; Thu, 15 Jun 2006 21:48:31 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr3Rm-0002n9-2X for lemonade@ietf.org; Thu, 15 Jun 2006 21:48:31 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5G1mRu2002784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Jun 2006 18:48:28 -0700 Received: from [192.168.1.13] (vpn-10-50-16-135.qualcomm.com [10.50.16.135]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5G1mQbH016552; Thu, 15 Jun 2006 18:48:27 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 15 Jun 2006 18:46:00 -0700 To: Curtis King From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:37 AM -0600 6/15/06, Curtis King wrote: > I would hate to create VMAILBOX on such a server ;) An index is an > index the cost will be same, except with CONTEXT there will be 1 > less for each "view". One fewer index or one fewer data item per index (the second UID)? > The performance issue is listing of all the mailboxes and > vmailboxes, more so with clients than servers. This is one biggest > problems with some existing clients today, vmailboxes will make the > situation worst. The performance issue is that it is hard for clients to manage large numbers of mailboxes? Because they need to poll each one for state changes? >> When a mailbox is deleted or renamed, VFOLDER specifies a certain >> behaviour (which may or may not be considered good behaviour), >> CONTEXTS makes it depend on whether the rename/delete was issued >> by the context-owning client or some other. > > Incorrect it should be handled the same way as having any other > mailbox deleted or renamed currently. Since a CONTEXT, as I understand it, only "sort of" exists, if the underlying mailbox is deleted then it can't exist any more. The difference between the client that created the context and others is that the context never existed for the others, right? > Thinking you can solve poor client implementations by adding a > feature to servers is overly optimisic. As I pointed out VMAILBOX > can make some "plain IMAP" clients perform worst. We do need to > trust developers will produce the best servers and clients they > can. A great protocol doesn't prevent bad implementations. One thing we can do is to provide more advice on the right way to use the protocol. There have been some attempts at this before (offhand, RFC 2180 and RFC 2683). It may be helpful to have another, and to mention the previous ones in profile-bis. > I prefer instead to give the client developers more tools to make > better clients with. One problem when developing clients is the > most you can expect a server to support is RFC3501 until now. > LEMONADE sets a new standard which clients can expect from most > major servers. I think most active desktop clients will start to > use the tools set the by LEMONADE profile. I agree. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- ...All repairs tend to destroy the structure [of the software], to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes. As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress. [...] Systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence. --Fred Brooks in _The Mythical Man Month_ _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 21:53:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3Wq-0002uW-JX; Thu, 15 Jun 2006 21:53:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3Wp-0002uL-Ak for lemonade@ietf.org; Thu, 15 Jun 2006 21:53:43 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr3Wo-0002wW-2B for lemonade@ietf.org; Thu, 15 Jun 2006 21:53:43 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 9BA41272A7 for ; Thu, 15 Jun 2006 19:53:41 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <50726B29-AEC8-4919-9CA6-34A524C33AC3@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Thu, 15 Jun 2006 19:53:47 -0600 To: Enhancements to Internet email to support diverse serviceenivronments X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 15-Jun-06, at 1:46 PM, Curtis King wrote: > CONTENT can cover the view part. Yes? If no then what is missing or > wrong. > > A new draft which applies a FILTER to IDLE. If a server always > returns UID in the response then it should be easy for the client > to track just the desired changes. I missed, we would need IDLE only if the notification part of CONTEXT was an issue because it didn't meet some requirement or we didn't want two inband notification mechanisms. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 21:55:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3Yc-0005XK-8S; Thu, 15 Jun 2006 21:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3Ya-0005XA-PK for lemonade@ietf.org; Thu, 15 Jun 2006 21:55:32 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr3YY-0003Ar-FL for lemonade@ietf.org; Thu, 15 Jun 2006 21:55:32 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 2EC68272A7; Thu, 15 Jun 2006 19:55:30 -0600 (MDT) In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Thu, 15 Jun 2006 19:55:36 -0600 To: Mark Crispin X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 15-Jun-06, at 1:32 PM, Mark Crispin wrote: > On Thu, 15 Jun 2006, Arnt Gulbrandsen wrote: >>> I haven't seen clients do LIST * for long time. Clients trying to >>> discover the whole mailbox hierarchy at every startup using LIST "" >>> %, LIST "" foo/% which have the performance problems. In some cases >>> issuing LIST * would be better than their existing behavior ;) >> OK, OK, I should have said "LIST * or the equivalent series of LIST >> ...%... commands". > > So, are you saying that there are clients that walk the entire tree > using % just to avoid doing a *? Unbelievable. It's even worst than that they also issue a status for each new mailbox they find. > > The whole point of "LIST * is harmful" is that walking the entire > tree is harmful. > > I can see a client doing "LIST %", followed by "LIST %/%" if the > server does not advertise CHILDREN and needs to know that. But any > further tree prowling should be deferred until the user actually > looks in a name that has inferiors. You would think that's the obvious solution. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 22:00:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3dQ-0008Oy-Iz; Thu, 15 Jun 2006 22:00:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3dP-0008Ol-Ba for lemonade@ietf.org; Thu, 15 Jun 2006 22:00:31 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr3dO-0003cT-18 for lemonade@ietf.org; Thu, 15 Jun 2006 22:00:31 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5G20SoD004248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 15 Jun 2006 19:00:29 -0700 Received: from [192.168.1.13] (vpn-10-50-16-135.qualcomm.com [10.50.16.135]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5G20Q6J006062 for ; Thu, 15 Jun 2006 19:00:27 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <449111CA.5040908@pathbreaker.com> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 15 Jun 2006 18:55:19 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:52 AM -0700 6/15/06, Ray Cromwell wrote: > CONTEXT doesn't make it easy for two or more devices or users to > share a 'virtual' view into a mailbox. While this sounds attractive, I'd like to better understand how it would be used and how important it is. I think this goes back to the use cases for vmailboxes. I'd previously suggested two use cases, but I haven't seen others, and if they are in the draft I've missed them. > Neither spec handles multiple mailbox searches which is clearly a > highly desirable user feature, I assume multiple mailbox CONTEXTs/VMAILBOXes are useful because they reduce the client load, over the air/wire traffic, and latency. That is, clients could use one CONTEXT or VMAILBOX to have a view into "interesting" messages that happen to be in a any of a number of mailboxes. Either way, the client needs to know the actual mailbox, I assume, in order to let the user move or delete a message. > and CONTEXT doesn't handle, atleast in an obvious way, a crucial > part of the Lemonade OMA MEM realization for notifications) Meaning out of band notifications? I though that for both context and vmailbox Sieve would be used for this. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- What is mind? No matter. What is matter? Never mind. --Thomas Hewitt Key, 1799-1875 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 15 23:11:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr4k3-00040d-Pa; Thu, 15 Jun 2006 23:11:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr4k2-00040U-SQ for lemonade@ietf.org; Thu, 15 Jun 2006 23:11:26 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr4k1-0000mi-Gq for lemonade@ietf.org; Thu, 15 Jun 2006 23:11:26 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 148ED272A7; Thu, 15 Jun 2006 21:11:25 -0600 (MDT) In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Thu, 15 Jun 2006 21:11:31 -0600 To: Randall Gellens X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 15-Jun-06, at 7:46 PM, Randall Gellens wrote: > At 12:37 AM -0600 6/15/06, Curtis King wrote: > >> I would hate to create VMAILBOX on such a server ;) An index is >> an index the cost will be same, except with CONTEXT there will be >> 1 less for each "view". > > One fewer index or one fewer data item per index (the second UID)? It could be either depending on the implementation. The big win is for CONTEXT the index can be lost with no penalty to the client, where as with VMAILBOX the client would have to download the messages again because there would be new UID returned for each message. > > >> The performance issue is listing of all the mailboxes and >> vmailboxes, more so with clients than servers. This is one biggest >> problems with some existing clients today, vmailboxes will make >> the situation worst. > > The performance issue is that it is hard for clients to manage > large numbers of mailboxes? Some clients have a great desire to walk the whole mailbox hierarchy using LIST "" foo/%, so they can build a nice tree. This takes a long time. > Because they need to poll each one for state changes? It's more they want to poll for state changes right at the start when combined with the walking of hierarchy it makes for very long connect and reconnect times. > > >>> When a mailbox is deleted or renamed, VFOLDER specifies a >>> certain behaviour (which may or may not be considered good >>> behaviour), CONTEXTS makes it depend on whether the rename/delete >>> was issued by the context-owning client or some other. >> >> Incorrect it should be handled the same way as having any other >> mailbox deleted or renamed currently. > > Since a CONTEXT, as I understand it, only "sort of" exists, if the > underlying mailbox is deleted then it can't exist any more. The > difference between the client that created the context and others > is that the context never existed for the others, right? correct. Having a mailbox deleted when there is an active context should be handled the same as when it has a mailbox selected. > > >> Thinking you can solve poor client implementations by adding a >> feature to servers is overly optimisic. As I pointed out VMAILBOX >> can make some "plain IMAP" clients perform worst. We do need to >> trust developers will produce the best servers and clients they >> can. A great protocol doesn't prevent bad implementations. > > One thing we can do is to provide more advice on the right way to > use the protocol. There have been some attempts at this before > (offhand, RFC 2180 and RFC 2683). It may be helpful to have > another, and to mention the previous ones in profile-bis. I agree. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 02:38:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr7xt-0000Jc-Mq; Fri, 16 Jun 2006 02:37:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr7xs-0000Hc-MW for lemonade@ietf.org; Fri, 16 Jun 2006 02:37:56 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr7xr-0004jN-2Y for lemonade@ietf.org; Fri, 16 Jun 2006 02:37:56 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E03AA4AC6C; Fri, 16 Jun 2006 08:37:53 +0200 (CEST) Message-Id: Date: Fri, 16 Jun 2006 08:39:40 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> In-Reply-To: <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King writes: > Here are a few of the problems I have run into so far and would like > authors to explain what should happen. > > "For all intents and purposes, the virtual folder looks and behaves like a > real IMAP4 folder, except that it does not contain any messages itself. " > > 1. If you delete a vmailbox, should it not remove all messages just > like deleting a real mailbox? If not, this needs to be in the draft. It should not, which is just like a real mailbox. If you use Sieve rules to ensure that mail from your SO ends up in both INBOX.lillian INBOX, and then delete INBOX.lillian, the same messages remain in INBOX. Similarly, if you create INBOX.lillian vfolder as a view into INBOX which maps out messages from Lillian, and then delete INBOX.lillian, INBOX remains unaffected. No difference. > 2. Expunging messages and the interaction between clients. The mobile > client uses vmailbox for trash based on a message being marked > \deleted. Now when I access the backing mailbox using a desktop > client which does a SELECT and a CLOSE. All \deleted messages with be > expunged and now on my mobile client it will look like my trash was > magically emptied. Have fun figuring out that bug report ;) That's also just like a real mailbox. Another client empties the trash (by closing or expunging), and the mobile client sees that the trash went away. > 3. " The EXPUNGE Command (RFC 3501 section 6.4.3) causes the underlying > mailbox to be expunged when a view is expunged. Servers SHOULD > expunge only the messages visible in the view, or MAY expunge the > entire mailbox. The former is more desirable, if possible. " > > I have great mobile client which has this great option to show only > unread messages which it does by creating a vmailbox. Now, I go back > to my desktop and find a new mailbox which I don't remember creating > and it has a bunch duplicate messages from my INBOX. I will just > delete this junk mailbox using my desktop client, which does moves > all messages to "Deleted Messages", then marks them \deleted and > expunges. Hey where did all my new messages go? > > With the MAY expunge entire mailbox clause, there might even be more > messages expunged before the client expects it. I remember feeling a bit uncertain about whether to allow the 't' right. I decided against allowing 'i', but couldn't make up my mind about 't'. This makes it simple: 't' must be withheld. > Not to mention all the UID games you have to play. In my case, those UID games were zero. I had implemented APPEND, so I had the code already. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 02:41:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr81P-0001wh-0N; Fri, 16 Jun 2006 02:41:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr81N-0001wS-MK for lemonade@ietf.org; Fri, 16 Jun 2006 02:41:33 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr81M-0005MX-0K for lemonade@ietf.org; Fri, 16 Jun 2006 02:41:33 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 215B64AC6C; Fri, 16 Jun 2006 08:41:31 +0200 (CEST) Message-Id: <0m9d0uQfOFliUXnOU8hrtA.md5@libertango.oryx.com> Date: Fri, 16 Jun 2006 08:43:17 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> In-Reply-To: <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King writes: >> Yes, in a pathological case, CONTEXT would be more efficient since >> presumably the client would issue a single uber-search and parse >> out the results into individual 'vmailboxes' on the client side, >> rather than issue dozens of searches. But, what you see as a bug >> for a pathological case (vmailboxes show up in LIST) I see as a >> feature (clients can share vmailboxes easily) > > Once again, what's the big deal with sharing vmailboxes? I want to share all of mine. Ask Dave how many of the ten he mentioned yesterday he wants to share. > The point I'm trying to make is we need to drop the idea that we can > improve existing clients with VMAILBOX. Let's drop backward > compatibility, so we can get the correct solution in a timely manner. I understand that, and my judgment is different: We're not improving existing mailboxes if we show them the vfolders, we're worsening them if we don't. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 03:07:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr8Q4-00008n-Ui; Fri, 16 Jun 2006 03:07:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr8Q2-00008h-Oo for lemonade@ietf.org; Fri, 16 Jun 2006 03:07:02 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr8Q1-0007zv-9S for lemonade@ietf.org; Fri, 16 Jun 2006 03:07:02 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id AD78B272A7; Fri, 16 Jun 2006 01:06:58 -0600 (MDT) In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E3A8277-3436-4C8E-8EAB-56A8DEC7EA54@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Fri, 16 Jun 2006 01:07:04 -0600 To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 16-Jun-06, at 12:39 AM, Arnt Gulbrandsen wrote: > Curtis King writes: >> Here are a few of the problems I have run into so far and would >> like authors to explain what should happen. >> >> "For all intents and purposes, the virtual folder looks and >> behaves like a >> real IMAP4 folder, except that it does not contain any messages >> itself. " >> >> 1. If you delete a vmailbox, should it not remove all messages >> just like deleting a real mailbox? If not, this needs to be in >> the draft. > > It should not, which is just like a real mailbox. What? The last time I deleted a real mailbox it deleted all messages in it. > If you use Sieve rules to ensure that mail from your SO ends up in > both INBOX.lillian INBOX, and then delete INBOX.lillian, the same > messages remain in INBOX. That's because it was copied. > Similarly, if you create INBOX.lillian vfolder as a view into INBOX > which maps out messages from Lillian, and then delete > INBOX.lillian, INBOX remains unaffected. No difference. Why isn't that true when I expunge messages in the virtual mailbox? > >> 2. Expunging messages and the interaction between clients. The >> mobile client uses vmailbox for trash based on a message being >> marked \deleted. Now when I access the backing mailbox using a >> desktop client which does a SELECT and a CLOSE. All \deleted >> messages with be expunged and now on my mobile client it will >> look like my trash was magically emptied. Have fun figuring out >> that bug report ;) > > That's also just like a real mailbox. Another client empties the > trash (by closing or expunging), and the mobile client sees that > the trash went away. No it's not. When I close my INBOX it does not expunge messages in my Trash folder. > >> 3. " The EXPUNGE Command (RFC 3501 section 6.4.3) causes the >> underlying >> mailbox to be expunged when a view is expunged. Servers SHOULD >> expunge only the messages visible in the view, or MAY expunge the >> entire mailbox. The former is more desirable, if possible. " >> >> I have great mobile client which has this great option to show >> only unread messages which it does by creating a vmailbox. Now, I >> go back to my desktop and find a new mailbox which I don't >> remember creating and it has a bunch duplicate messages from my >> INBOX. I will just delete this junk mailbox using my desktop >> client, which does moves all messages to "Deleted Messages", then >> marks them \deleted and expunges. Hey where did all my new >> messages go? >> >> With the MAY expunge entire mailbox clause, there might even be >> more messages expunged before the client expects it. > > I remember feeling a bit uncertain about whether to allow the 't' > right. I decided against allowing 'i', but couldn't make up my mind > about 't'. This makes it simple: 't' must be withheld. We continue to move further away from "For all intents and purposes, the virtual folder looks and behaves like a real IMAP4 folder, except that it does not contain any messages itself." The mailbox metaphor doesn't work for filters. Time to move on. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 03:11:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr8UY-00053q-JV; Fri, 16 Jun 2006 03:11:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr8UX-00053g-Rv for lemonade@ietf.org; Fri, 16 Jun 2006 03:11:41 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr8UW-0000QH-CI for lemonade@ietf.org; Fri, 16 Jun 2006 03:11:41 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 602894AC71; Fri, 16 Jun 2006 09:11:39 +0200 (CEST) Message-Id: Date: Fri, 16 Jun 2006 09:13:25 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Contexts Implementation Issues. References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <32502.1150381246.957176@peirce.dave.cridland.net> <9UgYj8LhgiYlEcZRGD6tcA.md5@libertango.oryx.com> <32502.1150401772.762269@peirce.dave.cridland.net> <32502.1150406985.926672@peirce.dave.cridland.net> In-Reply-To: <32502.1150406985.926672@peirce.dave.cridland.net> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland writes: > On Thu Jun 15 21:21:16 2006, Arnt Gulbrandsen wrote: >> Restating that: If I implement CONTEXTS and keep at it until it >> doesn't suck, I can do VFOLDER at no extra cost and get 100% reader >> compatibility. > > Probably, in your implementation, but not in others. In others, the > cost of VFOLDER is higher. > > Consider: =2E.. > For SORT, things are a bit different, since both NOTIFY and PARTIAL > require a full set of results, but that's a different state of > affairs. Reminds me of when I implemented what became VFOLDER last autumn, except that in its case, it was a different desirable feature that imposed the cost. You may argue that if you do CONTEXTS badly, it doesn't suck quite so much as if you do VFOLDER badly. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 05:15:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAQP-00071a-Gl; Fri, 16 Jun 2006 05:15:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAQO-00071V-Rd for lemonade@ietf.org; Fri, 16 Jun 2006 05:15:32 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrAQN-0006Lv-AG for lemonade@ietf.org; Fri, 16 Jun 2006 05:15:32 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 296094AC71; Fri, 16 Jun 2006 11:15:29 +0200 (CEST) Message-Id: Date: Fri, 16 Jun 2006 11:17:16 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> <3E3A8277-3436-4C8E-8EAB-56A8DEC7EA54@mumbo.ca> In-Reply-To: <3E3A8277-3436-4C8E-8EAB-56A8DEC7EA54@mumbo.ca> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Curtis King writes: > On 16-Jun-06, at 12:39 AM, Arnt Gulbrandsen wrote: >> Curtis King writes: >>> Here are a few of the problems I have run into so far and would >>> like authors to explain what should happen. >>> >>> "For all intents and purposes, the virtual folder looks and behaves >>> like a >>> real IMAP4 folder, except that it does not contain any messages itself. " >>> >>> 1. If you delete a vmailbox, should it not remove all messages just >>> like deleting a real mailbox? If not, this needs to be in the >>> draft. >> >> It should not, which is just like a real mailbox. > > What? The last time I deleted a real mailbox it deleted all messages in it. It did not delete the same messages in another mailbox. >> Similarly, if you create INBOX.lillian vfolder as a view into INBOX >> which maps out messages from Lillian, and then delete >> INBOX.lillian, INBOX remains unaffected. No difference. > > Why isn't that true when I expunge messages in the virtual mailbox? Because my friend Abhijit and I couldn't make a useful case either way for that when we implemented this last year. We couldn't decide what was more useful - allowing expunge to work un the backing mailbox or disallowing it. It becomes a bit of a moot point when 't' is disallowed. > The mailbox metaphor doesn't work for filters. Time to move on. Aren't you proving that all the clients which implement vfolders (e.g. gnus and apple mail) are broken? I haven't heard any complaints from users of these clients. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 10:27:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFIE-0003RK-Bn; Fri, 16 Jun 2006 10:27:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFIC-0003R5-Nu for lemonade@ietf.org; Fri, 16 Jun 2006 10:27:24 -0400 Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFIB-0000us-EE for lemonade@ietf.org; Fri, 16 Jun 2006 10:27:24 -0400 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 9B5B1D6B056; Fri, 16 Jun 2006 10:27:22 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Fri, 16 Jun 2006 10:27:25 -0400 X-Sasl-enc: 9oryCRp40Pqhxu6TV2yBqdvNOgJaHL2M66xq2T2zGROL 1150468045 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id D5B7F7135; Fri, 16 Jun 2006 10:27:18 -0400 (EDT) Date: Fri, 16 Jun 2006 10:27:14 -0400 From: Cyrus Daboo To: Arnt Gulbrandsen , lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Message-ID: <1DA08A9CB37AA1737D10925A@Cyrus-Daboo.local> In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> <3E3A8277-3436-4C8E-8EAB-56A8DEC7EA54@mumbo.ca> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Arnt, --On June 16, 2006 11:17:16 AM +0200 Arnt Gulbrandsen wrote: >> The mailbox metaphor doesn't work for filters. Time to move on. > > Aren't you proving that all the clients which implement vfolders (e.g. > gnus and apple mail) are broken? I haven't heard any complaints from > users of these clients. Lets remember that most clients implementing virtual folders provide a clear visual 'cue' to the user that they are dealing with a virtual folder and not a real folder. Thus users will have some expectation that it may not behave the same way as a 'real' folder. The concern I raised in Dallas about returning virtual mailboxes in ordinary LIST applies here - users won't have a 'cue' to distinguish those from real mailboxes and thus confusion will occur. If virtual mailboxes have to be explicitly LIST'ed via LISTEXT then clients will know about them and can provide an appropriate 'cue' and different warning messages/error messages for user actions. Another issue: how do different clients know that a virtual mailbox created by another client is equivalent to one it wants to create? e.g. the case of trash: say one mobile client wants to use 'Trash' as the name, and another 'trash' (on a server with case-sensitive mailbox names). If the clients each create their own trash mailbox then that is wasteful. But the only way to know whether a virtual trash exists would be to get the underlying search expression for each virtual mailbox and compare that with the one the client wants to use for its trash. This is a case where 'context' is better as each client just uses a search of its own choosing. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 10:29:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFKU-000591-C8; Fri, 16 Jun 2006 10:29:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFKT-00058w-Qr for lemonade@ietf.org; Fri, 16 Jun 2006 10:29:45 -0400 Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFKS-0000yt-Ke for lemonade@ietf.org; Fri, 16 Jun 2006 10:29:45 -0400 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id F0D4BD6B4C5; Fri, 16 Jun 2006 10:29:43 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Fri, 16 Jun 2006 10:29:47 -0400 X-Sasl-enc: SLo9XbAiRo8wsr8uzQlQq0Y1G6axvIMfsdIui9s6Z/ms 1150468186 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 0F95F1E7B; Fri, 16 Jun 2006 10:29:45 -0400 (EDT) Date: Fri, 16 Jun 2006 10:29:41 -0400 From: Cyrus Daboo To: Arnt Gulbrandsen , lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Message-ID: <42BDBA7F119B22D77546BC87@Cyrus-Daboo.local> In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Arnt, --On June 16, 2006 8:39:40 AM +0200 Arnt Gulbrandsen wrote: >> 1. If you delete a vmailbox, should it not remove all messages just >> like deleting a real mailbox? If not, this needs to be in the draft. > > It should not, which is just like a real mailbox. If you use Sieve rules > to ensure that mail from your SO ends up in both INBOX.lillian INBOX, and > then delete INBOX.lillian, the same messages remain in INBOX. Similarly, > if you create INBOX.lillian vfolder as a view into INBOX which maps out > messages from Lillian, and then delete INBOX.lillian, INBOX remains > unaffected. No difference. Can you make sure that the VMAILBOX spec describes the interaction with SIEVE fileinto? Even if all it says is that the v-mailbox is treated exactly the same as a 'real' mailbox as far as fileinto is concerned. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 10:40:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFUq-0003eC-6p; Fri, 16 Jun 2006 10:40:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFUp-0003e7-Nd for lemonade@ietf.org; Fri, 16 Jun 2006 10:40:27 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFUo-0002fp-6D for lemonade@ietf.org; Fri, 16 Jun 2006 10:40:27 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 16 Jun 2006 15:40:19 +0100 Message-ID: <4492C2AE.1010009@isode.com> Date: Fri, 16 Jun 2006 15:39:42 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt References: <0FA975F2D8295A448BE3ADC16124465738F36E@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC16124465738F36E@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan.Ordogh@nokia.com wrote: > - Can we add more events? Like MailboxCreated (name), MailboxRenamed (name, newname), MailboxDeleted (name), MailboxMoved (name, targetmailbox)? > I am not sure what MailboxMoved means, but I agree about the rest. > - This is for 'folder' management, but there could be a lot more. > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 13:19:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrHyH-0004BQ-Ko; Fri, 16 Jun 2006 13:19:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrHyF-0004BD-Mg for lemonade@ietf.org; Fri, 16 Jun 2006 13:18:59 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrHyE-0003eI-C9 for lemonade@ietf.org; Fri, 16 Jun 2006 13:18:59 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id A1253272A7; Fri, 16 Jun 2006 11:18:57 -0600 (MDT) In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> <3E3A8277-3436-4C8E-8EAB-56A8DEC7EA54@mumbo.ca> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B68272E-7FFE-45FE-A73F-6BF2DA938A90@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Fri, 16 Jun 2006 11:18:56 -0600 To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 16-Jun-06, at 3:17 AM, Arnt Gulbrandsen wrote: > Curtis King writes: >> On 16-Jun-06, at 12:39 AM, Arnt Gulbrandsen wrote: >>> Curtis King writes: >>>> Here are a few of the problems I have run into so far and would >>>> like authors to explain what should happen. >>>> >>>> "For all intents and purposes, the virtual folder looks and >>>> behaves like a >>>> real IMAP4 folder, except that it does not contain any >>>> messages itself. " >>>> >>>> 1. If you delete a vmailbox, should it not remove all messages >>>> just like deleting a real mailbox? If not, this needs to be in >>>> the draft. >>> >>> It should not, which is just like a real mailbox. >> >> What? The last time I deleted a real mailbox it deleted all >> messages in it. > > It did not delete the same messages in another mailbox. That's my point!! Are these virtual mailboxes or not? > >>> Similarly, if you create INBOX.lillian vfolder as a view into >>> INBOX which maps out messages from Lillian, and then delete >>> INBOX.lillian, INBOX remains unaffected. No difference. >> >> Why isn't that true when I expunge messages in the virtual mailbox? > > Because my friend Abhijit and I couldn't make a useful case either > way for that when we implemented this last year. We couldn't decide > what was more useful - allowing expunge to work un the backing > mailbox or disallowing it. > > It becomes a bit of a moot point when 't' is disallowed. If VMAILBOX doesn't allow flags especially the \deleted flag to-be set, then it's not a very effective view is it. > >> The mailbox metaphor doesn't work for filters. Time to move on. > > Aren't you proving that all the clients which implement vfolders > (e.g. gnus and apple mail) are broken? I haven't heard any > complaints from users of these clients. The difference here is I know when I'm working on a virtual mailbox versus a real mailbox. Cyrus covered much better than I very could. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 16:02:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKWT-00029p-Nm; Fri, 16 Jun 2006 16:02:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr31q-0006sH-3v; Thu, 15 Jun 2006 21:21:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr1Sx-0004Tt-Ov; Thu, 15 Jun 2006 19:41:35 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fr1JO-0008Fy-NN; Thu, 15 Jun 2006 19:31:44 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5FNUZmU005784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 23:30:36 GMT Received: from mirror by ietf.org with local (Exim 4.43) id 1Fr1IJ-0002FM-T8; Thu, 15 Jun 2006 19:30:35 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Glenn Parsons , Eric Burger From: Dean Willis(OMA) Message-Id: Date: Thu, 15 Jun 2006 19:30:35 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Fri, 16 Jun 2006 15:50:47 -0400 Cc: Ted Hardie , lemonade@ietf.org, "Yaacov Weingarten \(Jerry\)" Subject: [lemonade] New Liaison Statement, "OMA LS 0113 on Mobile EMAIL to the IETF LEMONADE WG" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: OMA-LIAISON@mail.openmobilealliance.org List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Title: OMA LS 0113 on Mobile EMAIL to the IETF LEMONADE WG Submission Date: 2006-06-15 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=235 Please reply by 2006-08-21 From: Dean Willis(OMA) To: IETF Lemonade Working Group(Glenn Parsons , Eric Burger ) Cc: Ted Hardie Lisa Dusseault lemonade@ietf.org Reponse Contact: Yaacov (Jerry) Weingarten Technical Contact: Yaacov (Jerry) Weingarten Purpose: For comment Body: 1 Overview This liaison is in response to the update that was received from IETF LEMONADE 2 Proposal OMA MWG-MEM thanks IETF LEMONADE for their update of the activity within their work group. OMA MWG-MEM appreciates that there is a need to address the different notifications that need to be defined and the corresponding information that needs to be included for each of the notifications. MEM has begun to address a list of notifications that should be generated by the MEM Server for outband notification and the required information objects. MWG-MEM will interface with BAC-Push in order to update the EMN notification payload appropriately and advise IETF-LEMONADE of when such an update can be made available. Regarding presentation of the TS that is being developed in MWG-MEM for the realization of the MEM Enabler using the LEMONADE extensions, MWG-MEM will be happy to provide this through a presentation at one of your upcoming meetings, most likely the Oct interim meeting. In regards to the interoperability event that IETF is planning, MWG-MEM would be interested in receiving the results from this event. This proposal will be conveyed to our Interoperability Group (OMA-IOP). OMA organizes interoperability events based on completed and approved specifications and test descriptions that are generated from the TS and their accompanying SCR tables. It is our opinion that the results of such an IETF interoperability would be helpful in identifying the parts of the MEM LEMONADE realization that would need additional IOP testing as part of the OMA Test Fests. OMA MWG-MEM will hold its next meeting on 21-23 Aug in Beijing, China 3 Requested Action(s) We request the IETF LEMONADE Working Group to consider this information. 4 Conclusion OMA MWG-MEM SWG wishes to thank the IETF LEMONADE WG for its update liaison. OMA MWG-MEM looks forward to continued collaboration with the IETF LEMONADE WG. Finally, OMA MWG-MEM wishes to thank the IETF LEMONADE WG for its kind consideration of this liaison. Attachment(s): Liaison Statement in Original Microsoft Word .DOC format (https://datatracker.ietf.org/documents/LIAISON/file327.doc) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 16:16:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKk3-0006PR-Nt; Fri, 16 Jun 2006 16:16:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKk3-0006PM-EF for lemonade@ietf.org; Fri, 16 Jun 2006 16:16:31 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrKk2-0004f7-SU for lemonade@ietf.org; Fri, 16 Jun 2006 16:16:31 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5GKGPu3028007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jun 2006 13:16:26 -0700 Received: from [192.168.1.13] (vpn-10-50-0-117.qualcomm.com [10.50.0.117]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5GKGKmD025573; Fri, 16 Jun 2006 13:16:24 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 16 Jun 2006 13:16:14 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:26 PM +0200 6/15/06, Arnt Gulbrandsen wrote: > Curtis King writes: >> On 14-Jun-06, at 9:14 AM, Arnt Gulbrandsen wrote: >>> In the server's RAM, CONTEXTS and VFOLDER seem to be the same. In >>> both cases, the server keeps track of modsequences and updates >>> UID sets in RAM. For CONTEXTS, it's one UID set, for VFOLDER, >>> it's two UID sets and a mailbox name. >>> >>> In VFOLDER, all that information is stored persistently on the >>> server. In CONTEXTS, parts of it is stored on the client, and >>> parts may not be stored at all, but instead recomputed. >>> >>> If the client uses CONDSTORE and stores the result sets >>> persistently, performance at session start time is essentially >>> the same for the two. If the client doesn't use CONDSTORE, or if >>> it issues SEARCHes for all contexts when it SELECTs the backing >>> mailbox, the server groans under the load. >> >> I would hate to create VMAILBOX on such a server ;) An index is an >> index the cost will be same, except with CONTEXT there will be 1 >> less for each "view". > > I don't see that. The work required to update the index differs > substantially. > > Take the case where a user read INBOX by mostly partitioning it > into fifteen groups: Ten specific to a mailing list (SEARCH HEADER > "List-ID" "lemonade.ietf.org" etc), one which catches other mailing > lists, one which catches messages with the $Junk flag set, one > which catches messages to/from the user's personal address, one > which catches work mail (based on From/To domain), and one for the > rest. Perfectly plausible. Just so I have some numbers, I'll say > that the inbox contains 35,000 messages, of which 150 have been > delivered since last time I read mail. (If you think 35,000 is a > lot, use gmail for a while, it'll change your mind.) > > There are four costs to consider, at least that I can think of. > > 1. The amount of persistent storage required on the server. For > VFOLDER, that's 15 sets of UID pairs, 15 mailbox names, 15 ACLs, > etc. For CONTEXTS, nothing. Agreed? Plus, for VMAILBOX, the search criteria and backing mailbox name (unless that's what you meant by "mailbox name"). For CONTEXTs, if the server stores nothing that the entire CONTEXT needs to be recomputing for each use. The draft suggested that servers might use the client hint to store or at least cache some of this. > 2. Ditto on the client(s). For VFOLDER, nothing needs be stored. > For CONTEXTS, the client must to store the search expression. If > the client also stores the matching UID set and its highest modseq, > that benefits the server greatly (but makes little difference to > the client). It would make a difference to the client if it needs to send more data and wait longer to get the results. > 3. The amount of CPU/whatever required to start a session (SELECT > or equivalent). For VFOLDER, the server must consider 150 messages > every time the client SELECTs a VFOLDER. For CONTEXTS, the client > affects that. In the lowest-server-load case, the client enables > just one CONTEXT at a time and uses CONDSTORE optimally, so the > server needs to consider 150 messages each time the client switches > context. In the worst case, the client enables all 15 contexts > after issuing SELECT INBOX and does not use CONDSTORE, and the > server has to consider each of the 35,000 messages 15 times. I > suspect that a good client author such as Dave will enable most/all > of the 15 and use CONDSTORE, so the server has to process each of > 150 messages 15 times. > > 4. The amount of CPU/whatever required when a message is injected > into a mailbox and a client is looking at that mailbox. For > VFOLDER, the server needs to consider whether the message matches > either zero or one search expression(s): Zero if the client has > INBOX selected, one if the client has one of the VFOLDERs selected. > For CONTEXTS, it needs to consider as many search expressions as > the client has enabled, 0-15. So, for VMAILBOX, every time a message in added to the backing mailbox, instead of the server comparing it against the search criteria for each VMAILBOX, it only needs to compare against any currently SELECTed VMAILBOxes that use the backing mailbox. Likewise, whenever a VMAILBOX is SELECTed, the server must compare the previous highest UID of the compared messages in the backing mailbox, and if new messages arrived in the backing mailbox, compare those. So the server needs to maintain a link from each mailbox to all VMAILBOXes that use that mailbox (which it needs to do anyway in order to handle mailbox renames or deletes). > For three of these, IMO the two are nearly the same, and for one, > VFOLDER wins by a significant margin. Depending on what's expensive > in your architecture, your conclusion may be different. > >> The performance issue is listing of all the mailboxes and >> vmailboxes, more so with clients than servers. This is one >> biggest problems with some existing clients today, vmailboxes >> will make the situation worst. > > True. I disregarded this because I think LIST * is already a form > of suicide. One might as well be hanged for a sheep as for a lamb. > >>> For CONTEXTS, there is a nice fallback to working with stock IMAP >>> servers. For VFOLDER, there is none. >>> >>> For CONTEXTS, two clients don't stay in sync, unless the clients >>> share state in some way outside the extension. VFOLDER works with >>> vanilla and extended IMAP clients. >> >> What? Clients stay in sync using existing IMAP mechanisms. > > How does this work? It's not clear to me from the draft. Take the > case where I read mail using my mobile device milonga and my office > machine libertango. When I create, modify or delete a context on > milonga, how does libertango learn about change context? This goes to the use cases for virtual mailboxes, I think. It may or may not make sense to want to share them between clients. If virtual mailboxes are used in lieu of server-based filtering, so that incoming mail for, say, mailing lists, personal mail versus work mail, etc. are all in INBOX instead of in individual mailboxes, then it does make sense to share them between clients. If instead virtual mailboxes are used to create subsets of already-filtered mail so that limited-capacity mobile devices don't see low-priority messages, then it may not make sense to share them, since the criteria for "interesting" and low-priority may differ on each device. > So far, IMAP clients tend not to use SEARCH at all, but instead > FETCH 1:* RFC822 and do the searching on the client. I've seen a > mobile client written by people I personally know and respect do > that. It takes some faith to assume that the average mobile client > will begin to use SEARCH+CONDSTORE+CONTEXTS optimally. Or, we need to understand why current desktop clients do it that way. Off the top of my head, two possible factors are: clients were written originally for POP and are used to doing their own searching, and history of poor search performance on servers (I've certainly experienced the pain of this). If, because of resource constraints, mobile clients are more likely to rely on SEARCH, then we should help that, and provide guidance to client and server developers, especially if this expected usage differs from current practice. > Instead of trusting implementers generally, I'd prefer to design > the extension so that if a server implementation sucks, the pain is > mostly on the server admin's side, and that if a client > implementation sucks, the pain is mostly on the user's side. That makes sense. > >> I prefer instead to give the client developers more tools to make >> better clients with. One problem when developing clients is the >> most you can expect a server to support is RFC3501 until now. >> LEMONADE sets a new standard which clients can expect from most >> major servers. I think most active desktop clients will start to >> use the tools set the by LEMONADE profile. > > I'll accept that if you can get a Microsoft person to step forward > and say "Outlook and Outlook Express will be updated to use > LEMONADE". By that reasoning we may as well all go home, on the assumption that Microsoft will own the mobile as well as the desktop client and server environments. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I have made it a rule, whenever in my power, to avoid becoming the draughtsman of papers to be reviewed by a public body. --Benjamin Franklin _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 17:05:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrLVm-0002vq-W5; Fri, 16 Jun 2006 17:05:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrLVm-0002vh-8V for lemonade@ietf.org; Fri, 16 Jun 2006 17:05:50 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrLVk-0003Np-V9 for lemonade@ietf.org; Fri, 16 Jun 2006 17:05:50 -0400 Received: from [209.89.70.52] (tribeca.mumbo.ca [209.89.70.52]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 7DA7C272A7; Fri, 16 Jun 2006 15:05:48 -0600 (MDT) In-Reply-To: <1DA08A9CB37AA1737D10925A@Cyrus-Daboo.local> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> <3E3A8277-3436-4C8E-8EAB-56A8DEC7EA54@mumbo.ca> <1DA08A9CB37AA1737D10925A@Cyrus-Daboo.local> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Fri, 16 Jun 2006 15:05:47 -0600 To: Cyrus Daboo X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: lemonade@ietf.org, Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 16-Jun-06, at 8:27 AM, Cyrus Daboo wrote: > Another issue: how do different clients know that a virtual mailbox > created by another client is equivalent to one it wants to create? > e.g. the case of trash: say one mobile client wants to use 'Trash' > as the name, and another 'trash' (on a server with case-sensitive > mailbox names). If the clients each create their own trash mailbox > then that is wasteful. But the only way to know whether a virtual > trash exists would be to get the underlying search expression for > each virtual mailbox and compare that with the one the client wants > to use for its trash. This is a case where 'context' is better as > each client just uses a search of its own choosing. This is a big advantage for CONTEXT on the server side as the server can use the same underlying index for the same search criteria no mater what name the client gives it. You can do this for VMAILBOX as well, but you still need to track names and UIDs, etc, no matter if dynamic content is allowed or not. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 18:04:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMQz-0002HA-DG; Fri, 16 Jun 2006 18:04:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMQy-0002Gz-2C for lemonade@ietf.org; Fri, 16 Jun 2006 18:04:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrL4F-00074n-2f for lemonade@ietf.org; Fri, 16 Jun 2006 16:37:23 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FrKfq-0000IW-2g for lemonade@ietf.org; Fri, 16 Jun 2006 16:12:12 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5GKC8cK018975; Fri, 16 Jun 2006 13:12:08 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5GKC8mt022027 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Jun 2006 13:12:08 -0700 Date: Fri, 16 Jun 2006 13:12:10 -0700 (Pacific Daylight Time) From: Mark Crispin To: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt In-Reply-To: Message-ID: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NAME_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -2.6 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 15 Jun 2006, Curtis King wrote: >> So, are you saying that there are clients that walk the entire tree using % >> just to avoid doing a *? Unbelievable. > It's even worst than that they also issue a status for each new mailbox they > find. This is a lesson to never underestimate the determination of individuals to do the wrong thing, no matter what measures are undertaken to prevent it. >> I can see a client doing "LIST %", followed by "LIST %/%" if the server >> does not advertise CHILDREN and needs to know that. But any further tree >> prowling should be deferred until the user actually looks in a name that >> has inferiors. > You would think that's the obvious solution. Sadly, I think that the number of people who think that they can design software greatly outnumbers those who actually can. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 18:11:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMX7-0006Bx-4G; Fri, 16 Jun 2006 18:11:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMX6-0006Bj-2R for lemonade@ietf.org; Fri, 16 Jun 2006 18:11:16 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrMX4-0000f5-MW for lemonade@ietf.org; Fri, 16 Jun 2006 18:11:16 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5GMBBtX007604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jun 2006 15:11:11 -0700 Received: from [192.168.1.13] (vpn-10-50-0-117.qualcomm.com [10.50.0.117]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5GMB92s005200; Fri, 16 Jun 2006 15:11:10 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <32502.1150381246.957176@peirce.dave.cridland.net> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <32502.1150381246.957176@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 16 Jun 2006 15:08:29 -0700 To: Dave Cridland , Enhancements to Internet email to support diverse service enivronments From: Randall Gellens Subject: Re: [lemonade] Contexts Implementation Issues. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 3:20 PM +0100 6/15/06, Dave Cridland wrote: > CONTEXTS does not mandate any persistent storage, but equally does > not mandate against it. Typically, I'd expect the server to have > built indices, so for sake of argument you're looking at - perhaps > - 15 sets of UIDs. The wire-level efficiency is the same whatever > is stored on the server. > > This contrasts with VFOLDER, since unless you effectively make it > into a real mailbox with shared content, and persist UIDs, the wire > efficiency of the protocol will suffer greatly. With VFOLDER the UIDs of messages selected by the criteria remain constant unless the message goes out of view and comes back (or the UIDVALIDITY of the backing mailbox changes). How does the wire efficiency (by which I assume you mean the amount of data that must be sloshed either way) differ? >> 2. Ditto on the client(s). For VFOLDER, nothing needs be stored. >> For CONTEXTS, the client must to store the search expression. If >> the client also stores the matching UID set and its highest >> modseq, that benefits the server greatly (but makes little >> difference to the client). >> > For VFOLDER on a client, a substantial amount of data must be > stored for effective use, but nothing needs to be. I assume the client would likely store the VMAILBOX cache, just as it would for a real mailbox, plus UIDNEXT, UIDVALIDITY, and the highest MODSEQ (also just as it would for a real maibox)? > For CONTEXTS on the client, the search criteria need to be available. > > The client can persist result sets, of course, and this not only > makes a difference to the server, but to the client, too, because > it affects wire efficiency. Here the client stores the UID set of matching messages and the highest MODSEQ? >> 3. The amount of CPU/whatever required to start a session (SELECT >> or equivalent). For VFOLDER, the server must consider 150 messages >> every time the client SELECTs a VFOLDER. For CONTEXTS, the client >> affects that. In the lowest-server-load case, the client enables >> just one CONTEXT at a time and uses CONDSTORE optimally, so the >> server needs to consider 150 messages each time the client >> switches context. In the worst case, the client enables all 15 >> contexts after issuing SELECT INBOX and does not use CONDSTORE, >> and the server has to consider each of the 35,000 messages 15 >> times. I suspect that a good client author such as Dave will >> enable most/all of the 15 and use CONDSTORE, so the server has to >> process each of 150 messages 15 times. >> >> > To begin with, you're still considering all 35,000 messages - it's > simply that you're using a MODSEQ index to first-cut the search > range. So only messages which have changed since the MODSEQ are considered? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Finagle's Second Law: No matter what the anticipated result, there will always be someone eager to (a) misinterpret it, (b) fake it, or (c) believe it happened according to his own pet theory. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 18:11:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMX8-0006Da-Cx; Fri, 16 Jun 2006 18:11:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMX7-0006DB-Lp for lemonade@ietf.org; Fri, 16 Jun 2006 18:11:17 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrMX6-0000fG-AU for lemonade@ietf.org; Fri, 16 Jun 2006 18:11:17 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5GMBD7T007611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jun 2006 15:11:14 -0700 Received: from [192.168.1.13] (vpn-10-50-0-117.qualcomm.com [10.50.0.117]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5GMB92u005200; Fri, 16 Jun 2006 15:11:12 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 16 Jun 2006 15:10:07 -0700 To: Mark Crispin From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 8:01 AM -0700 6/15/06, Mark Crispin wrote: >> One problem when developing clients is the most you can expect a >> server to support is RFC3501 until now. LEMONADE sets a new >> standard which clients can expect from most major servers. I think >> most active desktop clients will start to use the tools set the by >> LEMONADE profile. > > I, on the other hand, hope that this does not happen. Why is that? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Note that although IBM 'invented' virtual memory in 1972 it had been available in a multi-processor multi-tasking environment on the B5000 line since 1963 and the B6000 line since 1968. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 18:26:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMm4-0005rY-E8; Fri, 16 Jun 2006 18:26:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMm3-0005rO-NW for lemonade@ietf.org; Fri, 16 Jun 2006 18:26:43 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrMm2-0002rB-C8 for lemonade@ietf.org; Fri, 16 Jun 2006 18:26:43 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5GMQfpt016192; Fri, 16 Jun 2006 15:26:41 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5GMQfgd018718 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Jun 2006 15:26:41 -0700 Date: Fri, 16 Jun 2006 15:26:43 -0700 (Pacific Daylight Time) From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt In-Reply-To: Message-ID: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri, 16 Jun 2006, Randall Gellens wrote: >>> One problem when developing clients is the most you can expect a server >>> to support is RFC3501 until now. LEMONADE sets a new standard which >>> clients can expect from most major servers. I think most active desktop >>> clients will start to use the tools set the by LEMONADE profile. >> I, on the other hand, hope that this does not happen. > Why is that? It would have the effect of making an already extraordinarily-complex mandatory minimum-to-implement for IMAP even more complex. I do not believe that it is a good thing to raise the bar to implement IMAP or to offer IMAP on existing mail stores. The Lemonade extensions, while undeniably valuable to mobile clients, are of much less importance to desktop clients. We should not encourage the (further) proliferation of desktop clients which do not work with servers that do not offer a particular extension. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 19:11:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrNTH-00026H-5t; Fri, 16 Jun 2006 19:11:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrNTF-00022X-HZ for lemonade@ietf.org; Fri, 16 Jun 2006 19:11:21 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrNTE-0000BT-69 for lemonade@ietf.org; Fri, 16 Jun 2006 19:11:21 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5GNBI7S018756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jun 2006 16:11:19 -0700 Received: from [192.168.1.13] (vpn-10-50-0-117.qualcomm.com [10.50.0.117]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5GNBBD4029326; Fri, 16 Jun 2006 16:11:16 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <2753C43F-FA4A-487B-8834-3650FC05A51E@osafoundation.org> References: <4486CC85.80400@isode.com> <7ED1AE38-5BA6-4100-B072-07B1397C8E95@osafoundation.org> <2753C43F-FA4A-487B-8834-3650FC05A51E@osafoundation.org> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 16 Jun 2006 16:11:00 -0700 To: Lisa Dusseault From: Randall Gellens Subject: Re: [lemonade] Notifications for multiple devices per user Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Lemonade WG , Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 10:15 AM -0700 6/15/06, Lisa Dusseault wrote: >> At 4:40 PM -0700 6/9/06, Lisa Dusseault wrote: >> >>> There's an alternative architecture for the same use case, and >>> that's to let the notification server (SIP or XMPP, in >>> particular) do fanout. Then the IMAP server simply sends the >>> notification to the user's notification address (plus some >>> application field if specified) and the user decides which >>> devices subscribe to those notifications. > It's easier for the device to simply to subscribe, or no, to some > address to which notifications are sent (not nonstop but whenever > there's a receiver) according to a previously configured script or > rule. I apologize if this was covered in a draft that I missed, but I'd like to understand this better. So Sieve would be used to test messages, and generate notification events as appropriate. If you had, say, progressively more restrictive filter criteria, the Sieve script would contain tests for each set. The Sieve script could be written such that it did the most restrictive (fewest notifications) tests first, in the equivalent of a deep IF-THEN-ELSEIF, and therefore at most one notification would be generated per message. Or, the Sieve script could be written such that it did all tests against all messages, and therefore might generate multiple notifications per message. Notifications generated by the Sieve script would be have an identifier that looked like an IM address, and be published to something that looked like an IM server. In the case of progressively more restrictive filter criteria, each would have its own address. For example, 'randy.urgent-messages@jabber.example.org', 'randy.interesting-messages@jabber.example.org', etc. Devices would subscribe to the notifications using the identifier. How does the Sieve script get created and updated? Which device does this, and how much knowledge does it need about the others? How is the Sieve script or engine configured to send notifications to the addresses? How do devices learn which notification identifier they need to subscribe to? Note that I think these questions apply generally to any out of band notification mechanism. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- In America, anyone can become president. That's one of the risks you take. --Adlai Stevenson _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 19:28:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrNjf-0006Ib-L5; Fri, 16 Jun 2006 19:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrNje-0006IT-GF for lemonade@ietf.org; Fri, 16 Jun 2006 19:28:18 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrNjd-0000zH-67 for lemonade@ietf.org; Fri, 16 Jun 2006 19:28:18 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5GNSBEZ020068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jun 2006 16:28:12 -0700 Received: from [192.168.1.13] (vpn-10-50-0-117.qualcomm.com [10.50.0.117]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5GNS8Z7003763; Fri, 16 Jun 2006 16:28:10 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4491AB88.4060100@pathbreaker.com> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> <4491AB88.4060100@pathbreaker.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 16 Jun 2006 16:25:31 -0700 To: Ray Cromwell , Curtis King From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: lemonade@ietf.org, Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:48 AM -0700 6/15/06, Ray Cromwell wrote: > I think this entire thread is predicated on the assumption that > VMAILBOX mandates that servers must allow search criteria on > dynamic attributes or criteria that create the need to assign new > UIDs. The original VFOLDER proposal did not have this feature and > we have not decided whether or not this feature is necessary for > VFOLDERs or if it will be included in the final spec. It was made > optional in the latest VFOLDER draft (adopted from Arnt's VIEW > proposal) precisely so that a) we can have a discussion about the > costs of implementing and b) some people could choose not to > implement it. It can't be optional unless it isn't essential. To know if it is needed, we need to know how VMAILBOXes would be used. Obviously, we can't anticipate every possible use. But if we knew more clearly which problems we were trying to solve and (perhaps more importantly) which we aren't, we could narrow things down, I think. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I employ no person who smokes. --- Thomas Edison [Handwritten note by Edison to Henry Ford, April 26, 1914 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 20:17:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrOVe-0003U6-0Q; Fri, 16 Jun 2006 20:17:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrOVc-0003Tu-DE for lemonade@ietf.org; Fri, 16 Jun 2006 20:17:52 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrOVb-0006u8-2Q for lemonade@ietf.org; Fri, 16 Jun 2006 20:17:52 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5H0Hioa018482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jun 2006 17:17:45 -0700 Received: from [192.168.1.13] (vpn-10-50-0-117.qualcomm.com [10.50.0.117]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5H0HV9R008207; Fri, 16 Jun 2006 17:17:42 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 16 Jun 2006 17:17:22 -0700 To: Mark Crispin , Arnt Gulbrandsen From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 12:32 PM -0700 6/15/06, Mark Crispin wrote: > On Thu, 15 Jun 2006, Arnt Gulbrandsen wrote: >>> I haven't seen clients do LIST * for long time. Clients trying to >>> discover the whole mailbox hierarchy at every startup using LIST "" >>> %, LIST "" foo/% which have the performance problems. In some cases >>> issuing LIST * would be better than their existing behavior ;) >> OK, OK, I should have said "LIST * or the equivalent series of LIST >> ...%... commands". > > So, are you saying that there are clients that walk the entire tree > using % just to avoid doing a *? Unbelievable. > > The whole point of "LIST * is harmful" is that walking the entire > tree is harmful. > > I can see a client doing "LIST %", followed by "LIST %/%" if the > server does not advertise CHILDREN and needs to know that. But any > further tree prowling should be deferred until the user actually > looks in a name that has inferiors. I believe Mac Eudora only fetches the mailbox tree (or even the top level of the mailbox hierarchy) on request (by the user selecting "Refresh mailbox list"). In which case it does make sense to walk the entire tree. I assume the idea is that mailbox creation/deletion/renaming by other clients is infrequent enough that when it does happen the user can tell the client to go update the list. Probably, a conclusion of this discussion is that we need better guidance for developers. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Heuristics are bug ridden by definition. If they didn't have bugs, then they'd be algorithms. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 21:24:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrPYH-0007HD-De; Fri, 16 Jun 2006 21:24:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrPYG-0007H8-Tg for lemonade@ietf.org; Fri, 16 Jun 2006 21:24:40 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrPYF-0003No-JC for lemonade@ietf.org; Fri, 16 Jun 2006 21:24:40 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5H1OZjd028123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jun 2006 18:24:35 -0700 Received: from [192.168.1.13] (vpn-10-50-0-117.qualcomm.com [10.50.0.117]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5H1OQh5023336; Fri, 16 Jun 2006 18:24:29 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <69A8533D-F578-43D0-8C3D-2D9B89FB9834@mumbo.ca> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> <4491AB88.4060100@pathbreaker.com> <69A8533D-F578-43D0-8C3D-2D9B89FB9834@mumbo.ca> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 16 Jun 2006 18:24:12 -0700 To: Curtis King , Ray Cromwell From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org, Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:53 PM -0600 6/15/06, Curtis King wrote: > On my mobile client I only want to see unread messages 90% of the time. So your mobile client shows you a list of unread messages. You pick one and read it. Does it then vanish from the mobile device? I'd think that it would be confusing and frustrating if it immediately vanished, but people probably would like it to to vanish from the mobile device at some point. People are also likely to try and delete the message from the local device only if it doesn't go away when they are through with it. I'm not sure when it should vanish just from having been read, but I think it needs to be under explicit client control. Is doing a FETCH without PEEK is the right trigger for it to vanish? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Life is ... a shopping mall ... where items such as worldly success, love of music, a strong backhand, close relationships with your family, a few good friends and countless other things are on sale. The commodity with which they are purchased is not money, but time. --William Rehnquist _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 21:34:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrPhe-0005yO-OD; Fri, 16 Jun 2006 21:34:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrPhd-0005yJ-TY for lemonade@ietf.org; Fri, 16 Jun 2006 21:34:21 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrPhc-0004SB-Id for lemonade@ietf.org; Fri, 16 Jun 2006 21:34:21 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5H1YIIW029130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jun 2006 18:34:19 -0700 Received: from [192.168.1.13] (vpn-10-50-0-117.qualcomm.com [10.50.0.117]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5H1YDjF023097; Fri, 16 Jun 2006 18:34:16 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 16 Jun 2006 18:30:34 -0700 To: Curtis King , Chris Newman From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 2:19 PM -0600 6/15/06, Curtis King wrote: > The longer the discussion goes on, the more I think we need ACAP > light or IMSP. There has been discussion in the past about a rev of the ACAP spec that would make it easier to implement on servers. As I recall, one key point was to not require all three of contexts, inheritance, and ACL on items. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Premature optimization is the root of all evil --C. A. R. Hoare _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 16 21:41:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrPoM-0003gK-Va; Fri, 16 Jun 2006 21:41:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrPoL-0003et-MY for lemonade@ietf.org; Fri, 16 Jun 2006 21:41:17 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrPoK-0005jT-Az for lemonade@ietf.org; Fri, 16 Jun 2006 21:41:17 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5H1fEx4029467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jun 2006 18:41:15 -0700 Received: from [192.168.1.13] (vpn-10-50-0-117.qualcomm.com [10.50.0.117]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5H1f9m5013321; Fri, 16 Jun 2006 18:41:12 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 16 Jun 2006 18:39:16 -0700 To: Curtis King From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:46 PM -0600 6/15/06, Curtis King wrote: > Here are a few of the problems I have run into so far and would > like authors to explain what should happen. I'm not an author of the draft but have a few comments. > > "For all intents and purposes, the virtual folder looks and behaves like a > real IMAP4 folder, except that it does not contain any messages itself. " > > 1. If you delete a vmailbox, should it not remove all messages just > like deleting a real mailbox? If not, this needs to be in the draft. I'd expect not, but I agree we need to be clear on what happens. > 2. Expunging messages and the interaction between clients. The > mobile client uses vmailbox for trash based on a message being > marked \deleted. Now when I access the backing mailbox using a > desktop client which does a SELECT and a CLOSE. All \deleted > messages with be expunged and now on my mobile client it will look > like my trash was magically emptied. Have fun figuring out that bug > report ;) Isn't this the same as a second client expunging messages from any mailbox? > > 3. " The EXPUNGE Command (RFC 3501 section 6.4.3) causes the underlying > mailbox to be expunged when a view is expunged. Servers SHOULD > expunge only the messages visible in the view, or MAY expunge the > entire mailbox. The former is more desirable, if possible. " > > I have great mobile client which has this great option to show only > unread messages which it does by creating a vmailbox. Now, I go > back to my desktop and find a new mailbox which I don't remember > creating and it has a bunch duplicate messages from my INBOX. I > will just delete this junk mailbox using my desktop client, which > does moves all messages to "Deleted Messages", then marks them > \deleted and expunges. Hey where did all my new messages go? With > the MAY expunge entire mailbox clause, there might even be more > messages expunged before the client expects it. This is more serious, IMHO. A second client could 'accidently' delete messages in this way. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Did you know... That no one ever reads these things? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Jun 17 00:19:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrSH5-0004kN-0Q; Sat, 17 Jun 2006 00:19:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrSH4-0004kI-81 for lemonade@ietf.org; Sat, 17 Jun 2006 00:19:06 -0400 Received: from brooklyn.mumbo.ca ([209.89.70.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrSH2-0004pR-Ts for lemonade@ietf.org; Sat, 17 Jun 2006 00:19:06 -0400 Received: from [192.168.0.102] (d198-53-122-114.abhsia.telus.net [198.53.122.114]) by brooklyn.mumbo.ca (Postfix) with ESMTP id 36F1A272A7; Fri, 16 Jun 2006 22:19:02 -0600 (MDT) In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Date: Fri, 16 Jun 2006 22:18:55 -0600 To: Randall Gellens X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On 16-Jun-06, at 7:39 PM, Randall Gellens wrote: > At 1:46 PM -0600 6/15/06, Curtis King wrote: > >> Here are a few of the problems I have run into so far and would >> like authors to explain what should happen. > > I'm not an author of the draft but have a few comments. Of course the more comments the better. > >> 2. Expunging messages and the interaction between clients. The >> mobile client uses vmailbox for trash based on a message being >> marked \deleted. Now when I access the backing mailbox using a >> desktop client which does a SELECT and a CLOSE. All \deleted >> messages with be expunged and now on my mobile client it will look >> like my trash was magically emptied. Have fun figuring out that >> bug report ;) > > Isn't this the same as a second client expunging messages from any > mailbox? True, but it still might be confusing to end users. Yes? > >> >> 3. " The EXPUNGE Command (RFC 3501 section 6.4.3) causes the >> underlying >> mailbox to be expunged when a view is expunged. Servers SHOULD >> expunge only the messages visible in the view, or MAY expunge the >> entire mailbox. The former is more desirable, if possible. " >> >> I have great mobile client which has this great option to show >> only unread messages which it does by creating a vmailbox. Now, I >> go back to my desktop and find a new mailbox which I don't >> remember creating and it has a bunch duplicate messages from my >> INBOX. I will just delete this junk mailbox using my desktop >> client, which does moves all messages to "Deleted Messages", then >> marks them \deleted and expunges. Hey where did all my new >> messages go? With the MAY expunge entire mailbox clause, there >> might even be more messages expunged before the client expects it. > > This is more serious, IMHO. A second client could 'accidently' > delete messages in this way. yes. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Jun 17 06:50:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrYO4-0006xt-25; Sat, 17 Jun 2006 06:50:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrYO2-0006qF-9E for lemonade@ietf.org; Sat, 17 Jun 2006 06:50:42 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrYO0-0005bb-QY for lemonade@ietf.org; Sat, 17 Jun 2006 06:50:42 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id BAA094ACCC for ; Sat, 17 Jun 2006 12:50:39 +0200 (CEST) Message-Id: Date: Sat, 17 Jun 2006 12:50:39 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> <3E3A8277-3436-4C8E-8EAB-56A8DEC7EA54@mumbo.ca> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt Gulbrandsen writes: > Curtis King writes: >> On 16-Jun-06, at 12:39 AM, Arnt Gulbrandsen wrote: >>> Similarly, if you create INBOX.lillian vfolder as a view into INBOX >>> which maps out messages from Lillian, and then delete >>> INBOX.lillian, INBOX remains unaffected. No difference. >> >> Why isn't that true when I expunge messages in the virtual mailbox? > > Because my friend Abhijit and I couldn't make a useful case either way > for that when we implemented this last year. We couldn't decide what > was more useful - allowing expunge to work un the backing mailbox or > disallowing it. > > It becomes a bit of a moot point when 't' is disallowed. But of course 't' must be allowed. I clearly wasn't thinking when I wrote that. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Jun 17 08:37:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fra3W-0006dY-TD; Sat, 17 Jun 2006 08:37:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fra3V-0006dT-VP for lemonade@ietf.org; Sat, 17 Jun 2006 08:37:37 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fra3S-0003C6-Dz for lemonade@ietf.org; Sat, 17 Jun 2006 08:37:37 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E26654AC7D; Sat, 17 Jun 2006 14:37:32 +0200 (CEST) Message-Id: Date: Sat, 17 Jun 2006 14:37:33 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens writes: > At 1:26 PM +0200 6/15/06, Arnt Gulbrandsen wrote: >> Curtis King writes: >>> I prefer instead to give the client developers more tools to make >>> better clients with. One problem when developing clients is the >>> most you can expect a server to support is RFC3501 until now. >>> LEMONADE sets a new standard which clients can expect from most >>> major servers. I think most active desktop clients will start to >>> use the tools set the by LEMONADE profile. >> >> I'll accept that if you can get a Microsoft person to step forward >> and say "Outlook and Outlook Express will be updated to use >> LEMONADE". > > By that reasoning we may as well all go home, on the assumption that > Microsoft will own the mobile as well as the desktop client and > server environments. I'd rather not step overboard, neither to port nor to starboard. I think that Lemonade will take hold in the mobile email world. I also think that people will continue to use regular clients, even as they begin to use mobile devices. I conclude that Lemonade had better maintain some compatibility: Lemonade should affect the relationship between mobile client and server, not that between sometimes mobile user and mail. (More answers to this message and others later, perhaps Monday, but I think I've almost had my say. Right or wrong, I'll stop talking about this soon. Better not repeat myself more than twice.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Jun 17 16:29:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrhPf-0007Ma-Hu; Sat, 17 Jun 2006 16:28:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrhPE-0007HG-SC for lemonade@ietf.org; Sat, 17 Jun 2006 16:28:32 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrhGr-0004t2-MO for lemonade@ietf.org; Sat, 17 Jun 2006 16:19:54 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FrhGq-0003XH-R3; Sat, 17 Jun 2006 20:19:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 116E3498002; Sat, 17 Jun 2006 21:19:52 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05237-04; Sat, 17 Jun 2006 21:19:42 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 195C2498003; Sat, 17 Jun 2006 21:19:42 +0100 (BST) Date: Sat, 17 Jun 2006 21:19:42 +0100 Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <4490FC6F.1050500@pathbreaker.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <6187.1150575582.212480@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri Jun 16 01:17:40 2006, Randall Gellens wrote: > In Dave's reply, he suggested that, in the case of (2), that it > wasn't a problem if clients got notifications of state changes for > all messages in a mailbox, even those outside the subset of those > that were "interesting": Yes, that's what I intended to convey. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Jun 17 16:39:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrhaJ-0005mD-N1; Sat, 17 Jun 2006 16:39:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrhaI-0005m7-SD for lemonade@ietf.org; Sat, 17 Jun 2006 16:39:58 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrhaH-0006Y5-CM for lemonade@ietf.org; Sat, 17 Jun 2006 16:39:58 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FrhaG-0002Nb-1q; Sat, 17 Jun 2006 20:39:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 152FE498003; Sat, 17 Jun 2006 21:39:56 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05726-08; Sat, 17 Jun 2006 21:39:52 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 82D34498002; Sat, 17 Jun 2006 21:39:52 +0100 (BST) Date: Sat, 17 Jun 2006 21:39:52 +0100 Subject: Re: [lemonade] Contexts Implementation Issues. References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <32502.1150381246.957176@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <6187.1150576792.237741@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri Jun 16 23:08:29 2006, Randall Gellens wrote: > At 3:20 PM +0100 6/15/06, Dave Cridland wrote: > >> CONTEXTS does not mandate any persistent storage, but equally >> does not mandate against it. Typically, I'd expect the server to >> have built indices, so for sake of argument you're looking at - >> perhaps - 15 sets of UIDs. The wire-level efficiency is the same >> whatever is stored on the server. >> >> This contrasts with VFOLDER, since unless you effectively make it >> into a real mailbox with shared content, and persist UIDs, the >> wire efficiency of the protocol will suffer greatly. > > With VFOLDER the UIDs of messages selected by the criteria remain > constant unless the message goes out of view and comes back (or the > UIDVALIDITY of the backing mailbox changes). How does the wire > efficiency (by which I assume you mean the amount of data that must > be sloshed either way) differ? > > Because (as Curtis said a while back) it means that VFOLDER mandates persistent storage, to ensure those UIDs don't change. If the index isn't persisted (or is lost), then the client's cache is rendered worthless, and the mailbox data will end up being sloshed (great word!) down the wire (which is, of course, a virtual one). >>> 2. Ditto on the client(s). For VFOLDER, nothing needs be stored. >>> For CONTEXTS, the client must to store the search expression. If >>> the client also stores the matching UID set and its highest >>> modseq, that benefits the server greatly (but makes little >>> difference to the client). >>> >> For VFOLDER on a client, a substantial amount of data must be >> stored for effective use, but nothing needs to be. > > I assume the client would likely store the VMAILBOX cache, just as > it would for a real mailbox, plus UIDNEXT, UIDVALIDITY, and the > highest MODSEQ (also just as it would for a real maibox)? > > Yes, but if it fails to do so, the data isn't lost, although it needs refetching. >> For CONTEXTS on the client, the search criteria need to be >> available. >> >> The client can persist result sets, of course, and this not only >> makes a difference to the server, but to the client, too, because >> it affects wire efficiency. > > Here the client stores the UID set of matching messages and the > highest MODSEQ? > > That, as they say, is a good question. I need to look at what the client needs to store, the complexity of doing so, and the bandwidth saved by doing so. >> To begin with, you're still considering all 35,000 messages - >> it's simply that you're using a MODSEQ index to first-cut the >> search range. > > So only messages which have changed since the MODSEQ are considered? In Arnt's scenario, on a re-select or re-acquisition of a context, there are 35,000 messages considered. The most efficient, and obvious, method for cutting down the server's workload is to not consider adding or removing any messages which have not changed. It's so obvious that Arnt has forgotten to mention it, is all. Most servers will have a fast way of finding changed messages, after all. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Jun 17 17:12:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fri5v-0001jf-AJ; Sat, 17 Jun 2006 17:12:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fri5t-0001ja-8Z for lemonade@ietf.org; Sat, 17 Jun 2006 17:12:37 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fri5r-0002d9-R5 for lemonade@ietf.org; Sat, 17 Jun 2006 17:12:37 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1Fri5r-0007Y1-3M; Sat, 17 Jun 2006 21:12:35 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 6D1F7498003; Sat, 17 Jun 2006 22:12:35 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06218-07; Sat, 17 Jun 2006 22:12:33 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 31082498002; Sat, 17 Jun 2006 22:12:33 +0100 (BST) Date: Sat, 17 Jun 2006 22:12:32 +0100 Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <449111CA.5040908@pathbreaker.com> <6AF0BC4F-695E-4029-A9CF-9F49C73A285A@mumbo.ca> <0m9d0uQfOFliUXnOU8hrtA.md5@libertango.oryx.com> In-Reply-To: <0m9d0uQfOFliUXnOU8hrtA.md5@libertango.oryx.com> MIME-Version: 1.0 Message-Id: <6187.1150578752.615963@peirce.dave.cridland.net> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri Jun 16 07:43:17 2006, Arnt Gulbrandsen wrote: > Curtis King writes: >>> Yes, in a pathological case, CONTEXT would be more efficient >>> since presumably the client would issue a single uber-search and >>> parse out the results into individual 'vmailboxes' on the client >>> side, rather than issue dozens of searches. But, what you see >>> as a bug for a pathological case (vmailboxes show up in LIST) I >>> see as a feature (clients can share vmailboxes easily) >> >> Once again, what's the big deal with sharing vmailboxes? > > I want to share all of mine. Ask Dave how many of the ten he > mentioned yesterday he wants to share. > > Well, I do share all of them, because my view definitions, like the rest of my configuration, lives in ACAP. But I'm afraid that overall, I'm really not the best person to ask about the notion of sharing things between devices, since my entire client configuration is always shared between all devices - I've largely forgotten what "not shared" means in practise. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Jun 18 10:47:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FryYf-000088-HX; Sun, 18 Jun 2006 10:47:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrhZM-00040q-Tj for lemonade@ietf.org; Sat, 17 Jun 2006 16:39:00 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrhZL-0006Wm-GS for lemonade@ietf.org; Sat, 17 Jun 2006 16:39:00 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FrhZJ-0003in-7e; Sat, 17 Jun 2006 20:38:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 38517498003; Sat, 17 Jun 2006 21:38:57 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05712-07; Sat, 17 Jun 2006 21:38:53 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 05957498002; Sat, 17 Jun 2006 21:38:52 +0100 (BST) Date: Sat, 17 Jun 2006 21:38:52 +0100 Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> <4491AB88.4060100@pathbreaker.com> <69A8533D-F578-43D0-8C3D-2D9B89FB9834@mumbo.ca> In-Reply-To: MIME-Version: 1.0 Message-Id: <6187.1150576732.697840@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Sun, 18 Jun 2006 10:47:24 -0400 Cc: Enhancements to Internet email to support diverse service enivronments , Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sat Jun 17 02:24:12 2006, Randall Gellens wrote: > At 1:53 PM -0600 6/15/06, Curtis King wrote: > >> On my mobile client I only want to see unread messages 90% of the >> time. > > So your mobile client shows you a list of unread messages. You > pick one and read it. Does it then vanish from the mobile device? > I'd think that it would be confusing and frustrating if it > immediately vanished, but people probably would like it to to > vanish from the mobile device at some point. People are also > likely to try and delete the message from the local device only if > it doesn't go away when they are through with it. I'm not sure > when it should vanish just from having been read, but I think it > needs to be under explicit client control. Is doing a FETCH > without PEEK is the right trigger for it to vanish? I have a lot of control code in my view implementation to address precisely this issue - basically, adding \Seen is not enough to remove a message from a view. It's not terribly easy to handle in a protocol specification, and it risks rendering a virtual mailbox useful for reading \Seen messages, unless you insist on always using PEEK. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Jun 18 12:41:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs0Ke-0002wd-Ft; Sun, 18 Jun 2006 12:41:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs0Kd-0002tC-Do for lemonade@ietf.org; Sun, 18 Jun 2006 12:41:03 -0400 Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs0Kb-00076S-6N for lemonade@ietf.org; Sun, 18 Jun 2006 12:41:03 -0400 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 900B7D6CBF3; Sun, 18 Jun 2006 12:40:59 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by frontend3.internal (MEProxy); Sun, 18 Jun 2006 12:41:01 -0400 X-Sasl-enc: JRfH+VM7po+hA+p7czHj2ZiFDL/SeWIQUMaJ+UDh1+1Q 1150648862 Received: from [10.0.1.4] (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) by www.fastmail.fm (Postfix) with ESMTP id E09261DB3; Sun, 18 Jun 2006 12:41:00 -0400 (EDT) Date: Sun, 18 Jun 2006 12:41:02 -0400 From: Cyrus Daboo To: Dave Cridland , Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Message-ID: In-Reply-To: <6187.1150576732.697840@peirce.dave.cridland.net> References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> <4491AB88.4060100@pathbreaker.com> <69A8533D-F578-43D0-8C3D-2D9B89FB9834@mumbo.ca> <6187.1150576732.697840@peirce.dave.cridland.net> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Enhancements to Internet email to support diverse service enivronments , Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dave, --On June 17, 2006 9:38:52 PM +0100 Dave Cridland wrote: >> So your mobile client shows you a list of unread messages. You >> pick one and read it. Does it then vanish from the mobile device? >> I'd think that it would be confusing and frustrating if it >> immediately vanished, but people probably would like it to to >> vanish from the mobile device at some point. People are also >> likely to try and delete the message from the local device only if >> it doesn't go away when they are through with it. I'm not sure >> when it should vanish just from having been read, but I think it >> needs to be under explicit client control. Is doing a FETCH >> without PEEK is the right trigger for it to vanish? > > I have a lot of control code in my view implementation to address > precisely this issue - basically, adding \Seen is not enough to remove a > message from a view. > > It's not terribly easy to handle in a protocol specification, and it > risks rendering a virtual mailbox useful for reading \Seen messages, > unless you insist on always using PEEK. All of this is a re-hash of the VIEW extension debate. Remember the discussion on 'dynamic', 'semi-dynamic' and 'static' views? There are use cases for all of those. The \Seen flag maps to semi-dynamic - you want new unseen messages to automatically appear in view but you do not want messages that you read to automatically disappear out of view. The \Delete flag is dynamic - typically a deleted message should disappear from the view immediately the flag is set. This was extensively described in Section 5 of VIEW. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 19 16:36:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQTb-00078y-Jf; Mon, 19 Jun 2006 16:36:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQTZ-00074i-BQ; Mon, 19 Jun 2006 16:36:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQFi-0006tW-8q; Mon, 19 Jun 2006 16:21:42 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsPm2-0005L1-Ca; Mon, 19 Jun 2006 15:51:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5JJo1mU030982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsPl3-0007ZC-Sa; Mon, 19 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-streaming-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Streaming Multimedia Messaging Attachments Author(s) : N. Cook Filename : draft-ietf-lemonade-streaming-00.txt Pages : 17 Date : 2006-6-19 This document, part of the Lemonade Working Group, describes the Best Current Practice for streaming multimedia attachments received by a resource constrained and/or mobile device from a IMAP server. It allows such clients, which are limited in storage space and bandwidth, to play video and audio content which is attached to email messages. The document describes a profile for making use of the existing IMAP URLAUTH extension (RFC 4467) [2] and the "Netann" SIP Media Service as described in RFC 4240 [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-streaming-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-streaming-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-19130213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-streaming-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-streaming-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-19130213.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Mon Jun 19 17:51:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRew-0006QE-W0; Mon, 19 Jun 2006 17:51:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRew-0006O4-5U for lemonade@ietf.org; Mon, 19 Jun 2006 17:51:50 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsRes-00048I-QQ for lemonade@ietf.org; Mon, 19 Jun 2006 17:51:50 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5JLphtK015562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Jun 2006 14:51:44 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5JLpfKJ019989; Mon, 19 Jun 2006 14:51:42 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 19 Jun 2006 14:49:15 -0700 To: Mark Crispin , Curtis King From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:12 PM -0700 6/16/06, Mark Crispin wrote: > On Thu, 15 Jun 2006, Curtis King wrote: >>> So, are you saying that there are clients that walk the entire >>> tree using % just to avoid doing a *? Unbelievable. >> It's even worst than that they also issue a status for each new >> mailbox they find. > > This is a lesson to never underestimate the determination of > individuals to do the wrong thing, no matter what measures are > undertaken to prevent it. I think this argues that profile-bis should reference the existing advice-to-implementers RFCs, and that a new such document is needed to cover what is missing. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The trouble with the world is not that people know too little, but that they know so many things that ain't so. --Mark Twain _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 19 17:59:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRmX-0002gw-IL; Mon, 19 Jun 2006 17:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRmW-0002aR-Tn for lemonade@ietf.org; Mon, 19 Jun 2006 17:59:40 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsRmS-0005HY-I3 for lemonade@ietf.org; Mon, 19 Jun 2006 17:59:40 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5JLxZaI012669; Mon, 19 Jun 2006 14:59:35 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5JLxYdW022695 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 19 Jun 2006 14:59:35 -0700 Date: Mon, 19 Jun 2006 14:59:36 -0700 (Pacific Daylight Time) From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt In-Reply-To: Message-ID: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Enhancements to Internet email to support diverse serviceenivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon, 19 Jun 2006, Randall Gellens wrote: > I think this argues that profile-bis should reference the existing > advice-to-implementers RFCs, and that a new such document is needed to cover > what is missing. Yes, but whose advice is taken? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 19 18:27:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSDu-00030d-Tz; Mon, 19 Jun 2006 18:27:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSDt-00030Y-EW for lemonade@ietf.org; Mon, 19 Jun 2006 18:27:57 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsSDs-00005E-2m for lemonade@ietf.org; Mon, 19 Jun 2006 18:27:57 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5JMRr9M019920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Jun 2006 15:27:54 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5JMRhn0001946 for ; Mon, 19 Jun 2006 15:27:53 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465725F807@esebe199.NOE.Nokia.com> <679461CF-34F3-43BB-9DD9-A363C698A588@mumbo.ca> <2D14E4C5-6E77-4C6C-AC6C-0E72D7653E5A@mumbo.ca> <10595.1150236555.436597@peirce.dave.cridland.net> <35E9AF3C-4130-4D71-9463-7AC5E728DAC8@mumbo.ca> <94CE7324-1233-4179-A910-E95EC749E0BD@mumbo.ca> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 19 Jun 2006 15:27:25 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-vfolder-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 9:28 PM +0200 6/15/06, Arnt Gulbrandsen wrote: > Every use case I've seen so far for vfolder was of a kind that's > naturally shared, in the sense that if you have a certain vfolder on > your desktop, you want the same on your laptop. At 1:16 PM -0700 6/16/06, Randall Gellens wrote: > If virtual mailboxes are used in lieu of server-based filtering, so > that incoming mail for, say, mailing lists, personal mail versus > work mail, etc. are all in INBOX instead of in individual > mailboxes, then it does make sense to share them between clients. > If instead virtual mailboxes are used to create subsets of > already-filtered mail so that limited-capacity mobile devices don't > see low-priority messages, then it may not make sense to share > them, since the criteria for "interesting" and low-priority may > differ on each device. In thinking about this issue some more (how virtual mailboxes are used, and about sharing them between clients), it occurs to me that it doesn't really matter if the virtual mailbox itself is shared or not. What matters, to the user, is that: - a desired view of his or her mail is available on desired devices - the shared views and especially the messages in them are coherent That is, if virtual mailboxes are used in lieu of server-side filtering, say for mailing list traffic or personal versus work mail, the user may want the exact same criteria on each device, or may want somewhat different criteria on different devices. But most importantly, if the user deletes a message, or replies to a message, the state of that message needs to be identical on each device. So, I'm not sure if the actual virtual mailbox mechanism needs to be shared or not. If clients are going to have a set of stock criteria that users select and combine (perhaps using descriptive names and check-boxes or something, for example, 'unread mail from this week', or 'mail sent explicitly to me'), then it may not make any difference to the client. Each client will use the set of criteria that the user chose, and doesn't care if any other client uses the same set. I think each client needs to cache the same things regardless if the exact criteria is being used by another client. Also, the user can always modify the criteria used on one device and may or may not want the same change on another device. Does it make a difference to the server? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I personally think we developed language because of our deep need to complain. --Lily Tomlin _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 19 18:50:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSa4-0005Rk-RK; Mon, 19 Jun 2006 18:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSZI-0003ol-W9; Mon, 19 Jun 2006 18:50:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsSZI-00040Z-T5; Mon, 19 Jun 2006 18:50:04 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsSZG-0001hj-6N; Mon, 19 Jun 2006 18:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5JMo1Hp010434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jun 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsSZF-0001qe-LA; Mon, 19 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Jun 2006 18:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : IMAP4 Extensions for Quick Mailbox Resynchronization Author(s) : A. Melnikov Filename : draft-ietf-lemonade-reconnect-client-00.txt Pages : 9 Date : 2006-6-19 This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox. [[anchor1: Need more text here, we already have a quick reconnect extension called CONDSTORE.]] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-reconnect-client-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-reconnect-client-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-19165646.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-reconnect-client-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-reconnect-client-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-19165646.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Tue Jun 20 02:33:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsZna-0003df-CM; Tue, 20 Jun 2006 02:33:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsZnZ-0003da-NK for lemonade@ietf.org; Tue, 20 Jun 2006 02:33:17 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsZnY-0001HB-8p for lemonade@ietf.org; Tue, 20 Jun 2006 02:33:17 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5K6XBkK029165; Tue, 20 Jun 2006 09:33:14 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 09:32:17 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 09:32:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Question on 'Sent Items' deposit Date: Tue, 20 Jun 2006 09:32:00 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465754D92A@esebe199.NOE.Nokia.com> In-Reply-To: <4484263D.2070008@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Question on 'Sent Items' deposit Thread-Index: AcaInXGBJ/yqiK//Qqyt7gsF1HPHDQLlcJBA From: To: , X-OriginalArrivalTime: 20 Jun 2006 06:32:16.0635 (UTC) FILETIME=[46103CB0:01C69433] X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Yes, title change and additional info in bis would be great. Thank You.=20 Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: 05 June, 2006 15:40 To: Dave Cridland Cc: Ordogh Zoltan (Nokia-TP-MSW/Tampere); lemonade@ietf.org Subject: Re: [lemonade] Question on 'Sent Items' deposit Dave Cridland wrote: > On Fri Jun 02 08:28:05 2006, Zoltan.Ordogh@nokia.com wrote: > >> Hi all, >> It a is a usual practice to place a copy of a sent email (new,=20 >> replied, forwarded) to a special store typically called "Sent=20 >> items"/"Sent mail" > > I tend to put them in INBOX, in fact, but the practise of a specific=20 > mailbox for copies of sent messages is common. > >> I understand that this is not done automatically - or perhaps I=20 >> missed some draft(?) - and it is the client's responsibility to=20 >> create and desposit the copy. I recon this is not a problem for a=20 >> fixed terminal. However, when I send something from a mobile=20 >> terminal, I would not want to upload it twice (once to SUBMIT server=20 >> and again to the IMAP server). >> Does LEMONADE provide a mechanism to make sure that we do not need to = >> upload an email twice? > > Yes, and we do - you upload the copy (via APPEND, possibly using=20 > CATENATE to assemble), and then send by using a single BURL/URLAUTH = pair. > > There's an alternate method, which uses POSTADDRESS, which isn't=20 > currently part of Lemonade. (Perhaps it should be?) > > This is covered in section 2.7 of Profile Bis (and probably of=20 > Profile, too). Yes, this is the same section in Profile. Step by step instructions are specified in Section 2.4.1 of Profile. > I might alter the title if it makes this easier to find. I am wondering if Profile bis should have a section with several simple = examples, that would help to understand the more detailed explanation? > Incidentally, usage of these mechanisms can be sensible over DSL=20 > links, since usage-based billing is increasingly common. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 06:01:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsd3V-0000dM-8V; Tue, 20 Jun 2006 06:01:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsd3S-0000cU-Kq for lemonade@ietf.org; Tue, 20 Jun 2006 06:01:54 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsd3R-0008E1-6M for lemonade@ietf.org; Tue, 20 Jun 2006 06:01:54 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KA1pbD015164; Tue, 20 Jun 2006 13:01:52 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:01:06 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:01:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Date: Tue, 20 Jun 2006 13:00:49 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465754DC63@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt Thread-Index: AcaOayOLZg8db/KFTPy0H4dwUOoV1AF5OBFg From: To: , X-OriginalArrivalTime: 20 Jun 2006 10:01:06.0741 (UTC) FILETIME=[7296AE50:01C69450] X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >Why would a client want to have more than one saved or active session = to the same server? To have multiple mailboxes selected (one per = session)? Is this still needed with condstore? Not one particluar client, but different clients. The usual corporate case (which I think might get more complicated in = the real life, however not very often): 1. boss having a laptop 2. boss having a mobile 3. secretary having a laptop 4. secretary having a mobile accessing the very same mailbox. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 Sent: 13 June, 2006 00:56 To: Alexey Melnikov; Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt At 8:44 PM +0100 6/11/06, Alexey Melnikov wrote: >> What is the server/client behaviour if it could not be created? >> > Client needs to fallback to using regular IMAP, as if the quick=20 > reconnect extension is not available. > > In theory the client can do something differently if it expects, say, = > 3 resumable sessions and only got 2. Why would a client want to have more than one saved or active session to = the same server? To have multiple mailboxes selected (one per session)? = Is this still needed with condstore? If so, maybe we do need to provide guidance to client authors as to what = to expect and to server authors as to a minimum per-user to support. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Artificial = intelligence is no match for natural stupidity. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 06:05:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsd6o-0002tx-4V; Tue, 20 Jun 2006 06:05:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsd6m-0002tr-VH for lemonade@ietf.org; Tue, 20 Jun 2006 06:05:20 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsd6l-0008Na-FH for lemonade@ietf.org; Tue, 20 Jun 2006 06:05:20 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KA5EGo030580; Tue, 20 Jun 2006 13:05:15 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:05:13 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:05:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt Date: Tue, 20 Jun 2006 13:04:57 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465754DC78@esebe199.NOE.Nokia.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664703074FF0@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt Thread-Index: AcZ7KvWhMH5SLE5+SIyxoTbAWZTn9gIUu9UAADN23uABokMg4ADs+PjgAXINLuA= From: To: X-OriginalArrivalTime: 20 Jun 2006 10:05:14.0643 (UTC) FILETIME=[06598630:01C69451] X-Spam-Score: 0.2 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org No comments, sounds reasonable. Should we capture it in the draft one way or another to aviod these = questions in the future? Thank You.=20 Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Burger, Eric [mailto:eburger@cantata.com]=20 Sent: 13 June, 2006 12:01 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: lemonade@ietf.org Subject: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt I would offer that we just state DRM is up to the IMAP server. It is = way beyond lemonade scope to figure out and replicate full DRM. Rather, = let's do butt simple DRM: if the client has the right to copy an object, = they can do whatever they want with it. The implementation is in = URLAUTH. If you cannot copy an object, for whatever reason, determined = way outside the protocol, the server will not generate a URLAUTH token. = The converse holds, as well. If the server generates a URLAUTH token, = the client can do whatever it wants with the object. The client can = forward the object (BURL), stream the object (streaming), or eat the = object (URLFETCH). We should explicitly say that (1) this provides = greater than or equal to DRM semantics with respect to existing e-mail = and (2) if you want real DRM, implement a real DRM system. Comments? -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] Sent: Thursday, June 08, 2006 4:31 AM To: lemonade@ietf.org Subject: RE: [lemonade] draft-cook-lemonade-streaming-00.txt I think it's looking good and simple: we generate a URL withing the IMAP = session for the media, then client connects directly to media server to = start streaming. Comments/questions: - URLAUTH is RFC 4467 now, not a draft, so the reference should be = updated. - There is no mentioning of DRM. Should there be? Has it been = considered at all? Or we do not need to because we leave it up to the = client and the media server to sort it out? Can an IMAP server create an = authorized URL for a DRMed content without any problem? (I'm not an = expert on DRM, but I do know that it has been problematic in other = messaging systems). Thank You, a good draft once again. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Burger, Eric [mailto:eburger@cantata.com] Sent: 31 May, 2006 03:48 To: Enhancements to Internet email to support diverse = serviceenivronments Subject: [lemonade] draft-cook-lemonade-streaming-00.txt Until it hits the archives, here is a copy of the outline for the = streaming services draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 06:11:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsdCI-0004dm-KP; Tue, 20 Jun 2006 06:11:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsdCH-0004dh-9c for lemonade@ietf.org; Tue, 20 Jun 2006 06:11:01 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsdCF-000067-Qd for lemonade@ietf.org; Tue, 20 Jun 2006 06:11:01 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KAAu4v000751 for ; Tue, 20 Jun 2006 13:10:59 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:10:56 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:10:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [lemonade] Fetching attachments page-by-page Date: Tue, 20 Jun 2006 13:10:39 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465754DC89@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Fetching attachments page-by-page Thread-Index: AcaUUcgpkdOZDZ4+QeC2xHKbSzJOJg== From: To: X-OriginalArrivalTime: 20 Jun 2006 10:10:57.0085 (UTC) FILETIME=[D27606D0:01C69451] X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0326394061==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0326394061== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69451.D2331E83" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69451.D2331E83 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I understand that profile references OMA STI for conversion of = attachments. OMA STI however does not allow fetching an attachment = page-by-page. However, there are valid use cases (like get only the first two pages of = a PPS file and not to download the rest if the user is not interested). I guess there is no such problem with plain text files (You can just get = any number of bytes), however when it's a binary (PDF, PPS, etc), the = binary file format be broken when retrieval is based on the number of = bytes (some formats include headers, index tables, etc at the end of the = file). So, do You think it is worth working out such mechanism in profile, or = we should simply leave the issue alone? Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 ------_=_NextPart_001_01C69451.D2331E83 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [lemonade] Fetching attachments page-by-page

Hi all,
I understand that profile = references OMA STI for conversion of attachments. OMA STI however does = not allow fetching an attachment page-by-page.

However, there are valid use = cases (like get only the first two pages of a PPS file and not to = download the rest if the user is not interested).

I guess there is no such = problem with plain text files (You can just get any number of bytes), = however when it's a binary (PDF, PPS, etc), the binary file format be = broken when retrieval is based on the number of bytes (some formats = include headers, index tables, etc at the end of the file).

So, do You think it is worth = working out such mechanism in profile, or we should simply leave the = issue alone?
Thank You.

Best regards: Zolt=E1n = =D6rd=F6gh
E-mail: zoltan = dot ordogh at nokia dot com
Phone: = +358 50 386 = 0566


------_=_NextPart_001_01C69451.D2331E83-- --===============0326394061== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============0326394061==-- From lemonade-bounces@ietf.org Tue Jun 20 06:15:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsdGC-0007RP-El; Tue, 20 Jun 2006 06:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsdGB-0007R8-20 for lemonade@ietf.org; Tue, 20 Jun 2006 06:15:03 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsdG9-0000C8-HY for lemonade@ietf.org; Tue, 20 Jun 2006 06:15:03 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KAEuqa025453; Tue, 20 Jun 2006 13:14:57 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:14:55 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:14:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Notifications for multiple devices per user Date: Tue, 20 Jun 2006 13:14:39 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664703074FF8@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: AcaMKhrhhAKGUPKVRym3wD651H6R4QCYKhxQAXHOe7A= From: To: , X-OriginalArrivalTime: 20 Jun 2006 10:14:56.0166 (UTC) FILETIME=[60F6E460:01C69452] X-Spam-Score: 0.2 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org It only gets more difficult when the user can rename a real folder (e.g. = Deleted items->Trash). BTW: can the user do this? If yes, where is the mapping stored? (mapping that tell that "Trash" is = the place to store deleted mails). Or, is it achieved using "decorative names" - how to assign a = "decorative name" to a folder? (decorative name meaning the name of the = folder that is supposed to be shown on the UI only). Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Burger, Eric [mailto:eburger@cantata.com]=20 Sent: 13 June, 2006 12:01 To: Randall Gellens Cc: Lemonade WG Subject: RE: [lemonade] Notifications for multiple devices per user I would offer that nothing changes for VFOLDERs referencing VFOLDERs. Take the case of MIDDLE referencing BOTTOM, where BOTTOM is a real = mailbox. In order to do the right thing when BOTTOM is manipulated = (renamed or deleted), the server has to have a data structure with all = of the VFOLDERs that reference the base folder. In other words, the = server needs to keep track of VFOLDER dependencies, whether we allow = recursive VFOLDER definition or not. For example, if the user renames = BOTTOM to BASE, the expression calculating MIDDLE needs to be updated to = reference BASE. Once that infrastructure is in place, then recursion happens for free if = we treat VFOLDERs as mailboxes. In the example given below, we have TOP = referencing the VFOLDER MIDDLE referencing the real mailbox BOTTOM. If = we manipulate MIDDLE, like deleting it, it would take the appropriate = action on TOP. In this case, it would delete TOP. Likewise, if we = delete BOTTOM, that deletes MIDDLE, which deletes TOP. -----Original Message----- From: Randall Gellens [mailto:randy@qualcomm.com] Sent: Friday, June 09, 2006 8:59 PM To: Lisa Dusseault; Alexey Melnikov Cc: Lemonade WG Subject: Re: [lemonade] Notifications for multiple devices per user At 4:40 PM -0700 6/9/06, Lisa Dusseault wrote: > There's an alternative architecture for the same use case, and that's = > to let the notification server (SIP or XMPP, in particular) do fanout. = =20 > Then the IMAP server simply sends the notification to the user's=20 > notification address (plus some application field if > specified) and the user decides which devices subscribe to those=20 > notifications. > > I could be wrong but I think some of those kinds of servers can=20 > gateway to SMS so that would even work in. > > lisa > > On Jun 7, 2006, at 5:54 AM, Alexey Melnikov wrote: > >> In my private discussion with Zoltan he raised a question about IMAP = >> server ability to store notification information (i.e. where the=20 >> notification is to be sent) for multiple devices per user. Is this=20 >> the requirement the WG wants to consider when thinking about=20 >> notifications? Depending on the device capability, it is conceivable that the user = might want different criteria. So the more capable the device, the more = state changes and new messages it is aware of, but the more limited = devices would only know about the most urgent messages. I had been thinking that this would be handled by Sieve, with various = rules sending notifications to different devices. This would imply that = the rules would need to be updated as devices change. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Chance that an = American cannot name a single right protected by the First Amendment: 1 in 3. (Harper's Index) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 06:31:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsdWD-0007rt-Lf; Tue, 20 Jun 2006 06:31:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsdWC-0007oq-LI for lemonade@ietf.org; Tue, 20 Jun 2006 06:31:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsdWC-0000hb-Jv for lemonade@ietf.org; Tue, 20 Jun 2006 06:31:36 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsdKp-0004Zq-C1 for lemonade@ietf.org; Tue, 20 Jun 2006 06:19:52 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KAJnk2007709; Tue, 20 Jun 2006 13:19:50 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:19:26 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:19:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt Date: Tue, 20 Jun 2006 13:19:09 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465754DCA2@esebe199.NOE.Nokia.com> In-Reply-To: <4492C2AE.1010009@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt Thread-Index: AcaRUwa3BBjSbhXcRJKcMunPcZHCKQC/7ujQ From: To: X-OriginalArrivalTime: 20 Jun 2006 10:19:25.0962 (UTC) FILETIME=[01C67EA0:01C69453] X-Spam-Score: -2.6 (--) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org It was supposed to refer to folders, but I read on the mailing list = before that the word folder should be avoided - did You find a better = word? So I just used mailbox (but I guess You understood what I meant = anyway). Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: 16 June, 2006 17:40 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: lemonade@ietf.org Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt Zoltan.Ordogh@nokia.com wrote: > - Can we add more events? Like MailboxCreated (name), MailboxRenamed = (name, newname), MailboxDeleted (name), MailboxMoved (name, = targetmailbox)? > I am not sure what MailboxMoved means, but I agree about the rest. > - This is for 'folder' management, but there could be a lot more. > =20 > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 06:45:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdj9-0005le-E7; Tue, 20 Jun 2006 06:44:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdj7-0005lZ-Pe for lemonade@ietf.org; Tue, 20 Jun 2006 06:44:57 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsdj7-0001Ws-9j for lemonade@ietf.org; Tue, 20 Jun 2006 06:44:57 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KAinQl018324; Tue, 20 Jun 2006 13:44:55 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:44:22 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:44:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Notifications for multiple devices per user Date: Tue, 20 Jun 2006 13:44:05 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465754DD20@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: AcaRmjqeEBTXQ70/QtOB3/+67ptXqwCu2sBg From: To: , X-OriginalArrivalTime: 20 Jun 2006 10:44:22.0563 (UTC) FILETIME=[7DD1AF30:01C69456] X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: lemonade@ietf.org, alexey.melnikov@isode.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Good points. I am not sure myself that SIEVE is the best way to go here. SIEVE might be good enough to identify which events needs to be = notified, however I do not think that the SIEVE scripts should include = information about the bearer type or addresses (where to send the = notification) - otherwise each client needs to update the SIEVE script = according to its need, and it will introduce additional issues. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 Sent: 17 June, 2006 02:11 To: Lisa Dusseault Cc: Lemonade WG; Alexey Melnikov Subject: Re: [lemonade] Notifications for multiple devices per user At 10:15 AM -0700 6/15/06, Lisa Dusseault wrote: >> At 4:40 PM -0700 6/9/06, Lisa Dusseault wrote: >> >>> There's an alternative architecture for the same use case, and=20 >>> that's to let the notification server (SIP or XMPP, in >>> particular) do fanout. Then the IMAP server simply sends the=20 >>> notification to the user's notification address (plus some=20 >>> application field if specified) and the user decides which devices=20 >>> subscribe to those notifications. > It's easier for the device to simply to subscribe, or no, to some=20 > address to which notifications are sent (not nonstop but whenever=20 > there's a receiver) according to a previously configured script or=20 > rule. I apologize if this was covered in a draft that I missed, but I'd=20 like to understand this better. So Sieve would be used to test messages, and generate notification=20 events as appropriate. If you had, say, progressively more=20 restrictive filter criteria, the Sieve script would contain tests for=20 each set. The Sieve script could be written such that it did the most=20 restrictive (fewest notifications) tests first, in the equivalent of=20 a deep IF-THEN-ELSEIF, and therefore at most one notification would=20 be generated per message. Or, the Sieve script could be written such=20 that it did all tests against all messages, and therefore might=20 generate multiple notifications per message. Notifications generated=20 by the Sieve script would be have an identifier that looked like an=20 IM address, and be published to something that looked like an IM=20 server. In the case of progressively more restrictive filter=20 criteria, each would have its own address. For example,=20 'randy.urgent-messages@jabber.example.org',=20 'randy.interesting-messages@jabber.example.org', etc. Devices would subscribe to the notifications using the identifier. How does the Sieve script get created and updated? Which device does=20 this, and how much knowledge does it need about the others? How is the Sieve script or engine configured to send notifications to=20 the addresses? How do devices learn which notification identifier they need to = subscribe to? Note that I think these questions apply generally to any out of band=20 notification mechanism. --=20 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- In America, anyone can become president. That's one of the risks you take. --Adlai Stevenson _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 06:50:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdow-00081z-4N; Tue, 20 Jun 2006 06:50:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdou-00081u-Mn for lemonade@ietf.org; Tue, 20 Jun 2006 06:50:56 -0400 Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsdot-0001fg-DF for lemonade@ietf.org; Tue, 20 Jun 2006 06:50:56 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:45112) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1Fsdon-0005GB-5V (Exim 4.54) (return-path ); Tue, 20 Jun 2006 11:50:49 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Fsdon-0000G8-Kr (Exim 4.53) (return-path ); Tue, 20 Jun 2006 11:50:49 +0100 Date: Tue, 20 Jun 2006 11:50:49 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] Fetching attachments page-by-page In-Reply-To: <0FA975F2D8295A448BE3ADC16124465754DC89@esebe199.NOE.Nokia.com> Message-ID: References: <0FA975F2D8295A448BE3ADC16124465754DC89@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 20 Jun 2006, Zoltan.Ordogh@nokia.com wrote: > I understand that profile references OMA STI for conversion of > attachments. OMA STI however does not allow fetching an attachment > page-by-page. However, there are valid use cases (like get only the > first two pages of a PPS file and not to download the rest if the user > is not interested). I guess there is no such problem with plain text > files (You can just get any number of bytes), however when it's a binary > (PDF, PPS, etc), the binary file format be broken when retrieval is > based on the number of bytes (some formats include headers, index > tables, etc at the end of the file). So, do You think it is worth > working out such mechanism in profile, or we should simply leave the > issue alone? I think it's too dependent on the details of the media type. If its format is designed for paged access then byte-range requests should be enough. This is all that HTTP provides, for example, so it's probably not worth trying to provide higher-level semantics in IMAP. PDF is designed to work with byte-range requests, and in fact when I was fixing Apache's byte-range request handling several years ago, the most common client that did byte-range requests was the Adobe Acrobat viewer. Tony. -- f.a.n.finch http://dotat.at/ MALIN: SOUTH 4 OR 5 INCREASING 6 TO GALE 8 THEN VEERING WEST, PERHAPS INCREASING SEVERE GALE 9 LATER. RAIN. MODERATE OR POOR. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 06:53:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsdrO-0001RP-Na; Tue, 20 Jun 2006 06:53:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsdrN-0001RB-70 for lemonade@ietf.org; Tue, 20 Jun 2006 06:53:29 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsdrL-0001uS-Ny for lemonade@ietf.org; Tue, 20 Jun 2006 06:53:29 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KArNVm008378; Tue, 20 Jun 2006 13:53:26 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:52:26 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:52:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Locating media servers for streaming Date: Tue, 20 Jun 2006 13:52:09 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465754DD34@esebe199.NOE.Nokia.com> In-Reply-To: <256618E0-70A1-4508-805A-D551E7B5C293@noware.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Locating media servers for streaming Thread-Index: AcaP8zB/4HsBECsoSMKhPC7lm7agLAEY11Aw From: To: , X-OriginalArrivalTime: 20 Jun 2006 10:52:26.0187 (UTC) FILETIME=[9E14D9B0:01C69457] X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Could there be a separate command for this? (so that the client can get = the latest info if needed at any time) E.g. To get full mapping: C: GETMEDIASERVER S: Server1 (1.1.1.1: avi, divx, wmv, wma); Server2 (1.1.1.2: mov, rm, = mp3, ac3) To get a server that handles a particular type: C: GETMEDIASERVER avi S: Server1(1.1.1.1) Also, I have a question - perhaps it was described/discussed before, = apologies if it was: Can I stream a content that is being converted? E.g. I get an AC3 audio stream as attachment, can I stream it as MP3 = instead? Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Neil Cook [mailto:neil.cook@noware.co.uk]=20 Sent: 14 June, 2006 20:44 To: lemonade@ietf.org Subject: [lemonade] Locating media servers for streaming All, Been thinking about the potential problem of lemonade clients locating a = media server to use in reference to streaming a multimedia attachment. There are several scenarios where media server location is *required*: 1) Discovery of media servers if client doesn't know *any* already. (How likely is this scenario? You would need a SIP-capable client that = is not configured with any media servers, which doesn't seem incredibly = likely) 2) Discovery of media servers that are authorised to access an IMAP = server, because it is configured to accept URLFETCH requests only from = certain media servers. There are also several scenarios where media server location is a = nice-to-have for other reasons such as security. I'm thinking of the = security implications of pawn-ticket URLs. The IMAP server could return = a media server address together with the username that the media server = uses to access the IMAP server, and thus the client could generate a URL = which was secure in that it could *only* be accessed by the media server = in question. Any thoughts? Neil. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 07:01:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdyr-00045m-Ty; Tue, 20 Jun 2006 07:01:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdyq-00045b-CS for lemonade@ietf.org; Tue, 20 Jun 2006 07:01:12 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsdyo-0002aI-Sg for lemonade@ietf.org; Tue, 20 Jun 2006 07:01:12 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KB19FX026333 for ; Tue, 20 Jun 2006 14:01:10 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 14:01:09 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 14:01:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-00.txt Date: Tue, 20 Jun 2006 14:00:52 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465754DD4B@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-00.txt Thread-Index: AcaT8uLgMRnayov+SYWoI1cqYYLycAAZY38A From: To: X-OriginalArrivalTime: 20 Jun 2006 11:01:10.0130 (UTC) FILETIME=[D6603520:01C69458] X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi all, What is the relation of this document to EXPUNGED? I feel I am missing something. EXPUNGED was not good enough? Issues with = it? Why is it called - connect-client? It does not have much to with = connecting - it's about quick resych. Thank You.=20 Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20 Sent: 20 June, 2006 01:50 To: i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: [lemonade] I-D = ACTION:draft-ietf-lemonade-reconnect-client-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF. Title : IMAP4 Extensions for Quick Mailbox Resynchronization Author(s) : A. Melnikov Filename : draft-ietf-lemonade-reconnect-client-00.txt Pages : 9 Date : 2006-6-19 =09 This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox. [[anchor1: Need more text here, we already have a quick reconnect extension called CONDSTORE.]] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client-= 00.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-reconnect-client-00.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-reconnect-client-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 07:42:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsed7-0002XQ-Jg; Tue, 20 Jun 2006 07:42:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsed6-0002Wv-P9 for lemonade@ietf.org; Tue, 20 Jun 2006 07:42:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fse7D-0002yw-Us for lemonade@ietf.org; Tue, 20 Jun 2006 07:09:51 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fse0j-0005Cl-0o for lemonade@ietf.org; Tue, 20 Jun 2006 07:03:10 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KB36NS028030; Tue, 20 Jun 2006 14:03:06 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 14:03:05 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 14:03:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Fetching attachments page-by-page Date: Tue, 20 Jun 2006 14:02:49 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465754DD52@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Fetching attachments page-by-page Thread-Index: AcaUV5mys0sL6tQ8R0SrCJUnR0S+WQAAVhHg From: To: X-OriginalArrivalTime: 20 Jun 2006 11:03:05.0720 (UTC) FILETIME=[1B45D780:01C69459] X-Spam-Score: -2.6 (--) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ok, so You're saying that we should not worry about it because it's not = worth it, right? Sounds fine, just wanted to verify it. Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: Tony Finch [mailto:fanf2@hermes.cam.ac.uk] On Behalf Of ext Tony = Finch Sent: 20 June, 2006 13:51 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: lemonade@ietf.org Subject: Re: [lemonade] Fetching attachments page-by-page On Tue, 20 Jun 2006, Zoltan.Ordogh@nokia.com wrote: > I understand that profile references OMA STI for conversion of=20 > attachments. OMA STI however does not allow fetching an attachment=20 > page-by-page. However, there are valid use cases (like get only the=20 > first two pages of a PPS file and not to download the rest if the user = > is not interested). I guess there is no such problem with plain text=20 > files (You can just get any number of bytes), however when it's a=20 > binary (PDF, PPS, etc), the binary file format be broken when=20 > retrieval is based on the number of bytes (some formats include=20 > headers, index tables, etc at the end of the file). So, do You think=20 > it is worth working out such mechanism in profile, or we should simply = > leave the issue alone? I think it's too dependent on the details of the media type. If its = format is designed for paged access then byte-range requests should be = enough. This is all that HTTP provides, for example, so it's probably not worth = trying to provide higher-level semantics in IMAP. PDF is designed to work with byte-range requests, and in fact when I was = fixing Apache's byte-range request handling several years ago, the most = common client that did byte-range requests was the Adobe Acrobat viewer. Tony. -- f.a.n.finch http://dotat.at/ MALIN: SOUTH 4 OR 5 INCREASING 6 TO GALE 8 THEN VEERING WEST, PERHAPS = INCREASING SEVERE GALE 9 LATER. RAIN. MODERATE OR POOR. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 08:35:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsfRr-0006E4-Ja; Tue, 20 Jun 2006 08:35:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsfRq-0006Dm-IE for lemonade@ietf.org; Tue, 20 Jun 2006 08:35:14 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsfRp-0001jz-7n for lemonade@ietf.org; Tue, 20 Jun 2006 08:35:14 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FsfRo-00011t-AM; Tue, 20 Jun 2006 12:35:12 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 6C3C1498003; Tue, 20 Jun 2006 13:35:38 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30178-08; Tue, 20 Jun 2006 13:35:34 +0100 (BST) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:a5e3:5e56:88d9:6fd5]) by turner.dave.cridland.net (Postfix) with ESMTP id 22B58498002; Tue, 20 Jun 2006 13:35:34 +0100 (BST) Date: Tue, 20 Jun 2006 13:34:51 +0100 Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-00.txt References: <0FA975F2D8295A448BE3ADC16124465754DD4B@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC16124465754DD4B@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <636.1150806891.936000@JOHN> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Jun 20 12:00:52 2006, Zoltan.Ordogh@nokia.com wrote: > Hi all, > What is the relation of this document to EXPUNGED? > I feel I am missing something. EXPUNGED was not good enough? Issues > with it? > > EXPUNGED is a dependency of this document. I do have issues with EXPUNGED, I think it's too simplistic, but I need to work out a mechanism that works with minimal state on the server in order to compete. > Why is it called - connect-client? It does not have much to with > connecting - it's about quick resych. Because it's a direct alternate to "server-side reconnect". But yes, it's a fast select. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 08:50:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsfgA-00063f-1c; Tue, 20 Jun 2006 08:50:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsfg9-00061U-7n for lemonade@ietf.org; Tue, 20 Jun 2006 08:50:01 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsfg7-0002mi-Sj for lemonade@ietf.org; Tue, 20 Jun 2006 08:50:01 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1Fsfg6-0004e3-QC for lemonade@ietf.org; Tue, 20 Jun 2006 12:49:58 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id CAD1E498003 for ; Tue, 20 Jun 2006 13:50:25 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30342-02 for ; Tue, 20 Jun 2006 13:50:21 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 4FB9A498002 for ; Tue, 20 Jun 2006 13:50:21 +0100 (BST) Date: Tue, 20 Jun 2006 13:49:47 +0100 Subject: RE: [lemonade] Notifications for multiple devices per user References: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <666.1150807794.041102@peirce.dave.cridland.net> From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Jun 20 11:14:39 2006, Zoltan.Ordogh@nokia.com wrote: > It only gets more difficult when the user can rename a real folder > (e.g. Deleted items->Trash). > BTW: can the user do this? > If yes, where is the mapping stored? (mapping that tell that > "Trash" is the place to store deleted mails). Deleted messages are stored in the folder they were deleted from. IMAP has a two stage delete, first you flag, then you EXPUNGE. You can think of it as "first you delete, then you empty trash", if you prefer, and it can be presented much like that. Physically moving the messages to a seperate folder involves first copying them, then going through IMAP's two-stage delete, and at some point, selecting the trash mailbox, and going through IMAP's two-stage delete there, too, in order to empty trash. It's possible, but given that IMAP already provides the two stage deletion that a Trash metaphor seeks to provide, I've never seen the point of going through so many round-trips. In addition, you can run out of quota whilst "deleting" messages using that mechanism, which yields quite amusing error messages. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 10:50:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FshZ8-0007Rv-TX; Tue, 20 Jun 2006 10:50:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FshZ7-0007Rq-L6 for lemonade@ietf.org; Tue, 20 Jun 2006 10:50:53 -0400 Received: from hideout.bfs.openwave.com ([193.129.95.230] helo=bfs-isa-in.openwave.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FshZ5-0008I5-Sr for lemonade@ietf.org; Tue, 20 Jun 2006 10:50:53 -0400 Received: from bfs-exch-prd1.myopwv.com ([10.20.249.141]) by bfs-isa-in.openwave.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 15:50:20 +0100 Received: from bfs-fe-prd1.myopwv.com ([10.20.249.143]) by bfs-exch-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 15:50:19 +0100 Received: from [127.0.0.1] ([10.16.81.129]) by bfs-fe-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 15:50:18 +0100 In-Reply-To: <0FA975F2D8295A448BE3ADC16124465754DD34@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC16124465754DD34@esebe199.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <423B4CC4-97F6-4357-9A14-8809629F2A3F@noware.co.uk> Content-Transfer-Encoding: quoted-printable From: Neil Cook Subject: Re: [lemonade] Locating media servers for streaming Date: Tue, 20 Jun 2006 15:48:11 +0100 To: X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 20 Jun 2006 14:50:19.0549 (UTC) FILETIME=[D9AB0CD0:01C69478] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan, yes I was thinking of a separate command - the latest draft just =20 posted contains a description of the problem and a high-level =20 proposal for a solution similar to your suggestion below. I wanted to =20= get a feeling for whether we should do this before going into command =20= specifics. As for your second question, that is really a function of the media =20 server. If the client presents a set of acceptable media in the SDP =20 to the media server that is different from the media in the =20 attachment, then the media server could transcode it, depending on =20 its capabilities. So theoretically, yes. Of course there may not be a =20= suitable transcoder from/to the supported media types, but that is an =20= implementation issue. Neil. On 20 Jun 2006, at 11:52, =20 wrote: > Could there be a separate command for this? (so that the client can =20= > get the latest info if needed at any time) > E.g. > To get full mapping: > C: GETMEDIASERVER > S: Server1 (1.1.1.1: avi, divx, wmv, wma); Server2 (1.1.1.2: mov, =20 > rm, mp3, ac3) > > To get a server that handles a particular type: > C: GETMEDIASERVER avi > S: Server1(1.1.1.1) > > Also, I have a question - perhaps it was described/discussed =20 > before, apologies if it was: > Can I stream a content that is being converted? > E.g. I get an AC3 audio stream as attachment, can I stream it as =20 > MP3 instead? > > Thank You. > > Best regards: Zolt=E1n =D6rd=F6gh > E-mail: zoltan dot ordogh at nokia dot com > Phone: +358 50 386 0566 > > > -----Original Message----- > From: ext Neil Cook [mailto:neil.cook@noware.co.uk] > Sent: 14 June, 2006 20:44 > To: lemonade@ietf.org > Subject: [lemonade] Locating media servers for streaming > > All, > > Been thinking about the potential problem of lemonade clients =20 > locating a media server to use in reference to streaming a =20 > multimedia attachment. > > There are several scenarios where media server location is *required*: > > 1) Discovery of media servers if client doesn't know *any* already. > (How likely is this scenario? You would need a SIP-capable client =20 > that is not configured with any media servers, which doesn't seem =20 > incredibly likely) > > 2) Discovery of media servers that are authorised to access an IMAP =20= > server, because it is configured to accept URLFETCH requests only =20 > from certain media servers. > > There are also several scenarios where media server location is a =20 > nice-to-have for other reasons such as security. I'm thinking of =20 > the security implications of pawn-ticket URLs. The IMAP server =20 > could return a media server address together with the username that =20= > the media server uses to access the IMAP server, and thus the =20 > client could generate a URL which was secure in that it could =20 > *only* be accessed by the media server in question. > > Any thoughts? > > Neil. > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 10:51:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FshZS-0007fJ-3L; Tue, 20 Jun 2006 10:51:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FshWz-0006Kj-5T for lemonade@ietf.org; Tue, 20 Jun 2006 10:48:41 -0400 Received: from hideout.bfs.openwave.com ([193.129.95.230] helo=bfs-isa-in.openwave.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FshUf-0007pA-VX for lemonade@ietf.org; Tue, 20 Jun 2006 10:46:19 -0400 Received: from bfs-exch-prd1.myopwv.com ([10.20.249.141]) by bfs-isa-in.openwave.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 15:45:45 +0100 Received: from bfs-fe-prd1.myopwv.com ([10.20.249.143]) by bfs-exch-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 15:45:45 +0100 Received: from [127.0.0.1] ([10.16.81.129]) by bfs-fe-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 15:45:37 +0100 In-Reply-To: <0FA975F2D8295A448BE3ADC16124465754DC78@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC16124465754DC78@esebe199.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <8B43BABA-2D25-4524-8EBA-8EDC81196596@openwave.com> Content-Transfer-Encoding: quoted-printable From: Neil Cook Subject: Re: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt Date: Tue, 20 Jun 2006 15:42:42 +0100 To: X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 20 Jun 2006 14:45:45.0035 (UTC) FILETIME=[360B89B0:01C69478] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I just submitted a new version of the draft that encapsulates these =20 comments, please let me know what you think. Neil. On 20 Jun 2006, at 11:04, =20 wrote: > No comments, sounds reasonable. > Should we capture it in the draft one way or another to aviod these =20= > questions in the future? > Thank You. > > > Best regards: Zolt=E1n =D6rd=F6gh > E-mail: zoltan dot ordogh at nokia dot com > Phone: +358 50 386 0566 > > > -----Original Message----- > From: ext Burger, Eric [mailto:eburger@cantata.com] > Sent: 13 June, 2006 12:01 > To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) > Cc: lemonade@ietf.org > Subject: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt > > I would offer that we just state DRM is up to the IMAP server. It =20 > is way beyond lemonade scope to figure out and replicate full DRM. =20= > Rather, let's do butt simple DRM: if the client has the right to =20 > copy an object, they can do whatever they want with it. The =20 > implementation is in URLAUTH. If you cannot copy an object, for =20 > whatever reason, determined way outside the protocol, the server =20 > will not generate a URLAUTH token. The converse holds, as well. =20 > If the server generates a URLAUTH token, the client can do whatever =20= > it wants with the object. The client can forward the object =20 > (BURL), stream the object (streaming), or eat the object =20 > (URLFETCH). We should explicitly say that (1) this provides =20 > greater than or equal to DRM semantics with respect to existing e-=20 > mail and (2) if you want real DRM, implement a real DRM system. > > Comments? > > -----Original Message----- > From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] > Sent: Thursday, June 08, 2006 4:31 AM > To: lemonade@ietf.org > Subject: RE: [lemonade] draft-cook-lemonade-streaming-00.txt > > I think it's looking good and simple: we generate a URL withing the =20= > IMAP session for the media, then client connects directly to media =20 > server to start streaming. > Comments/questions: > - URLAUTH is RFC 4467 now, not a draft, so the reference should be =20= > updated. > - There is no mentioning of DRM. Should there be? Has it been =20 > considered at all? Or we do not need to because we leave it up to =20 > the client and the media server to sort it out? Can an IMAP server =20 > create an authorized URL for a DRMed content without any problem? =20 > (I'm not an expert on DRM, but I do know that it has been =20 > problematic in other messaging systems). > Thank You, a good draft once again. > > Best regards: Zolt=E1n =D6rd=F6gh > E-mail: zoltan dot ordogh at nokia dot com > Phone: +358 50 386 0566 > > > -----Original Message----- > From: ext Burger, Eric [mailto:eburger@cantata.com] > Sent: 31 May, 2006 03:48 > To: Enhancements to Internet email to support diverse =20 > serviceenivronments > Subject: [lemonade] draft-cook-lemonade-streaming-00.txt > > Until it hits the archives, here is a copy of the outline for the =20 > streaming services draft. > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 11:28:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsi9L-00080W-5W; Tue, 20 Jun 2006 11:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsi9J-0007zp-Up for lemonade@ietf.org; Tue, 20 Jun 2006 11:28:17 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsi9I-0003nt-J7 for lemonade@ietf.org; Tue, 20 Jun 2006 11:28:17 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5KFSDX6017346; Tue, 20 Jun 2006 08:28:14 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5KFS7m9001235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 08:28:13 -0700 Date: Tue, 20 Jun 2006 08:28:06 -0700 (PDT) From: Mark Crispin To: Dave Cridland Subject: RE: [lemonade] Notifications for multiple devices per user In-Reply-To: <666.1150807794.041102@peirce.dave.cridland.net> Message-ID: References: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> <666.1150807794.041102@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 20 Jun 2006, Dave Cridland wrote: > Physically moving the messages to a seperate folder involves first copying > them, then going through IMAP's two-stage delete, and at some point, > selecting the trash mailbox, and going through IMAP's two-stage delete there, > too, in order to empty trash. It's possible, but given that IMAP already > provides the two stage deletion that a Trash metaphor seeks to provide, I've > never seen the point of going through so many round-trips. In addition, you > can run out of quota whilst "deleting" messages using that mechanism, which > yields quite amusing error messages. There's another, far worse, consequence of using a Trash mailbox instead of the native IMAP delete/expunge model. You can not restore a deleted message with Trash; you are forced to write a *new* copy, with a new UID, that will get re-downloaded by other clients. This is even for a fumble-finger that is immediately undone. I understand why novice programmers do the move to a Trash mailbox: they can not separate what is presented to the user from what goes on internally. They also think that they are "saving work" by doing this, since "empty trash" becomes a one-shot operation on a single mailbox. Never mind all the extra work that is undertaken to get to this stage! -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 14:14:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fskkc-0000eQ-SU; Tue, 20 Jun 2006 14:14:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fskka-0000eL-VU for lemonade@ietf.org; Tue, 20 Jun 2006 14:14:57 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FskkY-0001E3-IP for lemonade@ietf.org; Tue, 20 Jun 2006 14:14:56 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KIEp5s013227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Jun 2006 11:14:53 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KIEo3s028448; Tue, 20 Jun 2006 11:14:51 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC16124465754DC89@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC16124465754DC89@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 20 Jun 2006 11:14:35 -0700 To: , From: Randall Gellens Subject: Re: [lemonade] Fetching attachments page-by-page Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:10 PM +0300 6/20/06, wrote: > I understand that profile references OMA STI for conversion of > attachments. OMA STI however does not allow fetching an attachment > page-by-page. > > However, there are valid use cases (like get only the first two > pages of a PPS file and not to download the rest if the user is not > interested). > > I guess there is no such problem with plain text files (You can > just get any number of bytes), however when it's a binary (PDF, > PPS, etc), the binary file format be broken when retrieval is based > on the number of bytes (some formats include headers, index tables, > etc at the end of the file). > > So, do You think it is worth working out such mechanism in profile, > or we should simply leave the issue alone? > Thank You. I think we should not add extra features or complexity if we can possibly avoid it. Keep in mind that new features can always be added in the future, requiring only the publication of a document extending the specific mechanism involved. I don't see a compelling reason to add this feature at this time. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The solution to a problem changes the nature of the problem. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 14:25:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskvE-00082s-N4; Tue, 20 Jun 2006 14:25:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskvD-00082n-7g for lemonade@ietf.org; Tue, 20 Jun 2006 14:25:55 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FskvB-0002Iu-Pb for lemonade@ietf.org; Tue, 20 Jun 2006 14:25:55 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KIPpuj014434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 20 Jun 2006 11:25:52 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5KIPnLO002681 for ; Tue, 20 Jun 2006 11:25:51 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <666.1150807794.041102@peirce.dave.cridland.net> References: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> <666.1150807794.041102@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 20 Jun 2006 11:25:23 -0700 To: From: Randall Gellens Subject: RE: [lemonade] Notifications for multiple devices per user Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 1:49 PM +0100 6/20/06, Dave Cridland wrote: > Deleted messages are stored in the folder they were deleted from. > IMAP has a two stage delete, first you flag, then you EXPUNGE. > > You can think of it as "first you delete, then you empty trash", if > you prefer, and it can be presented much like that. > > Physically moving the messages to a seperate folder involves first > copying them, then going through IMAP's two-stage delete, and at > some point, selecting the trash mailbox, and going through IMAP's > two-stage delete there, too, in order to empty trash. It's > possible, but given that IMAP already provides the two stage > deletion that a Trash metaphor seeks to provide, I've never seen > the point of going through so many round-trips. In addition, you > can run out of quota whilst "deleting" messages using that > mechanism, which yields quite amusing error messages. A client can certainly present deleted messages as being in a separate (virtual) mailbox even though the messages remain in their original mailbox. This has a few advantages, including the ease of restoring the message to its former mailbox if the user undeletes it. However, the clients that I've used don't do that. They either copy the message to a trash mailbox and then delete and expunge it from the former mailbox, or they leave it where it is, and either show it to the user (marked as deleted) or hide it. Are there clients that present deleted messages as being in a (virtual) trash mailbox? I suppose one concern would be user confusion: if the user looks at the mailboxes using another client or a web interface, the virtual trash mailbox would not be there. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Attaccabottonai (ah-TAHKA-bo-TONE-eye; Italian; noun): a doleful bore who buttonholes people and tells sad, pointless tales. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 14:27:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fskwt-0001Jj-4V; Tue, 20 Jun 2006 14:27:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fskwr-0001JZ-Ml for lemonade@ietf.org; Tue, 20 Jun 2006 14:27:37 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fskwo-0002LR-B0 for lemonade@ietf.org; Tue, 20 Jun 2006 14:27:37 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5KIRXM1001464; Tue, 20 Jun 2006 11:27:33 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com (D-140-142-21-52.dhcp4.washington.edu [140.142.21.52]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5KIRWMC000940 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 20 Jun 2006 11:27:33 -0700 Date: Tue, 20 Jun 2006 11:27:27 -0700 From: Mark Crispin To: Randall Gellens Subject: RE: [lemonade] Notifications for multiple devices per user In-Reply-To: Message-ID: References: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> <666.1150807794.041102@peirce.dave.cridland.net> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 20 Jun 2006, Randall Gellens wrote: > Are there clients that present deleted messages as being in a (virtual) trash > mailbox? I know that such exist, but I don't know their names. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 15:18:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fslk9-0008UN-5H; Tue, 20 Jun 2006 15:18:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fslk7-0008Pf-NI for lemonade@ietf.org; Tue, 20 Jun 2006 15:18:31 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fslk6-0007vs-8J for lemonade@ietf.org; Tue, 20 Jun 2006 15:18:31 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1Fslk5-0007cS-1v; Tue, 20 Jun 2006 19:18:29 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id DAEF1498003; Tue, 20 Jun 2006 20:18:58 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01110-04; Tue, 20 Jun 2006 20:18:54 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 6825D498002; Tue, 20 Jun 2006 20:18:54 +0100 (BST) Date: Tue, 20 Jun 2006 20:18:24 +0100 Subject: RE: [lemonade] Notifications for multiple devices per user References: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> <666.1150807794.041102@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <666.1150831104.400306@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Jun 20 19:25:23 2006, Randall Gellens wrote: > At 1:49 PM +0100 6/20/06, Dave Cridland wrote: > >> Deleted messages are stored in the folder they were deleted from. >> IMAP has a two stage delete, first you flag, then you EXPUNGE. >> >> You can think of it as "first you delete, then you empty trash", >> if you prefer, and it can be presented much like that. >> >> Physically moving the messages to a seperate folder involves >> first copying them, then going through IMAP's two-stage delete, >> and at some point, selecting the trash mailbox, and going through >> IMAP's two-stage delete there, too, in order to empty trash. It's >> possible, but given that IMAP already provides the two stage >> deletion that a Trash metaphor seeks to provide, I've never seen >> the point of going through so many round-trips. In addition, you >> can run out of quota whilst "deleting" messages using that >> mechanism, which yields quite amusing error messages. > > A client can certainly present deleted messages as being in a > separate (virtual) mailbox even though the messages remain in their > original mailbox. This has a few advantages, including the ease of > restoring the message to its former mailbox if the user undeletes > it. However, the clients that I've used don't do that. They either > copy the message to a trash mailbox and then delete and expunge it > from the former mailbox, or they leave it where it is, and either > show it to the user (marked as deleted) or hide it. > > It's easier to present them as "every mailbox has a trash can" - ie, don't present the trash as a distinct mailbox, present it as a feature of the mailbox. That way you don't have to emulate a multi-mailbox backed virtual folder. I don't do this, although many of my users usually ask me how to stop it showing the deleted messages in the summary. (Define a view that does UNDELETED, and use that). > Are there clients that present deleted messages as being in a > (virtual) trash mailbox? > > I suppose one concern would be user confusion: if the user looks at > the mailboxes using another client or a web interface, the virtual > trash mailbox would not be there. Well, it would be if your web interface or other client read your preferences from a common location and knew to present deleted messages using the metaphor you preferred. We could write one. Call it ACAP. Maybe have an Email Account Dataset specification for this kind of stuff. But that's just a crazy idea, I know. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 20 21:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsr9X-0000lW-FS; Tue, 20 Jun 2006 21:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsr9W-0000l7-Bj for lemonade@ietf.org; Tue, 20 Jun 2006 21:05:06 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsr9V-00054O-2H for lemonade@ietf.org; Tue, 20 Jun 2006 21:05:06 -0400 X-IronPort-AV: i="4.06,158,1149480000"; d="scan'208"; a="34400599:sNHT71485656" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt Date: Tue, 20 Jun 2006 21:05:02 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647031339C0@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt Thread-Index: AcZ7KvWhMH5SLE5+SIyxoTbAWZTn9gIUu9UAADN23uABokMg4ADs+PjgAXINLuAAH3JCkA== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I think it is in the latest revision of the draft. Alexey? -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com]=20 Sent: Tuesday, June 20, 2006 6:05 AM To: Burger, Eric Cc: lemonade@ietf.org Subject: RE: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt No comments, sounds reasonable. Should we capture it in the draft one way or another to aviod these = questions in the future? Thank You.=20 Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Burger, Eric [mailto:eburger@cantata.com]=20 Sent: 13 June, 2006 12:01 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: lemonade@ietf.org Subject: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt I would offer that we just state DRM is up to the IMAP server. It is = way beyond lemonade scope to figure out and replicate full DRM. Rather, = let's do butt simple DRM: if the client has the right to copy an object, = they can do whatever they want with it. The implementation is in = URLAUTH. If you cannot copy an object, for whatever reason, determined = way outside the protocol, the server will not generate a URLAUTH token. = The converse holds, as well. If the server generates a URLAUTH token, = the client can do whatever it wants with the object. The client can = forward the object (BURL), stream the object (streaming), or eat the = object (URLFETCH). We should explicitly say that (1) this provides = greater than or equal to DRM semantics with respect to existing e-mail = and (2) if you want real DRM, implement a real DRM system. Comments? -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] Sent: Thursday, June 08, 2006 4:31 AM To: lemonade@ietf.org Subject: RE: [lemonade] draft-cook-lemonade-streaming-00.txt I think it's looking good and simple: we generate a URL withing the IMAP = session for the media, then client connects directly to media server to = start streaming. Comments/questions: - URLAUTH is RFC 4467 now, not a draft, so the reference should be = updated. - There is no mentioning of DRM. Should there be? Has it been = considered at all? Or we do not need to because we leave it up to the = client and the media server to sort it out? Can an IMAP server create an = authorized URL for a DRMed content without any problem? (I'm not an = expert on DRM, but I do know that it has been problematic in other = messaging systems). Thank You, a good draft once again. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Burger, Eric [mailto:eburger@cantata.com] Sent: 31 May, 2006 03:48 To: Enhancements to Internet email to support diverse = serviceenivronments Subject: [lemonade] draft-cook-lemonade-streaming-00.txt Until it hits the archives, here is a copy of the outline for the = streaming services draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 02:14:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsvzE-0004RL-R4; Wed, 21 Jun 2006 02:14:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsvzD-0004R5-Su for lemonade@ietf.org; Wed, 21 Jun 2006 02:14:47 -0400 Received: from [2002:d159:4635::1] (helo=orthanc.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsvzC-0001Id-AC for lemonade@ietf.org; Wed, 21 Jun 2006 02:14:47 -0400 Received: from [192.168.15.2] (d154-5-28-131.bchsia.telus.net [154.5.28.131]) (authenticated bits=0) by orthanc.ca (8.13.4/8.13.4) with ESMTP id k5L6EepE085692; Wed, 21 Jun 2006 00:14:40 -0600 (MDT) (envelope-from lyndon@orthanc.ca) In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> <666.1150807794.041102@peirce.dave.cridland.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lyndon Nerenberg Subject: Re: [lemonade] Notifications for multiple devices per user Date: Tue, 20 Jun 2006 23:14:38 -0700 To: Randall Gellens X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=1.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on orthanc.ca X-Spam-Score: 1.8 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Are there clients that present deleted messages as being in a > (virtual) trash mailbox? I have yet to come across one. All the non-trash-folder clients I've worked with provide a switch that makes the deleted messages visible (or not) in the folder's message index list. > I suppose one concern would be user confusion: if the user looks at > the mailboxes using another client or a web interface, the virtual > trash mailbox would not be there. Which leads me to conclude we desperately need a "Doh! Don't Do IMAP Trash This Way, And Here's Why" RFC. Written in little tiny syllables, with a lot of pictures. Why is it so hard for client writers to grok this concept? I'm not asking this rhetorically. It's such a simple concept that I'm stunned by how hard it seems to be for people to wrap their heads around it. What do we need to do to explain the concept in a way that everyone "gets it" ??? --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 06:20:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FszoW-0005ln-2p; Wed, 21 Jun 2006 06:20:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FszoT-0005jL-LQ for lemonade@ietf.org; Wed, 21 Jun 2006 06:19:57 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FszoT-0002PX-4z for lemonade@ietf.org; Wed, 21 Jun 2006 06:19:57 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5LAJnHo021086; Wed, 21 Jun 2006 13:19:52 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 13:18:56 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 13:18:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt Date: Wed, 21 Jun 2006 13:18:39 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446575A3468@esebe199.NOE.Nokia.com> In-Reply-To: <8B43BABA-2D25-4524-8EBA-8EDC81196596@openwave.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt Thread-Index: AcaUeIBP4yD8VS2ORaOwyGwwJQUxKAAozygA From: To: X-OriginalArrivalTime: 21 Jun 2006 10:18:56.0103 (UTC) FILETIME=[1A641F70:01C6951C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mea culpa: I was looking at draft-cook-lemonade-streaming-00.txt instead = of draft-ietf-lemonade-streaming-00.txt. The updated version is great, thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Neil Cook [mailto:neil.cook@openwave.com]=20 Sent: 20 June, 2006 17:43 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: eburger@cantata.com; lemonade@ietf.org Subject: Re: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt I just submitted a new version of the draft that encapsulates these = comments, please let me know what you think. Neil. On 20 Jun 2006, at 11:04, = wrote: > No comments, sounds reasonable. > Should we capture it in the draft one way or another to aviod these=20 > questions in the future? > Thank You. > > > Best regards: Zolt=E1n =D6rd=F6gh > E-mail: zoltan dot ordogh at nokia dot com > Phone: +358 50 386 0566 > > > -----Original Message----- > From: ext Burger, Eric [mailto:eburger@cantata.com] > Sent: 13 June, 2006 12:01 > To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) > Cc: lemonade@ietf.org > Subject: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt > > I would offer that we just state DRM is up to the IMAP server. It =20 > is way beyond lemonade scope to figure out and replicate full DRM. =20 > Rather, let's do butt simple DRM: if the client has the right to copy=20 > an object, they can do whatever they want with it. The implementation = > is in URLAUTH. If you cannot copy an object, for whatever reason,=20 > determined way outside the protocol, the server > will not generate a URLAUTH token. The converse holds, as well. =20 > If the server generates a URLAUTH token, the client can do whatever it = > wants with the object. The client can forward the object (BURL),=20 > stream the object (streaming), or eat the object (URLFETCH). We=20 > should explicitly say that (1) this provides greater than or equal to=20 > DRM semantics with respect to existing e- mail and (2) if you want=20 > real DRM, implement a real DRM system. > > Comments? > > -----Original Message----- > From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] > Sent: Thursday, June 08, 2006 4:31 AM > To: lemonade@ietf.org > Subject: RE: [lemonade] draft-cook-lemonade-streaming-00.txt > > I think it's looking good and simple: we generate a URL withing the=20 > IMAP session for the media, then client connects directly to media=20 > server to start streaming. > Comments/questions: > - URLAUTH is RFC 4467 now, not a draft, so the reference should be=20 > updated. > - There is no mentioning of DRM. Should there be? Has it been=20 > considered at all? Or we do not need to because we leave it up to the=20 > client and the media server to sort it out? Can an IMAP server create=20 > an authorized URL for a DRMed content without any problem? > (I'm not an expert on DRM, but I do know that it has been problematic=20 > in other messaging systems). > Thank You, a good draft once again. > > Best regards: Zolt=E1n =D6rd=F6gh > E-mail: zoltan dot ordogh at nokia dot com > Phone: +358 50 386 0566 > > > -----Original Message----- > From: ext Burger, Eric [mailto:eburger@cantata.com] > Sent: 31 May, 2006 03:48 > To: Enhancements to Internet email to support diverse=20 > serviceenivronments > Subject: [lemonade] draft-cook-lemonade-streaming-00.txt > > Until it hits the archives, here is a copy of the outline for the=20 > streaming services draft. > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 06:25:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsztT-0001jX-8z; Wed, 21 Jun 2006 06:25:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsztS-0001jS-1n for lemonade@ietf.org; Wed, 21 Jun 2006 06:25:06 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsztR-0002X2-HJ for lemonade@ietf.org; Wed, 21 Jun 2006 06:25:06 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5LAP4Lf032443; Wed, 21 Jun 2006 13:25:04 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 13:24:12 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 13:24:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Locating media servers for streaming Date: Wed, 21 Jun 2006 13:23:55 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446575A347B@esebe199.NOE.Nokia.com> In-Reply-To: <423B4CC4-97F6-4357-9A14-8809629F2A3F@noware.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Locating media servers for streaming Thread-Index: AcaUePjnyq9iWblFQgWep26VEr8fBgAozyWQ From: To: X-OriginalArrivalTime: 21 Jun 2006 10:24:11.0917 (UTC) FILETIME=[D6A183D0:01C6951C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Thank You Neil, I would definiately prefer the new command - the client could always get = up-to-date information according to its needs. Back to the second issue: I understand what You are saying, and I agree, = however my question was more like: "Does the syntax support this and how = to do this?" I mean, You get a BURL so You an stream the media from the = media server. How can transcoding parameters be added to the BURL (so = that You can tell the server that You could give me that content like = this as well, just let me know which type it will be)?=20 Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Neil Cook [mailto:neil.cook@noware.co.uk]=20 Sent: 20 June, 2006 17:48 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: lemonade@ietf.org Subject: Re: [lemonade] Locating media servers for streaming Zoltan, yes I was thinking of a separate command - the latest draft just posted = contains a description of the problem and a high-level proposal for a = solution similar to your suggestion below. I wanted to get a feeling for = whether we should do this before going into command specifics. As for your second question, that is really a function of the media = server. If the client presents a set of acceptable media in the SDP to = the media server that is different from the media in the attachment, = then the media server could transcode it, depending on its capabilities. = So theoretically, yes. Of course there may not be a suitable transcoder = from/to the supported media types, but that is an implementation issue. Neil. On 20 Jun 2006, at 11:52, = wrote: > Could there be a separate command for this? (so that the client can=20 > get the latest info if needed at any time) E.g. > To get full mapping: > C: GETMEDIASERVER > S: Server1 (1.1.1.1: avi, divx, wmv, wma); Server2 (1.1.1.2: mov, rm,=20 > mp3, ac3) > > To get a server that handles a particular type: > C: GETMEDIASERVER avi > S: Server1(1.1.1.1) > > Also, I have a question - perhaps it was described/discussed before,=20 > apologies if it was: > Can I stream a content that is being converted? > E.g. I get an AC3 audio stream as attachment, can I stream it as > MP3 instead? > > Thank You. > > Best regards: Zolt=E1n =D6rd=F6gh > E-mail: zoltan dot ordogh at nokia dot com > Phone: +358 50 386 0566 > > > -----Original Message----- > From: ext Neil Cook [mailto:neil.cook@noware.co.uk] > Sent: 14 June, 2006 20:44 > To: lemonade@ietf.org > Subject: [lemonade] Locating media servers for streaming > > All, > > Been thinking about the potential problem of lemonade clients locating = > a media server to use in reference to streaming a multimedia=20 > attachment. > > There are several scenarios where media server location is *required*: > > 1) Discovery of media servers if client doesn't know *any* already. > (How likely is this scenario? You would need a SIP-capable client that = > is not configured with any media servers, which doesn't seem=20 > incredibly likely) > > 2) Discovery of media servers that are authorised to access an IMAP=20 > server, because it is configured to accept URLFETCH requests only from = > certain media servers. > > There are also several scenarios where media server location is a=20 > nice-to-have for other reasons such as security. I'm thinking of the=20 > security implications of pawn-ticket URLs. The IMAP server could=20 > return a media server address together with the username that the=20 > media server uses to access the IMAP server, and thus the client could = > generate a URL which was secure in that it could > *only* be accessed by the media server in question. > > Any thoughts? > > Neil. > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 06:26:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fszuf-000291-PB; Wed, 21 Jun 2006 06:26:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fszue-00028w-5B for lemonade@ietf.org; Wed, 21 Jun 2006 06:26:20 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fszuc-0002Z0-NK for lemonade@ietf.org; Wed, 21 Jun 2006 06:26:20 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5LAQFb8025471; Wed, 21 Jun 2006 13:26:17 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 13:25:30 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 13:25:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Fetching attachments page-by-page Date: Wed, 21 Jun 2006 13:25:13 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446575A347F@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Fetching attachments page-by-page Thread-Index: AcaUlX1K0jbEDepqSq+xItQPNfGgGgAh2T0A From: To: , X-OriginalArrivalTime: 21 Jun 2006 10:25:30.0133 (UTC) FILETIME=[05405450:01C6951D] X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Thank You Randall, no problem - just wanted to hear opinions on it since I could not make = it to the interim meeting.=20 Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 Sent: 20 June, 2006 21:15 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); lemonade@ietf.org Subject: Re: [lemonade] Fetching attachments page-by-page At 1:10 PM +0300 6/20/06, wrote: > I understand that profile references OMA STI for conversion of=20 > attachments. OMA STI however does not allow fetching an attachment=20 > page-by-page. > > However, there are valid use cases (like get only the first two pages = > of a PPS file and not to download the rest if the user is not=20 > interested). > > I guess there is no such problem with plain text files (You can just=20 > get any number of bytes), however when it's a binary (PDF, PPS, etc),=20 > the binary file format be broken when retrieval is based on the number = > of bytes (some formats include headers, index tables, etc at the end=20 > of the file). > > So, do You think it is worth working out such mechanism in profile,=20 > or we should simply leave the issue alone? > Thank You. I think we should not add extra features or complexity if we can = possibly avoid it. Keep in mind that new features can always be added = in the future, requiring only the publication of a document extending = the specific mechanism involved. I don't see a compelling reason to add = this feature at this time. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The solution to a = problem changes the nature of the problem. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 06:45:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0DK-00059i-Hj; Wed, 21 Jun 2006 06:45:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0DJ-00058s-AU for lemonade@ietf.org; Wed, 21 Jun 2006 06:45:37 -0400 Received: from hideout.bfs.openwave.com ([193.129.95.230] helo=bfs-isa-in.openwave.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft0DI-0003ZN-Pr for lemonade@ietf.org; Wed, 21 Jun 2006 06:45:37 -0400 Received: from bfs-exch-prd1.myopwv.com ([10.20.249.141]) by bfs-isa-in.openwave.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 11:45:04 +0100 Received: from bfs-fe-prd1.myopwv.com ([10.20.249.143]) by bfs-exch-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 11:45:04 +0100 Received: from [127.0.0.1] ([10.16.81.129]) by bfs-fe-prd1.myopwv.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 11:45:03 +0100 In-Reply-To: <0FA975F2D8295A448BE3ADC1612446575A347B@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446575A347B@esebe199.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Neil Cook Subject: Re: [lemonade] Locating media servers for streaming Date: Wed, 21 Jun 2006 11:46:10 +0100 To: X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 21 Jun 2006 10:45:04.0089 (UTC) FILETIME=[C0FBCC90:01C6951F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan, when the client contacts the media server, it provides the URL as a =20 parameter to the SIP INVITE as in my draft. What the draft doesn't go =20= into the details of is the SIP payload, which is SDP. SDP contains =20 all the media negotiation facilities required for this, and the =20 client would simply setup the correct SDP parameters to indicate =20 which media is it prepared to accept for this session. The reply to =20 the invite contains SDP parameters from the media server. I didn't go into the details of SIP/SDP in the draft, kind of =20 assuming that it was well understood, but I can flesh it out the fact =20= that SDP will be used for the media negotiation a little more. I =20 gueess it is a little presumptuous to assume that all messaging folks =20= also know about SDP. Neil. On 21 Jun 2006, at 11:23, =20 wrote: > Thank You Neil, > I would definiately prefer the new command - the client could =20 > always get up-to-date information according to its needs. > > Back to the second issue: I understand what You are saying, and I =20 > agree, however my question was more like: "Does the syntax support =20 > this and how to do this?" I mean, You get a BURL so You an stream =20 > the media from the media server. How can transcoding parameters be =20 > added to the BURL (so that You can tell the server that You could =20 > give me that content like this as well, just let me know which type =20= > it will be)? > > Thank You. > > Best regards: Zolt=E1n =D6rd=F6gh > E-mail: zoltan dot ordogh at nokia dot com > Phone: +358 50 386 0566 > > > -----Original Message----- > From: ext Neil Cook [mailto:neil.cook@noware.co.uk] > Sent: 20 June, 2006 17:48 > To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) > Cc: lemonade@ietf.org > Subject: Re: [lemonade] Locating media servers for streaming > > Zoltan, > > yes I was thinking of a separate command - the latest draft just =20 > posted contains a description of the problem and a high-level =20 > proposal for a solution similar to your suggestion below. I wanted =20 > to get a feeling for whether we should do this before going into =20 > command specifics. > > As for your second question, that is really a function of the media =20= > server. If the client presents a set of acceptable media in the SDP =20= > to the media server that is different from the media in the =20 > attachment, then the media server could transcode it, depending on =20 > its capabilities. So theoretically, yes. Of course there may not be =20= > a suitable transcoder from/to the supported media types, but that =20 > is an implementation issue. > > Neil. > > On 20 Jun 2006, at 11:52, =20 > wrote: > >> Could there be a separate command for this? (so that the client can >> get the latest info if needed at any time) E.g. >> To get full mapping: >> C: GETMEDIASERVER >> S: Server1 (1.1.1.1: avi, divx, wmv, wma); Server2 (1.1.1.2: mov, rm, >> mp3, ac3) >> >> To get a server that handles a particular type: >> C: GETMEDIASERVER avi >> S: Server1(1.1.1.1) >> >> Also, I have a question - perhaps it was described/discussed before, >> apologies if it was: >> Can I stream a content that is being converted? >> E.g. I get an AC3 audio stream as attachment, can I stream it as >> MP3 instead? >> >> Thank You. >> >> Best regards: Zolt=E1n =D6rd=F6gh >> E-mail: zoltan dot ordogh at nokia dot com >> Phone: +358 50 386 0566 >> >> >> -----Original Message----- >> From: ext Neil Cook [mailto:neil.cook@noware.co.uk] >> Sent: 14 June, 2006 20:44 >> To: lemonade@ietf.org >> Subject: [lemonade] Locating media servers for streaming >> >> All, >> >> Been thinking about the potential problem of lemonade clients =20 >> locating >> a media server to use in reference to streaming a multimedia >> attachment. >> >> There are several scenarios where media server location is =20 >> *required*: >> >> 1) Discovery of media servers if client doesn't know *any* already. >> (How likely is this scenario? You would need a SIP-capable client =20 >> that >> is not configured with any media servers, which doesn't seem >> incredibly likely) >> >> 2) Discovery of media servers that are authorised to access an IMAP >> server, because it is configured to accept URLFETCH requests only =20 >> from >> certain media servers. >> >> There are also several scenarios where media server location is a >> nice-to-have for other reasons such as security. I'm thinking of the >> security implications of pawn-ticket URLs. The IMAP server could >> return a media server address together with the username that the >> media server uses to access the IMAP server, and thus the client =20 >> could >> generate a URL which was secure in that it could >> *only* be accessed by the media server in question. >> >> Any thoughts? >> >> Neil. >> >> >> _______________________________________________ >> lemonade mailing list >> lemonade@ietf.org >> https://www1.ietf.org/mailman/listinfo/lemonade >> >> _______________________________________________ >> lemonade mailing list >> lemonade@ietf.org >> https://www1.ietf.org/mailman/listinfo/lemonade > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 06:51:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0J4-0000Vp-Cy; Wed, 21 Jun 2006 06:51:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0J2-0000Vk-V2 for lemonade@ietf.org; Wed, 21 Jun 2006 06:51:32 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft0J2-0004kA-8m for lemonade@ietf.org; Wed, 21 Jun 2006 06:51:32 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 21 Jun 2006 11:51:15 +0100 Message-ID: <44980246.7010201@isode.com> Date: Tue, 20 Jun 2006 15:12:22 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > In Section 1: > It is based on LEMONADE profile [profile]. > > This document describes the lemonade profile-bis that includes: > > I don't think we should use the term "bis" anywhere in the document > (just the title), since this document is an update to the previous > profile document and hence replaces it. Likewise, I wouldn't say "It > is based on LEMONADE profile [profile]" but perhaps "is an update of" > or something like that. Done. > Similarly, the text (which is later in the same section) "are > summarized in the LEMONADE profile [profile]" is confusing because > this document is the lemonade profile. I deleted this sentence, as I didn't think it provided any extra information. > I suggest deleting the text (later in this same section): > and mechanisms of the OMA MEM > Architecture [MEM-arch], following the LEMONADE point of view > described in the OMA MEM realization internet draft > [OMAMEMrealization]. Deleted. I've moved the reference to [MEM-arch] to the previous paragraph. > I think it might be confusing to readers who aren't looking to > implement OMA MEM, but just want to support email or mobile email. I > don't think this text is needed. The earlier part of the sentence > makes it clear that this supports OMA MEM. The reference to the OMA > MEM realization Internet Draft would be a problem if that draft is not > published as an RFC. Right, unless the reference is informative. > Likewise, the following text should be either deleted or moved to a > new section to be called something like "Notes on Supporting OMA MEM", > making clear that the section is to aid the working relationship > between lemonade and OMA MEM, and is to be deleted by the RFC Editor > prior to publication: > Also, it is to be noted that this document solely describes > normatively the LEMONADE profile bis. It discusses LEMONADE > understanding of the work in progress at OMA MEM ([MEM-req] and [MEM- > arch] but does not provide a normative reading of these documents. > Readers MUST refer to the Open Mobile Alliance web site for normative > references on the Mobile Email Enabler (OMA MEM). LEMONADE assumes > that the LEMONADE profile bis can be used as basis for an OMA > technical specification of a realization based on LEMONADE of the OMA > MEM enabler. I tend to agree with your comments that all OMA related topics should be grouped under a new top level section. If my co-editors agree with this, I will discuss with them the best way to do that > Section 3: Should BURL be here as well as in Section 2? At least a > short mention with reference to Section 2? I thought the section 5 defines the full list of IMAP and Submit extensions. Do you think that the section 3 also needs a pointer to BURL? > In Section 3.3, I don't like the quotes around 'expand' in 'MUST > "expand" all BURL'. I'd suggest either removing them, or change > 'expand' to 'dereference' RFC 4468 uses the term "resolve", so I updated the Profile document to use the same term. > . Although, in thinking about it, the wording could be taken the > wrong way. If the size of a message already exceeds a limit and there > are still BURL parts not yet expanded, there is no need for the server > to expand them. Correct. So the server can reject the last BURL chunk that caused the message to exceed server's limit. This is exactly the logic I've implemented in Isode Message Switch. > Perhaps something along the lines of "When including a message size in > the MAIL FROM command, clients MUST use a value that is at least as > large as the size of the message after expansion of all BURL parts. Good point. I've included this sentence. > Servers MUST NOT consider a message's size to be acceptable if it has > not expanded all BURL parts." I guess this is true, but I think the Profile document should provide more details: 1). If the client has specified SIZE MAIL FROM parameter and it is bigger than the maximum allowed by the server for the user, then the server MUST reject the message right away. 2). The server SHOULD verify "accumulated size" of the message after processing each BURL/BDAT chunk, but MAY do this after receiving all of them. > Section 4.3: I think we agreed to go with the alternate paragraph that > says "MUST provide [COMPRESS] support". Done. I will think about the rest of your comments: > Sections 6-9 should, I think, be moved to the new section I propose > above ("Notes on Supporting OMA MEM"). I don't want to confuse > non-OMA readers. > > In Section 9, the text " additional security measures like object > level encryption" is asking for trouble (I was going to say "raw meat > for the Security folks" but some of them may be vegetarian). Perhaps > it should be changed to "significant additional security > considerations" (although that too is really hand-waving). > > I like Section 10, but Sections 11-13 are difficult because they are > so intertwined with OMA references and considerations. I'm all for > making it clear how our model and protocols fit into OMA MEM, but I > also want to produce a stand-alone profile document that makes sense > to non-OMA people. I had been assuming that this document served that > purpose. > > In Section 14.3, "traverse firewalls" should be "deceive firewalls" > since firewalls can be traversed with no additional security > considerations. That's the job of the firewall. It's only when you > try to fool the firewall in order to subvert its configured policy > that you get into the additional issues. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 07:00:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0Rp-0006Gt-LO; Wed, 21 Jun 2006 07:00:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0Ro-0006Go-8e for lemonade@ietf.org; Wed, 21 Jun 2006 07:00:36 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft0Rn-00066b-LP for lemonade@ietf.org; Wed, 21 Jun 2006 07:00:36 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5LB0WdH030130; Wed, 21 Jun 2006 14:00:34 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 14:00:11 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 14:00:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Locating media servers for streaming Date: Wed, 21 Jun 2006 13:59:55 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446575A3509@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Locating media servers for streaming Thread-Index: AcaVINUWkVIYFZFxQWihDSzVsnjhsQAAC9fA From: To: X-OriginalArrivalTime: 21 Jun 2006 11:00:11.0424 (UTC) FILETIME=[DDCC2200:01C69521] X-Spam-Score: 0.2 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Well, I do know some things about the SDP - but I guess it is not as = much as I should. An example would be very helpful. I do not think I am the only guy who = is doing mostly email only and reading about SIP INVITE and SDP = regarding emails - and start wondering. :-) Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Neil Cook [mailto:neil.cook@noware.co.uk]=20 Sent: 21 June, 2006 13:46 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: lemonade@ietf.org Subject: Re: [lemonade] Locating media servers for streaming Zoltan, when the client contacts the media server, it provides the URL as a = parameter to the SIP INVITE as in my draft. What the draft doesn't go = into the details of is the SIP payload, which is SDP. SDP contains all = the media negotiation facilities required for this, and the client would = simply setup the correct SDP parameters to indicate which media is it = prepared to accept for this session. The reply to the invite contains = SDP parameters from the media server. I didn't go into the details of SIP/SDP in the draft, kind of assuming = that it was well understood, but I can flesh it out the fact that SDP = will be used for the media negotiation a little more. I gueess it is a = little presumptuous to assume that all messaging folks also know about = SDP. Neil. On 21 Jun 2006, at 11:23, = wrote: > Thank You Neil, > I would definiately prefer the new command - the client could always=20 > get up-to-date information according to its needs. > > Back to the second issue: I understand what You are saying, and I=20 > agree, however my question was more like: "Does the syntax support=20 > this and how to do this?" I mean, You get a BURL so You an stream the=20 > media from the media server. How can transcoding parameters be added=20 > to the BURL (so that You can tell the server that You could give me=20 > that content like this as well, just let me know which type it will=20 > be)? > > Thank You. > > Best regards: Zolt=E1n =D6rd=F6gh > E-mail: zoltan dot ordogh at nokia dot com > Phone: +358 50 386 0566 > > > -----Original Message----- > From: ext Neil Cook [mailto:neil.cook@noware.co.uk] > Sent: 20 June, 2006 17:48 > To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) > Cc: lemonade@ietf.org > Subject: Re: [lemonade] Locating media servers for streaming > > Zoltan, > > yes I was thinking of a separate command - the latest draft just=20 > posted contains a description of the problem and a high-level proposal = > for a solution similar to your suggestion below. I wanted to get a=20 > feeling for whether we should do this before going into command=20 > specifics. > > As for your second question, that is really a function of the media=20 > server. If the client presents a set of acceptable media in the SDP to = > the media server that is different from the media in the attachment,=20 > then the media server could transcode it, depending on its=20 > capabilities. So theoretically, yes. Of course there may not be a=20 > suitable transcoder from/to the supported media types, but that is an=20 > implementation issue. > > Neil. > > On 20 Jun 2006, at 11:52, =20 > wrote: > >> Could there be a separate command for this? (so that the client can=20 >> get the latest info if needed at any time) E.g. >> To get full mapping: >> C: GETMEDIASERVER >> S: Server1 (1.1.1.1: avi, divx, wmv, wma); Server2 (1.1.1.2: mov, rm, = >> mp3, ac3) >> >> To get a server that handles a particular type: >> C: GETMEDIASERVER avi >> S: Server1(1.1.1.1) >> >> Also, I have a question - perhaps it was described/discussed before,=20 >> apologies if it was: >> Can I stream a content that is being converted? >> E.g. I get an AC3 audio stream as attachment, can I stream it as >> MP3 instead? >> >> Thank You. >> >> Best regards: Zolt=E1n =D6rd=F6gh >> E-mail: zoltan dot ordogh at nokia dot com >> Phone: +358 50 386 0566 >> >> >> -----Original Message----- >> From: ext Neil Cook [mailto:neil.cook@noware.co.uk] >> Sent: 14 June, 2006 20:44 >> To: lemonade@ietf.org >> Subject: [lemonade] Locating media servers for streaming >> >> All, >> >> Been thinking about the potential problem of lemonade clients=20 >> locating a media server to use in reference to streaming a multimedia = >> attachment. >> >> There are several scenarios where media server location is >> *required*: >> >> 1) Discovery of media servers if client doesn't know *any* already. >> (How likely is this scenario? You would need a SIP-capable client=20 >> that is not configured with any media servers, which doesn't seem=20 >> incredibly likely) >> >> 2) Discovery of media servers that are authorised to access an IMAP=20 >> server, because it is configured to accept URLFETCH requests only=20 >> from certain media servers. >> >> There are also several scenarios where media server location is a=20 >> nice-to-have for other reasons such as security. I'm thinking of the=20 >> security implications of pawn-ticket URLs. The IMAP server could=20 >> return a media server address together with the username that the=20 >> media server uses to access the IMAP server, and thus the client=20 >> could generate a URL which was secure in that it could >> *only* be accessed by the media server in question. >> >> Any thoughts? >> >> Neil. >> >> >> _______________________________________________ >> lemonade mailing list >> lemonade@ietf.org >> https://www1.ietf.org/mailman/listinfo/lemonade >> >> _______________________________________________ >> lemonade mailing list >> lemonade@ietf.org >> https://www1.ietf.org/mailman/listinfo/lemonade > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 07:06:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0XL-0001Lc-Eu; Wed, 21 Jun 2006 07:06:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0XK-0001LS-3P for lemonade@ietf.org; Wed, 21 Jun 2006 07:06:18 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft0XI-0006SB-P1 for lemonade@ietf.org; Wed, 21 Jun 2006 07:06:18 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1Ft0XH-0000uk-Vb; Wed, 21 Jun 2006 11:06:16 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 9C063498003; Wed, 21 Jun 2006 12:06:51 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07039-02; Wed, 21 Jun 2006 12:06:46 +0100 (BST) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:2c20:733b:1c0f:85f5]) by turner.dave.cridland.net (Postfix) with ESMTP id 4A162498002; Wed, 21 Jun 2006 12:06:46 +0100 (BST) Date: Wed, 21 Jun 2006 12:05:48 +0100 Subject: Re: [lemonade] Notifications for multiple devices per user References: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> <666.1150807794.041102@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <1736.1150887949.021000@JOHN> From: Dave Cridland To: Lyndon Nerenberg Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Enhancements to Internet email to support diverse service enivronments , imap-protocol@u.washington.edu X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Jun 21 07:14:38 2006, Lyndon Nerenberg wrote: > Which leads me to conclude we desperately need a "Doh! Don't Do > IMAP Trash This Way, And Here's Why" RFC. Written in little tiny > syllables, with a lot of pictures. > > Well, I basically agree, so whilst I've not done the pictures, I've done my best to find and document the reasons why trash mailboxes are a bad idea on IMAP. Strangely, while thinking about them, I found a couple more (such as interaction with shared mailboxes, and reliance on UIDPLUS for any reasonable efficiency). See http://svn.dave.cridland.net/svn/ietf-drafts/draft-cridland-imap-trash.xml for some XML2RFC source, or temporarily http://dave.cridland.net/draft-cridland-imap-trash.txt I suggest that discussion of this, if anyone feels it's worthwhile, should probably take place on the IMAP protocol list, rather than here. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 08:33:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft1tJ-0007MD-TI; Wed, 21 Jun 2006 08:33:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft1tI-0007M8-9w for lemonade@ietf.org; Wed, 21 Jun 2006 08:33:04 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft1tG-00074P-Qk for lemonade@ietf.org; Wed, 21 Jun 2006 08:33:04 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5LCX0iS012207; Wed, 21 Jun 2006 15:33:01 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 15:33:00 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 15:32:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Notifications for multiple devices per user Date: Wed, 21 Jun 2006 15:32:41 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446575A3691@esebe199.NOE.Nokia.com> In-Reply-To: <1736.1150887634.498000@JOHN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: AcaVI8qFYovZ2VXQTE+7hGixIZBQPwAChJ5w From: To: X-OriginalArrivalTime: 21 Jun 2006 12:32:58.0512 (UTC) FILETIME=[D40A5900:01C6952E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave, I have this thought: If there was a MOVE command for IMAP, it would be easy I think. This (future) MOVE extension would move email(s) and/or folders (even = recursively if needed) without coping/deleting the emails directly to = another folder preserving the message-id. Then, the client could easily use MOVE to put all deleted messages to a = specific folder (Trash, Deleted item, etc), right? Then, there would be no need to use the flags at all - those messages in = the Trash folder would be just normal emails until the user decides to = permanently delete those emails. This should be easy to specify, right? Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Dave Cridland [mailto:dave@cridland.net]=20 Sent: 21 June, 2006 14:01 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: Enhancements to Internet email to support diverse service = enivronments; Burger, Eric; Randall Gellens; Ionescu Catalin = (Nokia-TP-MSW/Tampere) Subject: RE: [lemonade] Notifications for multiple devices per user On Wed Jun 21 11:15:29 2006, Zoltan.Ordogh@nokia.com wrote: > Thank You Dave and others, > Would it be possible to enhance this? I don't believe so, no. To present a trash mailbox similar to the typical desktop metaphor, you = would need to handle the equivalent of multi-mailbox backed virtual = folders whose backing was detirmined in realtime using wildcards = expanded according to the current user. I sincerely doubt that this is a practical proposition for many server = implementations, and it would be extremely difficult to specify. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 09:14:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2XX-0006Iv-NL; Wed, 21 Jun 2006 09:14:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2XW-0006Il-H4 for lemonade@ietf.org; Wed, 21 Jun 2006 09:14:38 -0400 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2XV-0002Dl-8h for lemonade@ietf.org; Wed, 21 Jun 2006 09:14:38 -0400 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 30E6DD80F12; Wed, 21 Jun 2006 09:14:35 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Wed, 21 Jun 2006 09:14:35 -0400 X-Sasl-enc: 7WiKpqNdqqryS3Fkae3wyKlWB+aiK0TRfrzHHuweHe9K 1150895675 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id CEBE9837E; Wed, 21 Jun 2006 09:14:32 -0400 (EDT) Date: Wed, 21 Jun 2006 09:14:30 -0400 From: Cyrus Daboo To: Dave Cridland , Lyndon Nerenberg Subject: Re: [lemonade] Notifications for multiple devices per user Message-ID: <3EFC3D2CFE5377EFDA5264A4@Cyrus-Daboo.local> In-Reply-To: <1736.1150887949.021000@JOHN> References: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> <666.1150807794.041102@peirce.dave.cridland.net> <1736.1150887949.021000@JOHN> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Enhancements to Internet email to support diverse service enivronments , imap-protocol@u.washington.edu X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dave, --On June 21, 2006 12:05:48 PM +0100 Dave Cridland wrote: > Well, I basically agree, so whilst I've not done the pictures, I've done > my best to find and document the reasons why trash mailboxes are a bad > idea on IMAP. I'm sorry but this is just wrong - if the Trash metaphor is what users are comfortable with then that's what the client should use. The protocol should not dictate how information is presented to the user and should be flexible enough (within limits) to provide ways for clients to do that. Lets face it, the main reason clients do Trash with IMAP is that that's what POP clients typically did plus users are already familiar and comfortable with that UI metaphor because that is what most file system browsers also use. I doubt very much it was done just because that's what the developers wanted. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 09:19:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2cA-0001iS-PY; Wed, 21 Jun 2006 09:19:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2c8-0001iM-Sq for lemonade@ietf.org; Wed, 21 Jun 2006 09:19:24 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2c4-0002LG-Dv for lemonade@ietf.org; Wed, 21 Jun 2006 09:19:24 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1Ft2c2-0006C0-VX; Wed, 21 Jun 2006 13:19:19 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 46BA4498004; Wed, 21 Jun 2006 14:19:56 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07948-09; Wed, 21 Jun 2006 14:19:47 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 7A612498002; Wed, 21 Jun 2006 14:19:47 +0100 (BST) Date: Wed, 21 Jun 2006 14:19:08 +0100 Subject: RE: [lemonade] Notifications for multiple devices per user References: <0FA975F2D8295A448BE3ADC1612446575A3691@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC1612446575A3691@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <666.1150895949.797061@peirce.dave.cridland.net> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Jun 21 13:32:41 2006, Zoltan.Ordogh@nokia.com wrote: > Dave, I have this thought: > If there was a MOVE command for IMAP, it would be easy I think. No, it's the same issue, albeit you miss out a round-trip. > This (future) MOVE extension would move email(s) and/or folders > (even recursively if needed) without coping/deleting the emails > directly to another folder preserving the message-id. RENAME already moves mailboxes. A MOVE is directly and completely equivalent to a sequence of COPY, STORE, UID EXPUNGE, albeit the latter requires UIDPLUS support. > Then, the client could easily use MOVE to put all deleted messages > to a specific folder (Trash, Deleted item, etc), right? Wrong. :-) > Then, there would be no need to use the flags at all - those > messages in the Trash folder would be just normal emails until the > user decides to permanently delete those emails. > This should be easy to specify, right? > > No. The problem is that this only works for personal mailboxes. Shared mailboxes would require a shared trash mailbox. For a shared trash mailbox, you'd need per-message ACLs, since you presumably want to have the same rights on a message both before and after it's deleted. Moreover, this wouldn't then work interoperably with all the existing clients which expect an in-situ two-stage deletion mechanism. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 09:21:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2eL-0004Dy-0k; Wed, 21 Jun 2006 09:21:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2eJ-00048w-Mx for lemonade@ietf.org; Wed, 21 Jun 2006 09:21:39 -0400 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2eI-0002QU-GJ for lemonade@ietf.org; Wed, 21 Jun 2006 09:21:39 -0400 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 2F236D80F83; Wed, 21 Jun 2006 09:21:37 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Wed, 21 Jun 2006 09:21:37 -0400 X-Sasl-enc: j3yIwc6Vnw8LAUFnhCLm2cSTdUcW/XFxneAZl3vJfEXZ 1150896097 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 2E0D7837A; Wed, 21 Jun 2006 09:21:35 -0400 (EDT) Date: Wed, 21 Jun 2006 09:21:34 -0400 From: Cyrus Daboo To: Zoltan.Ordogh@nokia.com, dave@cridland.net Subject: RE: [lemonade] Notifications for multiple devices per user Message-ID: <258D28C285E18A04F5D7A5B1@Cyrus-Daboo.local> In-Reply-To: <0FA975F2D8295A448BE3ADC1612446575A3691@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446575A3691@esebe199.NOE.Nokia.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Zoltan, --On June 21, 2006 3:32:41 PM +0300 Zoltan.Ordogh@nokia.com wrote: > Dave, I have this thought: > If there was a MOVE command for IMAP, it would be easy I think. > This (future) MOVE extension would move email(s) and/or folders (even > recursively if needed) without coping/deleting the emails directly to > another folder preserving the message-id. Then, the client could easily > use MOVE to put all deleted messages to a specific folder (Trash, Deleted > item, etc), right? Then, there would be no need to use the flags at all - > those messages in the Trash folder would be just normal emails until the > user decides to permanently delete those emails. This should be easy to > specify, right? Unfortunately the idea of MOVE has been shot down many times in the past - I suggest you review IMAP and IMAPext mailing lists to see the discussion of all that. Frankly its not worth fighting to get it now. Yes it would make Trash and move operations (which are a much more common user action than a copy) more reliable - but server vendors in the past have made it plain that its 'hard' to do so there was never any interest in implementing. Frankly I think the discussion of a statement that clients should not use Trash is all wrong - what we should do is write a 'best common practices for implementing Trash properly with IMAP' document to help client author's get it done right (subject to the limitations that do exist). -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 09:34:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2qZ-0004BF-JD; Wed, 21 Jun 2006 09:34:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2qX-0004B6-Ld for lemonade@ietf.org; Wed, 21 Jun 2006 09:34:17 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2qW-00045l-6l for lemonade@ietf.org; Wed, 21 Jun 2006 09:34:17 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1Ft2qV-0006q0-Hl; Wed, 21 Jun 2006 13:34:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 4B07C498003; Wed, 21 Jun 2006 14:34:52 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08188-03; Wed, 21 Jun 2006 14:34:48 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id BB398498002; Wed, 21 Jun 2006 14:34:48 +0100 (BST) Date: Wed, 21 Jun 2006 14:34:09 +0100 Subject: Re: [lemonade] Notifications for multiple devices per user References: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> <666.1150807794.041102@peirce.dave.cridland.net> <1736.1150887949.021000@JOHN> <3EFC3D2CFE5377EFDA5264A4@Cyrus-Daboo.local> In-Reply-To: <3EFC3D2CFE5377EFDA5264A4@Cyrus-Daboo.local> MIME-Version: 1.0 Message-Id: <666.1150896850.579833@peirce.dave.cridland.net> From: Dave Cridland To: Cyrus Daboo Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Enhancements to Internet email to support diverse service enivronments , Lyndon Nerenberg , imap-protocol@u.washington.edu X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Jun 21 14:14:30 2006, Cyrus Daboo wrote: > --On June 21, 2006 12:05:48 PM +0100 Dave Cridland > wrote: > >> Well, I basically agree, so whilst I've not done the pictures, >> I've done >> my best to find and document the reasons why trash mailboxes are a >> bad >> idea on IMAP. > > I'm sorry but this is just wrong - if the Trash metaphor is what > users are comfortable with then that's what the client should use. > The protocol should not dictate how information is presented to the > user and should be flexible enough (within limits) to provide ways > for clients to do that. > > But the protocol simply doesn't provide that, and without some quite extraordinary server support, it won't. I'm sure it's possible, in principle, for a server to present a Trash mailbox that is automatically populated with all messages marked with the \Deleted flag in any mailbox the current user has access to, but for the vast majority of implementations, I think that's impractical. > Lets face it, the main reason clients do Trash with IMAP is that > that's what POP clients typically did plus users are already > familiar and comfortable with that UI metaphor because that is what > most file system browsers also use. I doubt very much it was done > just because that's what the developers wanted. Indeed, users are familiar with a trash container with a relatively wide scope, and many client authors have provided such a container at either client-wide or server-wide scope. The only mechanism I can see for providing that in client-side IMAP would involve continuously searching all available mailboxes for messages marked as \Deleted, and presenting the results as a locally generated virtual mailbox, or else using a real mailbox as an artificial trash mailbox, which has both interoperability and (lesser) efficiency problems. The closest I can provide is a per-mailbox trash container, which is, I agree, a considerably reduced scope by comparison to what's typically implemented, and therefore expected, by the user. On the plus side, such a mechanism is fully interoperable with any server or client conforming to RFC3501 (Or, I think, even much older specifications). You state in another message that what we should do in write a "best common practises for implementing Trash properly with IMAP", and that's one aim of what I've written - it may well be that there's a much better method for providing a metaphor closer to the expectation of the typical user, but I don't see it. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 09:43:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2yy-000817-Oj; Wed, 21 Jun 2006 09:43:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2yx-000812-Sw for lemonade@ietf.org; Wed, 21 Jun 2006 09:42:59 -0400 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2yw-0004k1-Mx for lemonade@ietf.org; Wed, 21 Jun 2006 09:42:59 -0400 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id D4B6ED80EA7; Wed, 21 Jun 2006 09:42:57 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Wed, 21 Jun 2006 09:42:58 -0400 X-Sasl-enc: ownnW7qHyjm105GpdNKBJcxYehIls2xKEAwCfYvg29P8 1150897377 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id BCC868379; Wed, 21 Jun 2006 09:42:55 -0400 (EDT) Date: Wed, 21 Jun 2006 09:42:53 -0400 From: Cyrus Daboo To: Dave Cridland Subject: Re: [lemonade] Notifications for multiple devices per user Message-ID: In-Reply-To: <666.1150896850.579833@peirce.dave.cridland.net> References: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> <666.1150807794.041102@peirce.dave.cridland.net> <1736.1150887949.021000@JOHN> <3EFC3D2CFE5377EFDA5264A4@Cyrus-Daboo.local> <666.1150896850.579833@peirce.dave.cridland.net> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Enhancements to Internet email to support diverse service enivronments , imap-protocol@u.washington.edu X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dave, --On June 21, 2006 2:34:09 PM +0100 Dave Cridland wrote: > The only mechanism I can see for providing that in client-side IMAP would > involve continuously searching all available mailboxes for messages > marked as \Deleted, and presenting the results as a locally generated > virtual mailbox, or else using a real mailbox as an artificial trash > mailbox, which has both interoperability and (lesser) efficiency problems. But that is exactly what I am talking about as that's how clients have already implemented it and that's what all the complaints about interop have been about. I don't care about 'virtual' trash - just about making the copy-to-Trash work (which for the most part it does). -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 11:06:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4HZ-00053w-Vf; Wed, 21 Jun 2006 11:06:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4HX-00053q-Vm for lemonade@ietf.org; Wed, 21 Jun 2006 11:06:15 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4HW-0006qj-Hj for lemonade@ietf.org; Wed, 21 Jun 2006 11:06:15 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1Ft4HV-0004PI-Ti; Wed, 21 Jun 2006 15:06:14 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 412F8498003; Wed, 21 Jun 2006 16:06:51 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08851-03; Wed, 21 Jun 2006 16:06:46 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 2BE16498002; Wed, 21 Jun 2006 16:06:43 +0100 (BST) Date: Wed, 21 Jun 2006 16:05:59 +0100 Subject: Re: [lemonade] Notifications for multiple devices per user References: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> <666.1150807794.041102@peirce.dave.cridland.net> <1736.1150887949.021000@JOHN> <3EFC3D2CFE5377EFDA5264A4@Cyrus-Daboo.local> <666.1150896850.579833@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <666.1150902364.794593@peirce.dave.cridland.net> From: Dave Cridland To: Cyrus Daboo Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Enhancements to Internet email to support diverse service enivronments , imap-protocol@u.washington.edu X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Jun 21 14:42:53 2006, Cyrus Daboo wrote: > Hi Dave, > > --On June 21, 2006 2:34:09 PM +0100 Dave Cridland > wrote: > >> The only mechanism I can see for providing that in client-side >> IMAP would >> involve continuously searching all available mailboxes for messages >> marked as \Deleted, and presenting the results as a locally >> generated >> virtual mailbox, or else using a real mailbox as an artificial >> trash >> mailbox, which has both interoperability and (lesser) efficiency >> problems. > > But that is exactly what I am talking about as that's how clients > have already implemented it and that's what all the complaints > about interop have been about. I don't care about 'virtual' trash - > just about making the copy-to-Trash work (which for the most part > it does). I could suggest a method for finding the name of the mailbox to use, I suppose, by using NAMESPACE, but that adds another extension. I don't like relying on extensions to handle cases like deletion. Most of the other problems are insoluble, and I'm not even sure that "for the most part it does" is true, unless you only use clients that do a compatible trash mailbox. Of course, there are especially poor ways to do trash mailboxes, and I can add text to warn against them. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 11:43:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4rR-0005xd-F4; Wed, 21 Jun 2006 11:43:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4rP-0005xY-KQ for lemonade@ietf.org; Wed, 21 Jun 2006 11:43:19 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4rO-0000Vk-9n for lemonade@ietf.org; Wed, 21 Jun 2006 11:43:19 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5LFhELq030480; Wed, 21 Jun 2006 08:43:14 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5LFh6mB026975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jun 2006 08:43:14 -0700 Date: Wed, 21 Jun 2006 08:43:06 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo Subject: RE: [lemonade] Notifications for multiple devices per user In-Reply-To: <258D28C285E18A04F5D7A5B1@Cyrus-Daboo.local> Message-ID: References: <0FA975F2D8295A448BE3ADC1612446575A3691@esebe199.NOE.Nokia.com> <258D28C285E18A04F5D7A5B1@Cyrus-Daboo.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org, Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 21 Jun 2006, Cyrus Daboo wrote: > Frankly I think the discussion of a statement that clients should not use > Trash is all wrong - what we should do is write a 'best common practices for > implementing Trash properly with IMAP' document to help client author's get > it done right (subject to the limitations that do exist). Clients definitely should NOT use a mailbox as Trash in the IMAP protocol. What clients present to the user as a graphical interface is another matter entirely. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 11:46:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4uf-0000fT-Vq; Wed, 21 Jun 2006 11:46:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4uf-0000dz-Ht for lemonade@ietf.org; Wed, 21 Jun 2006 11:46:41 -0400 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4ue-0001Np-Ai for lemonade@ietf.org; Wed, 21 Jun 2006 11:46:41 -0400 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 5A0DED80ED4; Wed, 21 Jun 2006 11:46:39 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Wed, 21 Jun 2006 11:46:40 -0400 X-Sasl-enc: UjtGwGCBHBPpNAJBaCedwWDAow1wrpRaOz4LPNzCP5tA 1150904799 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 788288412; Wed, 21 Jun 2006 11:46:35 -0400 (EDT) Date: Wed, 21 Jun 2006 11:46:32 -0400 From: Cyrus Daboo To: Mark Crispin Subject: RE: [lemonade] Notifications for multiple devices per user Message-ID: In-Reply-To: References: <0FA975F2D8295A448BE3ADC1612446575A3691@esebe199.NOE.Nokia.com> <258D28C285E18A04F5D7A5B1@Cyrus-Daboo.local> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: lemonade@ietf.org, Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Mark, --On June 21, 2006 8:43:06 AM -0700 Mark Crispin wrote: >> Frankly I think the discussion of a statement that clients should not >> use Trash is all wrong - what we should do is write a 'best common >> practices for implementing Trash properly with IMAP' document to help >> client author's get it done right (subject to the limitations that do >> exist). > > Clients definitely should NOT use a mailbox as Trash in the IMAP protocol. > > What clients present to the user as a graphical interface is another > matter entirely. Well how are you supposed to do trash accumulated from multiple mailboxes? And no, having a 'virtual' trash per-mailbox is not acceptable. -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 12:15:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5MD-0003rg-B6; Wed, 21 Jun 2006 12:15:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5MB-0003rb-FB for lemonade@ietf.org; Wed, 21 Jun 2006 12:15:07 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5MA-0004gf-2l for lemonade@ietf.org; Wed, 21 Jun 2006 12:15:07 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5LGF2vC009545; Wed, 21 Jun 2006 09:15:02 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5LGF03O015102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jun 2006 09:15:01 -0700 Date: Wed, 21 Jun 2006 09:15:00 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo Subject: RE: [lemonade] Notifications for multiple devices per user In-Reply-To: Message-ID: References: <0FA975F2D8295A448BE3ADC1612446575A3691@esebe199.NOE.Nokia.com> <258D28C285E18A04F5D7A5B1@Cyrus-Daboo.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: lemonade@ietf.org, Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 21 Jun 2006, Cyrus Daboo wrote: >> Clients definitely should NOT use a mailbox as Trash in the IMAP protocol. >> What clients present to the user as a graphical interface is another >> matter entirely. > Well how are you supposed to do trash accumulated from multiple mailboxes? > And no, having a 'virtual' trash per-mailbox is not acceptable. Well how are you supposed to put back a message from the trash without causing a new instance of that message? You can't if you use a trash mailbox! Sometimes, it just isn't possible to get everything that you want; and you have to choose the least harmful alternative. Personally, I think that it is overrated to have a feature of having a trash that, at all times, holds all deleted messages in all mailboxes. There simply is no user expectation of a corresponding feature in any other facility! Filesystems? If you study the Windows or Macintosh filesystems carefully (I have), you'll discover that the trash is far less integrated that you might expect. You MAY have trash sharing between two local hard drives, but typically not with network mounted filesystems. Removable filesystems often implement dragging to trash as immediate delete then expunge with no undelete possible. If you unmount a hard drive, its part of the trash is immediately emptied. To put it another way, the designers of trash in other contexts have not attempted to do what is alleged to be "necessary" in IMAP. When you talk about "user expectations", you really mean an expectation that you created. In the course of creating that expectation, you damage other expectations that IMAP intended to offer. One of these damaged expectations is the ability, when over disk quota, to be able to delete some data and by doing so get under disk quota. Another one is the ability to undo a delete. IMAP delete is undoable, but moving to a trash mailbox is not. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 12:16:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5Nl-000424-Mu; Wed, 21 Jun 2006 12:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5Nl-00041y-Av for lemonade@ietf.org; Wed, 21 Jun 2006 12:16:45 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5Nj-0004jL-WF for lemonade@ietf.org; Wed, 21 Jun 2006 12:16:45 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5LGGcQP010678; Wed, 21 Jun 2006 09:16:39 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k5LGGbTO004588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jun 2006 09:16:38 -0700 Date: Wed, 21 Jun 2006 09:16:37 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] Notifications for multiple devices per user In-Reply-To: <6AzD+yL1wTp2/TKGB7SJVg.md5@libertango.oryx.com> Message-ID: References: <0FA975F2D8295A448BE3ADC1612446575A3691@esebe199.NOE.Nokia.com> <258D28C285E18A04F5D7A5B1@Cyrus-Daboo.local> <6AzD+yL1wTp2/TKGB7SJVg.md5@libertango.oryx.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: lemonade@ietf.org, Cyrus Daboo , Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 21 Jun 2006, Arnt Gulbrandsen wrote: > Mark Crispin writes: >> Clients definitely should NOT use a mailbox as Trash in the IMAP protocol. >> What clients present to the user as a graphical interface is another matter >> entirely. > How about LISTing all of the user's mailboxes, SELECTing each in turn, and > using SEARCH DELETED to present a Trash mailbox? That's a very good thing for a competitor's client to do, especially if you also control the server. Anything that makes your competitor's product work substantially worse than your product is always a good thing. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 14:50:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7m3-0003VU-9p; Wed, 21 Jun 2006 14:49:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7m2-0003VP-AV for lemonade@ietf.org; Wed, 21 Jun 2006 14:49:58 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft7m0-0004xr-UC for lemonade@ietf.org; Wed, 21 Jun 2006 14:49:58 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LInsvH003708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 11:49:55 -0700 Received: from [129.46.172.15] (vpn-10-50-16-21.qualcomm.com [10.50.16.21]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LIno0w006359; Wed, 21 Jun 2006 11:49:51 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> <666.1150807794.041102@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 21 Jun 2006 11:48:12 -0700 To: Lyndon Nerenberg From: Randall Gellens Subject: Re: [lemonade] Notifications for multiple devices per user Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:14 PM -0700 6/20/06, Lyndon Nerenberg wrote: >> Are there clients that present deleted messages as being in a >> (virtual) trash mailbox? > > I have yet to come across one. All the non-trash-folder clients > I've worked with provide a switch that makes the deleted messages > visible (or not) in the folder's message index list. > >> I suppose one concern would be user confusion: if the user looks >> at the mailboxes using another client or a web interface, the >> virtual trash mailbox would not be there. > > Which leads me to conclude we desperately need a "Doh! Don't Do > IMAP Trash This Way, And Here's Why" RFC. Written in little tiny > syllables, with a lot of pictures. Don't do IMAP trash which way? The Trash mailbox, the show/hide deleted messages, or the virtual trash mailbox way? > Why is it so hard for client writers to grok this concept? I'm not > asking this rhetorically. It's such a simple concept that I'm > stunned by how hard it seems to be for people to wrap their heads > around it. What do we need to do to explain the concept in a way > that everyone "gets it" ??? Which concept (sorry for being dense)? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Procedures! Of course, that's what you'd use with a *sophisticated* machine like this. Procedures. --'Ceaser Smith' in _Hot_Millions_ _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 14:58:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7tt-0000mO-8m; Wed, 21 Jun 2006 14:58:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7tl-0000mE-15 for lemonade@ietf.org; Wed, 21 Jun 2006 14:57:57 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft7tj-00069E-Lx for lemonade@ietf.org; Wed, 21 Jun 2006 14:57:57 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LIvrCA008819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 11:57:54 -0700 Received: from [129.46.172.15] (vpn-10-50-16-21.qualcomm.com [10.50.16.21]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LIvpfc028863; Wed, 21 Jun 2006 11:57:52 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44980246.7010201@isode.com> References: <44980246.7010201@isode.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 21 Jun 2006 11:57:46 -0700 To: Alexey Melnikov From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 3:12 PM +0100 6/20/06, Alexey Melnikov wrote: > Randall Gellens wrote: >> I think it might be confusing to readers who aren't looking to >> implement OMA MEM, but just want to support email or mobile email. >> I don't think this text is needed. The earlier part of the >> sentence makes it clear that this supports OMA MEM. The reference >> to the OMA MEM realization Internet Draft would be a problem if >> that draft is not published as an RFC. > > Right, unless the reference is informative. Even then it is unfortunate, I think, because people reading the profile-bis RFC will see a reference to an expired draft. >> Section 3: Should BURL be here as well as in Section 2? At least >> a short mention with reference to Section 2? > > I thought the section 5 defines the full list of IMAP and Submit > extensions. Do you think that the section 3 also needs a pointer to > BURL? Just for clarity, I think. >> . Although, in thinking about it, the wording could be taken the >> wrong way. If the size of a message already exceeds a limit and >> there are still BURL parts not yet expanded, there is no need for >> the server to expand them. > > Correct. So the server can reject the last BURL chunk that caused > the message to exceed server's limit. > This is exactly the logic I've implemented in Isode Message Switch. > >> Perhaps something along the lines of "When including a message >> size in the MAIL FROM command, clients MUST use a value that is at >> least as large as the size of the message after expansion of all >> BURL parts. > > Good point. I've included this sentence. > >> Servers MUST NOT consider a message's size to be acceptable if it >> has not expanded all BURL parts." > > I guess this is true, but I think the Profile document should > provide more details: > 1). If the client has specified SIZE MAIL FROM parameter and it is > bigger than the maximum allowed by the server for the user, then > the server MUST reject the message right away. Yes, it would be bad for servers to reject a message after submission when it could have been rejected at MAIL FROM. > 2). The server SHOULD verify "accumulated size" of the message > after processing each BURL/BDAT chunk, but MAY do this after > receiving all of them. I agree. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- When a man's best friend is his dog, that dog has a problem. --Edward Abbey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 15:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8Nn-0004sL-2w; Wed, 21 Jun 2006 15:28:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8Nm-0004jG-0i for lemonade@ietf.org; Wed, 21 Jun 2006 15:28:58 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft8Nj-0007lk-M8 for lemonade@ietf.org; Wed, 21 Jun 2006 15:28:57 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LJSrAT008017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 12:28:54 -0700 Received: from [129.46.172.15] (vpn-10-50-16-21.qualcomm.com [10.50.16.21]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LJSpAa014499; Wed, 21 Jun 2006 12:28:52 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC1612446575A3691@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446575A3691@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 21 Jun 2006 12:25:42 -0700 To: From: Randall Gellens Subject: RE: [lemonade] Notifications for multiple devices per user Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 3:32 PM +0300 6/21/06, wrote: > If there was a MOVE command for IMAP, it would be easy I think. > This (future) MOVE extension would move email(s) and/or folders > (even recursively if needed) without coping/deleting the emails > directly to another folder preserving the message-id. > Then, the client could easily use MOVE to put all deleted messages > to a specific folder (Trash, Deleted item, etc), right? > Then, there would be no need to use the flags at all - those > messages in the Trash folder would be just normal emails until the > user decides to permanently delete those emails. > This should be easy to specify, right? The UIDPLUS extension allows a client to do a COPY and learn the UID of the message in its new mailbox. This becomes effectively a MOVE. However, with this or your MOVE suggestion, no other client knows what happened. To other clients, it appears that a message was deleted and a new message appeared in a different mailbox. Other clients don't know these are the same message. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I have made it a rule, whenever in my power, to avoid becoming the draughtsman of papers to be reviewed by a public body. --Benjamin Franklin _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 15:37:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8WT-0000Zj-RO; Wed, 21 Jun 2006 15:37:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8WS-0000Ze-7p for lemonade@ietf.org; Wed, 21 Jun 2006 15:37:56 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft8WQ-00015a-UH for lemonade@ietf.org; Wed, 21 Jun 2006 15:37:56 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LJbpSl008883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 12:37:52 -0700 Received: from [129.46.172.15] (vpn-10-50-16-21.qualcomm.com [10.50.16.21]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LJbobJ013995; Wed, 21 Jun 2006 12:37:51 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0FA975F2D8295A448BE3ADC1612446575A3691@esebe199.NOE.Nokia.com> <258D28C285E18A04F5D7A5B1@Cyrus-Daboo.local> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 21 Jun 2006 12:36:07 -0700 To: Cyrus Daboo From: Randall Gellens Subject: RE: [lemonade] Notifications for multiple devices per user Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 11:46 AM -0400 6/21/06, Cyrus Daboo wrote: > Well how are you supposed to do trash accumulated from multiple > mailboxes? And no, having a 'virtual' trash per-mailbox is not > acceptable. Is the problem with presenting a client-generated virtual Trash mailbox that it would only contain messages in mailboxes that have been locally synched? I suppose clients could present a Trash mailbox that contains child mailboxes, each of which has the same name as a mailbox that the client synchronizes. That might help, but I'm not sure. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The fewer episodes of a TV show one has seen, the greater the chance that one has already viewed the episode one is watching. --Randall Gellens _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 15:50:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8iG-0000aD-JY; Wed, 21 Jun 2006 15:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8iB-0000Wc-3m; Wed, 21 Jun 2006 15:50:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft8i9-0002sn-Uc; Wed, 21 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5LJo1Hp029715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ft8i9-0003l7-Cl; Wed, 21 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-notification-protocol-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Lemonade Notification protocol Author(s) : S. Maes Filename : draft-ietf-lemonade-notification-protocol-00.txt Pages : 8 Date : 2006-6-21 This document introduces a notification protocol as a specified particular case of the notification mechanisms used by the Lemonade profile [LEMONADEPROFILEBIS] in [NOTIFICATIONS]. This document also discusses the use of Lemonade notifications to implement server to server notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notification-protocol-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-notification-protocol-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-notification-protocol-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-21102100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-notification-protocol-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-notification-protocol-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-21102100.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Wed Jun 21 17:47:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAY8-0006oK-HD; Wed, 21 Jun 2006 17:47:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtASZ-0003HY-4f for lemonade@ietf.org; Wed, 21 Jun 2006 17:42:03 -0400 Received: from [2002:d159:4635::1] (helo=orthanc.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtAPJ-0000nk-Bf for lemonade@ietf.org; Wed, 21 Jun 2006 17:38:42 -0400 Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by orthanc.ca (8.13.4/8.13.4) with ESMTP id k5LLcYw5094134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jun 2006 15:38:35 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Wed, 21 Jun 2006 15:38:34 -0600 (MDT) From: Lyndon Nerenberg To: Randall Gellens Subject: Re: [lemonade] Notifications for multiple devices per user In-Reply-To: Message-ID: <20060621153758.D94015@orthanc.ca> References: <0FA975F2D8295A448BE3ADC16124465754DC92@esebe199.NOE.Nokia.com> <666.1150807794.041102@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on orthanc.ca X-Spam-Score: -2.8 (--) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Don't do IMAP trash which way? The Trash mailbox, the show/hide deleted > messages, or the virtual trash mailbox way? Sorry ... I was referring to the "move it all into a single Trash mailbox" model. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 20:36:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDBq-0006Jv-HT; Wed, 21 Jun 2006 20:36:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4yO-0002yt-Hu for lemonade@ietf.org; Wed, 21 Jun 2006 11:50:32 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4yL-0002GC-46 for lemonade@ietf.org; Wed, 21 Jun 2006 11:50:32 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id F3D8B4AC7F; Wed, 21 Jun 2006 17:50:27 +0200 (CEST) Message-Id: <6AzD+yL1wTp2/TKGB7SJVg.md5@libertango.oryx.com> Date: Wed, 21 Jun 2006 17:50:47 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Notifications for multiple devices per user References: <0FA975F2D8295A448BE3ADC1612446575A3691@esebe199.NOE.Nokia.com> <258D28C285E18A04F5D7A5B1@Cyrus-Daboo.local> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Wed, 21 Jun 2006 20:36:55 -0400 Cc: Daboo , Mark Crispin , Cyrus, Zoltan.Ordogh@nokia.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin writes: > Clients definitely should NOT use a mailbox as Trash in the IMAP protocol. > > What clients present to the user as a graphical interface is another > matter entirely. How about LISTing all of the user's mailboxes, SELECTing each in turn, and using SEARCH DELETED to present a Trash mailbox? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 20:36:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDBp-0006JL-Mg; Wed, 21 Jun 2006 20:36:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fszkd-0004Cr-2o for lemonade@ietf.org; Wed, 21 Jun 2006 06:15:59 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fszkb-0002Kg-LJ for lemonade@ietf.org; Wed, 21 Jun 2006 06:15:59 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5LAFpUj016635; Wed, 21 Jun 2006 13:15:51 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 13:15:50 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 13:15:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Notifications for multiple devices per user Date: Wed, 21 Jun 2006 13:15:29 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446575A345E@esebe199.NOE.Nokia.com> In-Reply-To: <636.1150807299.833000@JOHN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for m From lemonade-bounces@ietf.org Wed Jun 21 20:37:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDBq-0006JX-8p; Wed, 21 Jun 2006 20:36:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0SI-0006Jm-TB for lemonade@ietf.org; Wed, 21 Jun 2006 07:01:06 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft0SH-00067t-JD for lemonade@ietf.org; Wed, 21 Jun 2006 07:01:06 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1Ft0SF-0002Zh-Pk; Wed, 21 Jun 2006 11:01:03 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 336A9498002; Wed, 21 Jun 2006 12:01:40 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06980-04; Wed, 21 Jun 2006 12:01:31 +0100 (BST) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:2c20:733b:1c0f:85f5]) by turner.dave.cridland.net (Postfix) with ESMTP id AD910498003; Wed, 21 Jun 2006 12:01:31 +0100 (BST) Date: Wed, 21 Jun 2006 12:00:32 +0100 Subject: RE: [lemonade] Notifications for multiple devices per user References: <0FA975F2D8295A448BE3ADC1612446575A345E@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC1612446575A345E@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <1736.1150887634.498000@JOHN> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Wed, 21 Jun 2006 20:36:54 -0400 Cc: Enhancements to Internet email to support diverse service enivronments , Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Jun 21 11:15:29 2006, Zoltan.Ordogh@nokia.com wrote: > Thank You Dave and others, > Would it be possible to enhance this? I don't believe so, no. To present a trash mailbox similar to the typical desktop metaphor, you would need to handle the equivalent of multi-mailbox backed virtual folders whose backing was detirmined in realtime using wildcards expanded according to the current user. I sincerely doubt that this is a practical proposition for many server implementations, and it would be extremely difficult to specify. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 20:37:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDBq-0006Jj-D4; Wed, 21 Jun 2006 20:36:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft1Ba-0003Kp-V5 for lemonade@ietf.org; Wed, 21 Jun 2006 07:47:54 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft1BZ-0003kT-FB for lemonade@ietf.org; Wed, 21 Jun 2006 07:47:54 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5LBlkWr026668; Wed, 21 Jun 2006 14:47:47 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 14:47:19 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 14:47:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Notifications for multiple devices per user Date: Wed, 21 Jun 2006 14:47:02 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446575A35D2@esebe199.NOE.Nokia.com> In-Reply-To: <1736.1150887634.498000@JOHN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: AcaVI8qFYovZ2VXQTE+7hGixIZBQPwABJUHA From: To: X-OriginalArrivalTime: 21 Jun 2006 11:47:19.0053 (UTC) FILETIME=[733213D0:01C69528] X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Wed, 21 Jun 2006 20:36:55 -0400 Cc: lemonade@ietf.org, randy@qualcomm.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ok, thank You. It seems I must accept this fact.=20 Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Dave Cridland [mailto:dave@cridland.net]=20 Sent: 21 June, 2006 14:01 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: Enhancements to Internet email to support diverse service = enivronments; Burger, Eric; Randall Gellens; Ionescu Catalin = (Nokia-TP-MSW/Tampere) Subject: RE: [lemonade] Notifications for multiple devices per user On Wed Jun 21 11:15:29 2006, Zoltan.Ordogh@nokia.com wrote: > Thank You Dave and others, > Would it be possible to enhance this? I don't believe so, no. To present a trash mailbox similar to the typical desktop metaphor, you = would need to handle the equivalent of multi-mailbox backed virtual = folders whose backing was detirmined in realtime using wildcards = expanded according to the current user. I sincerely doubt that this is a practical proposition for many server = implementations, and it would be extremely difficult to specify. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 20:37:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDBq-0006JX-8p; Wed, 21 Jun 2006 20:36:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0SI-0006Jm-TB for lemonade@ietf.org; Wed, 21 Jun 2006 07:01:06 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft0SH-00067t-JD for lemonade@ietf.org; Wed, 21 Jun 2006 07:01:06 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1Ft0SF-0002Zh-Pk; Wed, 21 Jun 2006 11:01:03 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 336A9498002; Wed, 21 Jun 2006 12:01:40 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06980-04; Wed, 21 Jun 2006 12:01:31 +0100 (BST) Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:2c20:733b:1c0f:85f5]) by turner.dave.cridland.net (Postfix) with ESMTP id AD910498003; Wed, 21 Jun 2006 12:01:31 +0100 (BST) Date: Wed, 21 Jun 2006 12:00:32 +0100 Subject: RE: [lemonade] Notifications for multiple devices per user References: <0FA975F2D8295A448BE3ADC1612446575A345E@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC1612446575A345E@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <1736.1150887634.498000@JOHN> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Wed, 21 Jun 2006 20:36:54 -0400 Cc: Enhancements to Internet email to support diverse service enivronments , Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Jun 21 11:15:29 2006, Zoltan.Ordogh@nokia.com wrote: > Thank You Dave and others, > Would it be possible to enhance this? I don't believe so, no. To present a trash mailbox similar to the typical desktop metaphor, you would need to handle the equivalent of multi-mailbox backed virtual folders whose backing was detirmined in realtime using wildcards expanded according to the current user. I sincerely doubt that this is a practical proposition for many server implementations, and it would be extremely difficult to specify. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 20:37:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDBq-0006Jj-D4; Wed, 21 Jun 2006 20:36:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft1Ba-0003Kp-V5 for lemonade@ietf.org; Wed, 21 Jun 2006 07:47:54 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft1BZ-0003kT-FB for lemonade@ietf.org; Wed, 21 Jun 2006 07:47:54 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5LBlkWr026668; Wed, 21 Jun 2006 14:47:47 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 14:47:19 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 14:47:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Notifications for multiple devices per user Date: Wed, 21 Jun 2006 14:47:02 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446575A35D2@esebe199.NOE.Nokia.com> In-Reply-To: <1736.1150887634.498000@JOHN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: AcaVI8qFYovZ2VXQTE+7hGixIZBQPwABJUHA From: To: X-OriginalArrivalTime: 21 Jun 2006 11:47:19.0053 (UTC) FILETIME=[733213D0:01C69528] X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Wed, 21 Jun 2006 20:36:55 -0400 Cc: lemonade@ietf.org, randy@qualcomm.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ok, thank You. It seems I must accept this fact.=20 Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Dave Cridland [mailto:dave@cridland.net]=20 Sent: 21 June, 2006 14:01 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: Enhancements to Internet email to support diverse service = enivronments; Burger, Eric; Randall Gellens; Ionescu Catalin = (Nokia-TP-MSW/Tampere) Subject: RE: [lemonade] Notifications for multiple devices per user On Wed Jun 21 11:15:29 2006, Zoltan.Ordogh@nokia.com wrote: > Thank You Dave and others, > Would it be possible to enhance this? I don't believe so, no. To present a trash mailbox similar to the typical desktop metaphor, you = would need to handle the equivalent of multi-mailbox backed virtual = folders whose backing was detirmined in realtime using wildcards = expanded according to the current user. I sincerely doubt that this is a practical proposition for many server = implementations, and it would be extremely difficult to specify. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 21 20:51:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDPQ-0003Zh-Av; Wed, 21 Jun 2006 20:51:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDPP-0003VR-5c for lemonade@ietf.org; Wed, 21 Jun 2006 20:50:59 -0400 Received: from pathbreaker.com ([64.71.130.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FtDPN-00040b-Ow for lemonade@ietf.org; Wed, 21 Jun 2006 20:50:59 -0400 Received: (qmail 7450 invoked by uid 89); 22 Jun 2006 00:50:01 -0000 Received: from localhost (HELO ?192.168.1.105?) (ray%logicaldepth.com@127.0.0.1) by 0 with SMTP; 22 Jun 2006 00:50:01 -0000 Message-ID: <4499E95F.1000606@pathbreaker.com> Date: Wed, 21 Jun 2006 17:50:39 -0700 From: Ray Cromwell User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] Notifications for multiple devices per user References: <0FA975F2D8295A448BE3ADC1612446575A3691@esebe199.NOE.Nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > > The UIDPLUS extension allows a client to do a COPY and learn the UID > of the message in its new mailbox. This becomes effectively a MOVE. > However, with this or your MOVE suggestion, no other client knows what > happened. To other clients, it appears that a message was deleted and > a new message appeared in a different mailbox. Other clients don't > know these are the same message. Ah, but we could solve that problem but introducing revision control semantics to IMAP, so clients could track the entire history of modification to the message j/k :) Hmm, the pieces are already there. Maildir + SVN. -Ray _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 22 08:41:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOVM-00071H-RU; Thu, 22 Jun 2006 08:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOVL-00070W-9S for lemonade@ietf.org; Thu, 22 Jun 2006 08:41:51 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtOUM-0000q5-Sq for lemonade@ietf.org; Thu, 22 Jun 2006 08:40:52 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5MCekfD018762; Thu, 22 Jun 2006 15:40:49 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 15:40:47 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 15:40:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Notifications for multiple devices per user Date: Thu, 22 Jun 2006 15:40:29 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446575A3EEB@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: AcaVaPkIfevTB2uwRpquC0oTMfsXZAAj0qRQ From: To: X-OriginalArrivalTime: 22 Jun 2006 12:40:47.0381 (UTC) FILETIME=[15EBD450:01C695F9] X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Randall, this is exactly what I tried to avoid with the MOVE command. But there = is another aspect to it as well: if the message gets a new ID, the = client will have to re-download a mail that it already has. Repeated = transfer bad. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Randall Gellens [mailto:randy@qualcomm.com]=20 Sent: 21 June, 2006 22:26 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) Cc: lemonade@ietf.org Subject: RE: [lemonade] Notifications for multiple devices per user At 3:32 PM +0300 6/21/06, wrote: > If there was a MOVE command for IMAP, it would be easy I think. > This (future) MOVE extension would move email(s) and/or folders (even = > recursively if needed) without coping/deleting the emails directly to=20 > another folder preserving the message-id. > Then, the client could easily use MOVE to put all deleted messages to = > a specific folder (Trash, Deleted item, etc), right? > Then, there would be no need to use the flags at all - those messages = > in the Trash folder would be just normal emails until the user decides = > to permanently delete those emails. > This should be easy to specify, right? The UIDPLUS extension allows a client to do a COPY and learn the UID of = the message in its new mailbox. This becomes effectively a MOVE.=20 However, with this or your MOVE suggestion, no other client knows what = happened. To other clients, it appears that a message was deleted and a = new message appeared in a different mailbox. Other clients don't know = these are the same message. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I have made it a = rule, whenever in my power, to avoid becoming the draughtsman of papers = to be reviewed by a public body. --Benjamin Franklin _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 22 08:42:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOVd-0007Fl-52; Thu, 22 Jun 2006 08:42:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOVa-0007CR-Dy for lemonade@ietf.org; Thu, 22 Jun 2006 08:42:06 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtOSj-0000i9-I5 for lemonade@ietf.org; Thu, 22 Jun 2006 08:39:11 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5MCd3UJ025441; Thu, 22 Jun 2006 15:39:04 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 15:39:04 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 15:39:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Notifications for multiple devices per user Date: Thu, 22 Jun 2006 15:38:45 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446575A3EE8@esebe199.NOE.Nokia.com> In-Reply-To: <258D28C285E18A04F5D7A5B1@Cyrus-Daboo.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: AcaVNgwnNCaduqxASDKU4riFhpX+qgAwk89g From: To: , X-OriginalArrivalTime: 22 Jun 2006 12:39:03.0947 (UTC) FILETIME=[D8450DB0:01C695F8] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Cyrus, I did not follow IMAP and IMAPEXT work in the past unfortunately. I do not see why would it be hard on the server, nor any reason to drop = it - this is a discussion that we would not have to repeat here again so = I just accept what You have wrote. As a last resort, we should go for the best practice document. Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Cyrus Daboo [mailto:cyrus@daboo.name]=20 Sent: 21 June, 2006 16:22 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); dave@cridland.net Cc: lemonade@ietf.org Subject: RE: [lemonade] Notifications for multiple devices per user Hi Zoltan, --On June 21, 2006 3:32:41 PM +0300 Zoltan.Ordogh@nokia.com wrote: > Dave, I have this thought: > If there was a MOVE command for IMAP, it would be easy I think. > This (future) MOVE extension would move email(s) and/or folders (even=20 > recursively if needed) without coping/deleting the emails directly to=20 > another folder preserving the message-id. Then, the client could=20 > easily use MOVE to put all deleted messages to a specific folder=20 > (Trash, Deleted item, etc), right? Then, there would be no need to use = > the flags at all - those messages in the Trash folder would be just=20 > normal emails until the user decides to permanently delete those=20 > emails. This should be easy to specify, right? Unfortunately the idea of MOVE has been shot down many times in the past = - I suggest you review IMAP and IMAPext mailing lists to see the = discussion of all that. Frankly its not worth fighting to get it now. = Yes it would make Trash and move operations (which are a much more = common user action than a copy) more reliable - but server vendors in = the past have made it plain that its 'hard' to do so there was never any = interest in implementing. Frankly I think the discussion of a statement that clients should not = use Trash is all wrong - what we should do is write a 'best common = practices for implementing Trash properly with IMAP' document to help = client author's get it done right (subject to the limitations that do = exist). -- Cyrus Daboo _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 22 08:43:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOWk-00086X-UH; Thu, 22 Jun 2006 08:43:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOWk-00086M-9C for lemonade@ietf.org; Thu, 22 Jun 2006 08:43:18 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtOWi-00019G-QS for lemonade@ietf.org; Thu, 22 Jun 2006 08:43:18 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5MChFFS015078; Thu, 22 Jun 2006 15:43:15 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 15:43:15 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 15:43:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Notifications for multiple devices per user Date: Thu, 22 Jun 2006 15:42:57 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446575A3EF4@esebe199.NOE.Nokia.com> In-Reply-To: <4499E95F.1000606@pathbreaker.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Notifications for multiple devices per user Thread-Index: AcaVlgD619yirpVMRaiFIVYt4u1e1gAYzFEQ From: To: , X-OriginalArrivalTime: 22 Jun 2006 12:43:15.0432 (UTC) FILETIME=[6E2A9E80:01C695F9] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Ray, would not be such tracking 'too heavy' on the constrained devices (which = we are tying to address)? Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Ray Cromwell [mailto:ray@pathbreaker.com]=20 Sent: 22 June, 2006 03:51 To: lemonade@ietf.org Subject: Re: [lemonade] Notifications for multiple devices per user Randall Gellens wrote: > > The UIDPLUS extension allows a client to do a COPY and learn the UID=20 > of the message in its new mailbox. This becomes effectively a MOVE. > However, with this or your MOVE suggestion, no other client knows what = > happened. To other clients, it appears that a message was deleted and = > a new message appeared in a different mailbox. Other clients don't=20 > know these are the same message. Ah, but we could solve that problem but introducing revision control = semantics to IMAP, so clients could track the entire history of = modification to the message j/k :) Hmm, the pieces are already there.=20 Maildir + SVN. -Ray _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 22 14:44:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUAD-0004bh-U3; Thu, 22 Jun 2006 14:44:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUAD-0004bN-0w for lemonade@ietf.org; Thu, 22 Jun 2006 14:44:25 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUAB-000818-Jo for lemonade@ietf.org; Thu, 22 Jun 2006 14:44:24 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5MIiLr6001365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Jun 2006 11:44:22 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5MIiIuP012490; Thu, 22 Jun 2006 11:44:20 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0FA975F2D8295A448BE3ADC1612446575A3EEB@esebe199.NOE.Nokia.com> References: <0FA975F2D8295A448BE3ADC1612446575A3EEB@esebe199.NOE.Nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 22 Jun 2006 11:38:50 -0700 To: , From: Randall Gellens Subject: RE: [lemonade] Notifications for multiple devices per user Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org At 3:40 PM +0300 6/22/06, wrote: > Hi Randall, > this is exactly what I tried to avoid with the MOVE command. But > there is another aspect to it as well: if the message gets a new > ID, the client will have to re-download a mail that it already has. > Repeated transfer bad. Hi Zoltan, The change in UID and hence re-downloading isn't another aspect, it's the primary aspect of other clients not knowing that these are the same message. The original client, the one that did the COPY, can know that these are the same message because UIDPLUS allows it to learn the new UID. The client can then update its cache to reflect this. > -----Original Message----- > From: ext Randall Gellens [mailto:randy@qualcomm.com] > Sent: 21 June, 2006 22:26 > To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) > Cc: lemonade@ietf.org > Subject: RE: [lemonade] Notifications for multiple devices per user > > At 3:32 PM +0300 6/21/06, wrote: > >> If there was a MOVE command for IMAP, it would be easy I think. >> This (future) MOVE extension would move email(s) and/or folders (even >> recursively if needed) without coping/deleting the emails directly to >> another folder preserving the message-id. >> Then, the client could easily use MOVE to put all deleted messages to >> a specific folder (Trash, Deleted item, etc), right? >> Then, there would be no need to use the flags at all - those messages >> in the Trash folder would be just normal emails until the user decides >> to permanently delete those emails. >> This should be easy to specify, right? > > The UIDPLUS extension allows a client to do a COPY and learn the > UID of the message in its new mailbox. This becomes effectively a > MOVE. > However, with this or your MOVE suggestion, no other client knows > what happened. To other clients, it appears that a message was > deleted and a new message appeared in a different mailbox. Other > clients don't know these are the same message. > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly-selected tag: --------------- I have made > it a rule, whenever in my power, to avoid becoming the draughtsman > of papers to be reviewed by a public body. > --Benjamin Franklin > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- In any collection of data, the figure most obviously correct, beyond all need of checking, is the mistake. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 22 18:54:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtY3k-0001zc-HU; Thu, 22 Jun 2006 18:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtXzw-000400-Fl; Thu, 22 Jun 2006 18:50:04 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtXzv-0003G3-Ax; Thu, 22 Jun 2006 18:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo2Rx025074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzu-0007uj-Mk; Thu, 22 Jun 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Jun 2006 18:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-01.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : The IMAP COMPRESS=DEFLATE Extension Author(s) : A. Gulbrandsen Filename : draft-ietf-lemonade-compress-01.txt Pages : 8 Date : 2006-6-22 The COMPRESS=DEFLATE extension allows an IMAP connection to be compressed using the DEFLATE algorithm, such that effective compression is available even when TLS is used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-compress-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-lemonade-compress-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: <2006-6-22165310.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-compress-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-compress-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22165310.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Thu Jun 22 19:30:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYdW-00067L-A5; Thu, 22 Jun 2006 19:30:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYdV-00067G-U1 for lemonade@ietf.org; Thu, 22 Jun 2006 19:30:57 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtYdU-0000c8-9Q for lemonade@ietf.org; Thu, 22 Jun 2006 19:30:57 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FtYdT-0004In-2l; Thu, 22 Jun 2006 23:30:55 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 080CD498003; Fri, 23 Jun 2006 00:31:47 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18297-07; Fri, 23 Jun 2006 00:31:40 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id D8438498002; Fri, 23 Jun 2006 00:31:40 +0100 (BST) Date: Fri, 23 Jun 2006 00:30:48 +0100 Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt References: <0FA975F2D8295A448BE3ADC16124465738ECE0@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC16124465738ECE0@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <16236.1151019048.695890@peirce.dave.cridland.net> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Jun 7 13:01:31 2006, Zoltan.Ordogh@nokia.com wrote: > Hi all, > A few questions/comments: > - Section 4.3, first paragraph. I saw some emails about > including/not including Compression in CONVERT. What was the > conclusion on this? Does the current bis reflect that agreement? > OMA STI does not include parameters for compressing files. > - Section 4.3, last paragraph. So, there will be a COMPRESS anyway? > - Section 4.3 general. This section is confusing. Would it be > possible to describe things from the compression level point of > view saying this is low-level, that is application-level, and that > is object-level compression. This is believed to be better for > this, that is believed to be better for that. For low-level use > this and that, for application-level use this and that, and for > object-level use this and that. This is mandatory, while that is > optional for the server. Clients to evaluate which is available and > best used according to their capabilities and the current network > conditions. Alexey has tidied this up, removing the inapplicable paragraphs. > - Section 4.5. Normative statement missing - is it a MUST, SHOULD > or MAY? It's a MUST, but expressed as a statement of fact for variety. (Note that CATENATE is even more extreme, dispensing with RFC2119 entirely). > - "required by [RFC3501]. As noted above, servers SHOULD support" > that note is quite far above - could we say "Section 4.3"? Done. > - Section 5: "STARTTLS | Required by IMAP [RFC3501]" Are we going > to describe all dependencies? If not, remove, if yes, add all > please. STARTTLS was historically not part of IMAP4rev1, it was mandated and included into RFC3501. Originally, though it was distinct, defined in RFC2595, and as such, I think it's a special case. > - Section 5: "LPROVISION, LSETPREF, LGETPREF | Section 4.4" these > are not described in section 4.4. They're part of the notifications draft. > - Section 13, 1st bullet: double dot at the end of the paragraph. > - Section 13, 3nd bullet: "Notifications (server to client)" -> > "Server to client notifications", but: why the separation if they > are discussed in the same draft anyway? Section 13 is intentionally somewhat rough notes, it will vanish. (It's actually section 7.7, now). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 22 19:31:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYeC-0006Po-V5; Thu, 22 Jun 2006 19:31:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYeC-0006PW-0d for lemonade@ietf.org; Thu, 22 Jun 2006 19:31:40 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtYeA-0000ez-Io for lemonade@ietf.org; Thu, 22 Jun 2006 19:31:39 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FtYe9-0001rT-Ol; Thu, 22 Jun 2006 23:31:37 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 650E8498003; Fri, 23 Jun 2006 00:32:29 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18297-10; Fri, 23 Jun 2006 00:32:24 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 4F9E2498002; Fri, 23 Jun 2006 00:32:24 +0100 (BST) Date: Fri, 23 Jun 2006 00:31:31 +0100 Subject: Re: FW: [lemonade] LEMONADE Profile 2 issues References: <0FA975F2D8295A448BE3ADC161244657323A48@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC161244657323A48@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <16236.1151019092.132872@peirce.dave.cridland.net> From: Dave Cridland To: "Zoltan.Ordogh@nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon Jun 5 08:07:07 2006, Zoltan.Ordogh@nokia.com wrote: > Page 1 > -> Typo: "It provides also extensions to provide support for > realizationz of"-> realizations > > Alexey corrected this. (I think). > Section 12.2.2 > " I2 designates proprietary adapters to the backends. They may > invoved > functions performed in the message stores or submit server as > well as > in the MEM enabler server." > -> invoved? Involved, right? Corrected. > -> What is a proprietary adapter? This is supposed to provide an > IMAP <-> POP3 mapping, right? So the message here is that > proprietary emails will never work because LEMONADE supports > IMAP/SUBMIT only, so whatever You do, You will need a LEMONADE > anabled IMAP/SUBMIT anyway, right? If so, should this whole section > be removed then? (LEMONADE does not provide any > support/specification for it, so it's not in the scope). > > I'd appreciate some discussion on this. > And finally: > There are an awfully long list of references listed - however not > all of these are used. Reference [48] is a very good example. > Stephane for example takes every opportunity to promote proprietary > technology P-IMAP - if You check, it's almost in every draft, but > never actually used. I am not saying P-IMAP is bad, I am saying > that this kind of behaviour confuses OMA MEM, analists (even my own > managers) because they do not know what LEMONADE is and what the > relation of profile/bis to P-IMAP is (which was believed to be > dropped quite a while ago). To avoid confusion, all of the unused > references should be either removed or described why and how they > are used. > > Both Alexey and myself have gone through the references carefully. A considerable number of these have built up over time, and until I'd done some stricter processing, it was difficult to see which ones were no longer used. Hopefully the references are now a little more usable. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 22 19:57:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtZ38-0001iY-I8; Thu, 22 Jun 2006 19:57:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtZ37-0001iS-HN for lemonade@ietf.org; Thu, 22 Jun 2006 19:57:25 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtZ36-0002wc-7X for lemonade@ietf.org; Thu, 22 Jun 2006 19:57:25 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5MNvJNN009885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Jun 2006 16:57:19 -0700 Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5MNvHPg017136; Thu, 22 Jun 2006 16:57:18 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 22 Jun 2006 16:56:06 -0700 To: Arnt Gulbrandsen , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The sentence in "The COMPRESS Command" at the end of Page 2 seems to be truncated. If the direction specified is "DOWN", only In "Compression Efficiency", the text "clients which send many APPEND commands may want to take special care" should be explained, I think. What should such clients do? Also, same section, since you list four different kinds of data sent by IMAP servers, may as well change "Downstream has the unusual property that 3-4 kinds of data are sent" to say "four" or maybe "at least four". Typo in "Implementation Notes": "level 0" should be "level to 0". -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Adding manpower to a late software project makes it later. -- Fred Brooks in _The Mythical Man Month_ _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 23 12:53:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftoua-00007Q-UH; Fri, 23 Jun 2006 12:53:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftoua-00007E-6H for lemonade@ietf.org; Fri, 23 Jun 2006 12:53:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtnJM-0003lv-BB for lemonade@ietf.org; Fri, 23 Jun 2006 11:11:08 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtnB2-0003Yv-Se for lemonade@ietf.org; Fri, 23 Jun 2006 11:02:34 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 23 Jun 2006 16:02:23 +0100 Message-ID: <449C0266.2020206@isode.com> Date: Fri, 23 Jun 2006 16:01:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dave Cridland Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt References: <0FA975F2D8295A448BE3ADC16124465738ECE0@esebe199.NOE.Nokia.com> <16236.1151019048.695890@peirce.dave.cridland.net> In-Reply-To: <16236.1151019048.695890@peirce.dave.cridland.net> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: -2.1 (--) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Internet email to support diverse service enivronments , Enhancements, "Zoltan.Ordogh@nokia.com" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote: > On Wed Jun 7 13:01:31 2006, Zoltan.Ordogh@nokia.com wrote: > >> Hi all, >> A few questions/comments: >> - Section 4.3, first paragraph. I saw some emails about >> including/not including Compression in CONVERT. What was the >> conclusion on this? Does the current bis reflect that agreement? OMA >> STI does not include parameters for compressing files. >> - Section 4.3, last paragraph. So, there will be a COMPRESS anyway? >> - Section 4.3 general. This section is confusing. Would it be >> possible to describe things from the compression level point of view >> saying this is low-level, that is application-level, and that is >> object-level compression. This is believed to be better for this, >> that is believed to be better for that. For low-level use this and >> that, for application-level use this and that, and for object-level >> use this and that. This is mandatory, while that is optional for the >> server. Clients to evaluate which is available and best used >> according to their capabilities and the current network conditions. > > Alexey has tidied this up, removing the inapplicable paragraphs. > >> - Section 4.5. Normative statement missing - is it a MUST, SHOULD or >> MAY? > > It's a MUST, but expressed as a statement of fact for variety. (Note > that CATENATE is even more extreme, dispensing with RFC2119 entirely). > >> - "required by [RFC3501]. As noted above, servers SHOULD support" >> that note is quite far above - could we say "Section 4.3"? > > Done. > >> - Section 5: "STARTTLS | Required by IMAP [RFC3501]" Are we going to >> describe all dependencies? If not, remove, if yes, add all please. > > STARTTLS was historically not part of IMAP4rev1, it was mandated and > included into RFC3501. Originally, though it was distinct, defined in > RFC2595, and as such, I think it's a special case. I agree. >> - Section 5: "LPROVISION, LSETPREF, LGETPREF | Section 4.4" these >> are not described in section 4.4. > > They're part of the notifications draft. Actually, I removed them, as we are going to use METADATA instead. >> - Section 13, 1st bullet: double dot at the end of the paragraph. > Fixed. >> - Section 13, 3nd bullet: "Notifications (server to client)" -> >> "Server to client notifications", > Changed. >> but: why the separation if they are discussed in the same draft anyway? > > Section 13 is intentionally somewhat rough notes, it will vanish. > (It's actually section 7.7, now). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 23 16:21:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fts9V-0005bW-Hl; Fri, 23 Jun 2006 16:21:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fts9T-0005bR-Tj for lemonade@ietf.org; Fri, 23 Jun 2006 16:21:15 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fts9S-0000qb-OD for lemonade@ietf.org; Fri, 23 Jun 2006 16:21:15 -0400 X-IronPort-AV: i="4.06,170,1149480000"; d="scan'208"; a="34556185:sNHT27309780" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Jun 2006 16:22:46 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470317AB79@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Montreal Thread-Index: AcaW8YiYCn/74CeiTz2LJkFfscXrwg== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [lemonade] Montreal X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Can you send me, off-list, if you plan on: 1. Physically attending in Montreal 2. Logically attending via Jabber / iChat 3. Not coming Also, be aware we got a note from the Secretariat there is a possibility of some schedule shifting. At this late date, I don't think it will happen, but we have asked again for an extra day between the two meeting slots. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 23 18:14:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fttv7-0005Sq-1t; Fri, 23 Jun 2006 18:14:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fttv5-0005NT-Dj for lemonade@ietf.org; Fri, 23 Jun 2006 18:14:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtsNa-0002Dm-EV for lemonade@ietf.org; Fri, 23 Jun 2006 16:35:50 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fts5R-0008UE-2A for lemonade@ietf.org; Fri, 23 Jun 2006 16:17:06 -0400 X-IronPort-AV: i="4.06,170,1149480000"; d="scan'208"; a="34556002:sNHT44374752" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Jun 2006 16:18:26 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470317AB20@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF Meeting Survey Thread-Index: AcZtM1s+MgqgOvwhR7qDSKYXkfK/XQpcGwSQ From: "Burger, Eric" To: X-Spam-Score: -2.5 (--) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [lemonade] FW: IETF Meeting Survey X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org My bad for taking so long to forward this, but if you could take the survey, it would be a good thing. -----Original Message----- From: Ray Pelletier [mailto:rpelletier@isoc.org]=20 Sent: Monday, May 01, 2006 11:25 AM To: wgchairs@ietf.org Subject: IETF Meeting Survey All; It has been suggested that if I really wanted to get feedback on the=20 Meeting Survey (and I do) I should have it forwarded by the WG Chairs=20 to the working groups - so this is a request that you ask members of the working groups to complete a short survey that focuses primarily, but=20 not exclusively, on their meeting experience in Dallas.=20 I truly want the info to make the changes members of the community want, if possible and greatly appreciate your assistance in this regard. Those interested in taking the survey can find it at: http://www.surveymonkey.com/s.asp?u=3D649182049947 Thanks Ray Pelletier IETF Admininstrative Director _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 23 18:21:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftu25-0000TJ-Jg; Fri, 23 Jun 2006 18:21:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftu23-0000T4-Jt for lemonade@ietf.org; Fri, 23 Jun 2006 18:21:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtsNa-0002EM-Ex for lemonade@ietf.org; Fri, 23 Jun 2006 16:35:50 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fts5O-0008UM-8K for lemonade@ietf.org; Fri, 23 Jun 2006 16:17:04 -0400 X-IronPort-AV: i="4.06,170,1149480000"; d="scan'208"; a="34555997:sNHT27779472" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Jun 2006 16:18:23 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470317AB1C@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Presentations Thread-Index: AcaWjhdPTY/F/0tMSfCJlA4VLIl68A== From: "Burger, Eric" To: X-Spam-Score: -2.5 (--) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [lemonade] Presentations X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org If you will be making a presentation at IETF 66, PLEASE send them to the chairs by July 6. Thank you. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Jun 25 19:37:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FueAZ-0007T6-Bv; Sun, 25 Jun 2006 19:37:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FueAY-0007T1-E8 for lemonade@ietf.org; Sun, 25 Jun 2006 19:37:34 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FueAW-0000i3-65 for lemonade@ietf.org; Sun, 25 Jun 2006 19:37:34 -0400 X-IronPort-AV: i="4.06,173,1149480000"; d="scan'208"; a="34650140:sNHT131361384" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] FW: IETF Meeting Survey Date: Sun, 25 Jun 2006 19:37:31 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470317ACD5@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] FW: IETF Meeting Survey Thread-Index: AcZtM1s+MgqgOvwhR7qDSKYXkfK/XQpcGwSQAIMg+sA= From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org My real bad for taking so long that the survey's closed :( -----Original Message----- From: Burger, Eric [mailto:eburger@cantata.com]=20 Sent: Friday, June 23, 2006 4:18 PM To: lemonade@ietf.org Subject: [lemonade] FW: IETF Meeting Survey My bad for taking so long to forward this, but if you could take the survey, it would be a good thing. -----Original Message----- From: Ray Pelletier [mailto:rpelletier@isoc.org]=20 Sent: Monday, May 01, 2006 11:25 AM To: wgchairs@ietf.org Subject: IETF Meeting Survey All; It has been suggested that if I really wanted to get feedback on the=20 Meeting Survey (and I do) I should have it forwarded by the WG Chairs=20 to the working groups - so this is a request that you ask members of the working groups to complete a short survey that focuses primarily, but=20 not exclusively, on their meeting experience in Dallas.=20 I truly want the info to make the changes members of the community want, if possible and greatly appreciate your assistance in this regard. Those interested in taking the survey can find it at: http://www.surveymonkey.com/s.asp?u=3D649182049947 Thanks Ray Pelletier IETF Admininstrative Director _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 26 02:46:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FukrZ-0006Kd-Ca; Mon, 26 Jun 2006 02:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FukrY-0006Ia-0P for lemonade@ietf.org; Mon, 26 Jun 2006 02:46:24 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FukrW-0002FE-J8 for lemonade@ietf.org; Mon, 26 Jun 2006 02:46:23 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5Q6kGfj029521; Mon, 26 Jun 2006 09:46:21 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 09:46:15 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 09:46:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt Date: Mon, 26 Jun 2006 09:45:52 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657603614@esebe199.NOE.Nokia.com> In-Reply-To: <16236.1151019048.695890@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-02.txt Thread-Index: AcaWU+5ItIwIZNbgTTSPNGx6MehNFACmA6vg From: To: X-OriginalArrivalTime: 26 Jun 2006 06:46:15.0397 (UTC) FILETIME=[387BA950:01C698EC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dave, >> - Section 5: "LPROVISION, LSETPREF, LGETPREF | Section 4.4" these=20 >> are not described in section 4.4. >They're part of the notifications draft. Should we then update the reference from Section 4.4. to the Notificiations draft? Thank You. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 26 05:00:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumxO-0006FQ-L6; Mon, 26 Jun 2006 05:00:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumxN-0006FF-HC; Mon, 26 Jun 2006 05:00:33 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FumxM-0007uJ-0q; Mon, 26 Jun 2006 05:00:33 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5Q90TW5029655; Mon, 26 Jun 2006 12:00:31 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 12:00:24 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 12:00:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-DACTION:draft-ietf-lemonade-notification-protocol-00.txt Date: Mon, 26 Jun 2006 11:59:58 +0300 Message-ID: <0FA975F2D8295A448BE3ADC1612446576037F3@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-DACTION:draft-ietf-lemonade-notification-protocol-00.txt Thread-Index: AcaVa/rwgHeQcXkbTReX5ik0jiMt3QDkdAZQ From: To: , X-OriginalArrivalTime: 26 Jun 2006 09:00:23.0737 (UTC) FILETIME=[F5AAE290:01C698FE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org A few comments: Section 1: "This draft provides a notification protocols for = [NOTIFICATIONS] and the Lemonade profile." typo "protocols"->"protocol" Section 2.1: "The present draft solely provides a generic protocol to do = so that the notification mechanism MAY support. " Remove "to do that" Section 2.2: "The present draft solely provides a generic protocol to do = so that the notification mechanism MAY support." Same as above - should = one of the duplicate sentences be removed? Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20 Sent: 21 June, 2006 22:50 To: i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: [lemonade] = I-DACTION:draft-ietf-lemonade-notification-protocol-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF. Title : Lemonade Notification protocol Author(s) : S. Maes Filename : draft-ietf-lemonade-notification-protocol-00.txt Pages : 8 Date : 2006-6-21 =09 This document introduces a notification protocol as a specified=20 particular case of the notification mechanisms used by the Lemonade=20 profile [LEMONADEPROFILEBIS] in [NOTIFICATIONS]. =20 =20 This document also discusses the use of Lemonade notifications to=20 implement server to server notifications.=20 =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notification-prot= ocol-00.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-notification-protocol-00.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE = /internet-drafts/draft-ietf-lemonade-notification-protocol-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 26 06:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuoSq-0008IF-A1; Mon, 26 Jun 2006 06:37:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuoSp-0008I7-S8 for lemonade@ietf.org; Mon, 26 Jun 2006 06:37:07 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuoSn-0002Mc-Eh for lemonade@ietf.org; Mon, 26 Jun 2006 06:37:07 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 26 Jun 2006 11:36:03 +0100 Message-ID: <449F0AD8.9050003@isode.com> Date: Sun, 25 Jun 2006 23:14:48 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] Notifications for multiple devices per user References: <0FA975F2D8295A448BE3ADC16124465754DD20@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC16124465754DD20@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: randy@qualcomm.com, lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan.Ordogh@nokia.com wrote: >Good points. >I am not sure myself that SIEVE is the best way to go here. >SIEVE might be good enough to identify which events needs to be notified, however I do not think that the SIEVE scripts should include information about the bearer type or addresses (where to send the notification) - otherwise each client needs to update the SIEVE script according to its need, and it will introduce additional issues. > > Sieve script can reference values stored in mailbox annotations. This would allow the Sieve script to stay pretty much static, while the client can modify where notifications go by changing per mailbox annotations. (Draft describing Sieve extension for this is on my todo list) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 26 18:12:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzKF-00042t-B4; Mon, 26 Jun 2006 18:12:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzKE-00042m-Ki for lemonade@ietf.org; Mon, 26 Jun 2006 18:12:58 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuzKA-00052g-37 for lemonade@ietf.org; Mon, 26 Jun 2006 18:12:58 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FuzK6-0007b4-8k for lemonade@ietf.org; Mon, 26 Jun 2006 22:12:53 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 33E30498003 for ; Mon, 26 Jun 2006 23:14:22 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07936-04 for ; Mon, 26 Jun 2006 23:14:07 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id E7A23498002 for ; Mon, 26 Jun 2006 23:14:06 +0100 (BST) Date: Mon, 26 Jun 2006 23:12:33 +0100 MIME-Version: 1.0 Message-Id: <32030.1151359954.696131@peirce.dave.cridland.net> From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: multipart/mixed; boundary="32030.1151359953.814126@peirce.dave.cridland.net" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 98033af64fe72c1cdc65fa459097e7f5 Subject: [lemonade] Profile Bis -03 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --32030.1151359953.814126@peirce.dave.cridland.net Content-Type: text/plain; charset="us-ascii"; format="flowed" Hiya folks, I submitted the attached version of draft-ietf-lemonade-profile-bis this morning, UK time, hence before the deadline, as version -03. I'm guessing there'll be a slight delay before it's seen in the I-D repository, so here is an advance copy. Have fun, and see if you can find the deliberate errors. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade --32030.1151359953.814126@peirce.dave.cridland.net Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-lemonade-profile-bis-03.txt" LEMONADE Working Group S. Maes, Ed. Internet-Draft Oracle Expires: November 2, 2006 A. Melnikov, Ed. Isode Limited D. Cridland, Ed. Inventure Systems Ltd May 2006 LEMONADE profile bis draft-ietf-lemonade-profile-bis-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 2, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the LEMONADE profile. It contains pointers to or descriptions of all the features that are normatively part of this version of the LEMONADE profile. This document describes a profile (a set of required extensions, Maes, et al. Expires November 2, 2006 [Page 1] Internet-Draft LEMONADE profile bis May 2006 restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon extensions to IMAP and Mail Submission protocols; specifically URLAUTH and CATENATE IMAP protocol extensions and BURL extension to the SUBMIT protocol. Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Forward without download . . . . . . . . . . . . . . . . . . . 5 3.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Message Sending Overview . . . . . . . . . . . . . . . . . 5 3.3. Traditional Strategy . . . . . . . . . . . . . . . . . . . 6 3.4. Step by step description . . . . . . . . . . . . . . . . . 7 3.4.1. Message assembly using IMAP CATENATE extension . . . . 7 3.4.2. Message assembly using SMTP CHUNKING and BURL extensions . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Normative statements related to forward without download . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.6. Security Considerations for pawn-tickets. . . . . . . . . 16 3.7. Copies of Sent messages: The fcc problem . . . . . . . . . 17 3.8. Registration of $Forwarded IMAP keyword . . . . . . . . . 17 4. Message Submission . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Pipelining . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. DSN Support . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Message size declaration . . . . . . . . . . . . . . . . . 18 4.4. Enhanced status code Support . . . . . . . . . . . . . . . 18 4.5. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Message Store . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Quick resynchronization . . . . . . . . . . . . . . . . . 19 5.2. Message part handling . . . . . . . . . . . . . . . . . . 19 5.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 19 5.4. Out of band notifications . . . . . . . . . . . . . . . . 19 5.5. Virtual Mailboxes . . . . . . . . . . . . . . . . . . . . 20 5.6. Additional IMAP extensions . . . . . . . . . . . . . . . . 20 6. Summary of the required IMAP and SMTP extensions . . . . . . . 21 7. OMA MEM Requirement document . . . . . . . . . . . . . . . . . 21 7.1. OMA MEM Architecture . . . . . . . . . . . . . . . . . . . 22 7.2. OMA MEM Deployment Issues . . . . . . . . . . . . . . . . 22 Maes, et al. Expires November 2, 2006 [Page 2] Internet-Draft LEMONADE profile bis May 2006 7.3. OMA MEM proxy . . . . . . . . . . . . . . . . . . . . . . 22 7.4. IETF LEMONADE Architecture . . . . . . . . . . . . . . . . 22 7.5. LEMONADE profile logical architecture . . . . . . . . . . 24 7.5.1. Relationship between the OMA MEM and LEMONADE logical architectures . . . . . . . . . . . . . . . . 24 7.5.2. LEMONADE realization of OMA MEM with non-LEMONADE compliant servers . . . . . . . . . . . . . . . . . . 26 7.6. Filters and server to client notifications and LEMONADE . 27 7.7. LEMONADE Profile features . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8.1. Confidentiality Protection of Submitted Messages . . . . . 30 8.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8.3. Additional extensions and deployment models . . . . . . . 31 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 10. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. Version history . . . . . . . . . . . . . . . . . . . . . . . 31 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix A. Streaming attachments . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . . . 39 Maes, et al. Expires November 2, 2006 [Page 3] Internet-Draft LEMONADE profile bis May 2006 1. Conventions used in this document In examples, "M:", "I:" and "S:" indicate lines sent by the client messaging user agent, IMAP e-mail server and SMTP submit server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Other capitalised words are typically names of extensions or commands - these are uppercased for clarity only, and are case-insensitive. All examples in this document are optimized for Lemonade use and might not represent examples of proper protocol usage for a general use Submit/IMAP client. In particular examples assume that Lemonade Submit and IMAP servers support all Lemonade extensions described in this document, so they do not demonstrate fallbacks in the absence of an extension. 2. Introduction LEMONADE provides enhancements to Internet email to support diverse service environments. This document describes the LEMONADE profile that includes: o "Forward without download" that describes exchanges between Lemonade clients and servers to allow to submit new email messages incorporating content which resides on locations external to the client. o Quick mailbox resynchronization using [RFC4551]. o Several IMAP and SMTP extensions that allow saving bandwidth and/or number of round trips required to send/receive data. o Extensions to provide support to realizations of OMA mobile email enabler (MEM) [MEM-req] [MEM-arch] using Internet Mail protocols defined by the IETF. <> Also, it is to be noted that this document solely describes normatively the LEMONADE profile. It discusses LEMONADE understanding of the work in progress at OMA MEM ([MEM-req] and [MEM- Maes, et al. Expires November 2, 2006 [Page 4] Internet-Draft LEMONADE profile bis May 2006 arch] but does not provide a normative reading of these documents. Readers MUST refer to the Open Mobile Alliance web site for normative references on the Mobile Email Enabler (OMA MEM). LEMONADE assumes that the LEMONADE profile can be used as basis for an OMA technical specification of a realization based on LEMONADE of the OMA MEM enabler. 3. Forward without download 3.1. Motivations The advent of client/server email using the [RFC3501], [RFC2821] and [RFC4409] protocols has changed what formerly were local disk operations to become repetitive network data transmissions. Lemonade "forward without download" makes use of the [RFC4468] SUBMIT extension to enable access to external sources during the submission of a message. In combination with the IMAP [RFC4467] extension, inclusion of message parts or even entire messages from the IMAP mail store is possible with a minimal trust relationship between the IMAP and SMTP SUBMIT servers. Lemonade "forward without download" has the advantage of maintaining one submission protocol, and thus avoids the risk of having multiple parallel and possibly divergent mechanisms for submission. The client can use Submit/SMTP [RFC4409] extensions without these being added to IMAP. Furthermore, by keeping the details of message submission in the SMTP SUBMIT server, Lemonade "forward without download" can work with other message retrieval protocols such as POP, NNTP, or whatever else may be designed in the future. 3.2. Message Sending Overview The act of sending an email message can be thought of as involving multiple steps: initiation of a new draft, draft editing, message assembly, and message submission. Initiation of a new draft and draft editing takes place in the MUA. Frequently, users choose to save more complex messages on an [RFC3501] server (via the APPEND command with the \Draft flag) for later recall by the MUA and resumption of the editing process. Message assembly is the process of producing a complete message from the final revision of the draft and external sources. At assembly time, external data is retrieved and inserted in the message. Message submission is the process of inserting the assembled message Maes, et al. Expires November 2, 2006 [Page 5] Internet-Draft LEMONADE profile bis May 2006 into the [RFC2821] infrastructure, typically using the [RFC4409] protocol. 3.3. Traditional Strategy Traditionally, messages are initiated, edited, and assembled entirely within an MUA, although drafts may be saved to an [RFC3501] server and later retrieved from the server. The completed text is then transmitted to an MSA for delivery. There is often no clear boundary between the editing and assembly process. If a message is forwarded, its content is often retrieved immediately and inserted into the message text. Similarly, when external content is inserted or attached, the content is usually retrieved immediately and made part of the draft. As a consequence, each save of a draft and subsequent retrieve of the draft transmits that entire (possibly large) content, as does message submission. In the past, this was not much of a problem, because drafts, external data, and the message submission mechanism were typically located on the same system as the MUA. The most common problem was running out of disk quota. Maes, et al. Expires November 2, 2006 [Page 6] Internet-Draft LEMONADE profile bis May 2006 3.4. Step by step description The model distinguishes between a Messaging User Agent (MUA), an IMAPv4Rev1 Server ([RFC3501]) and a SMTP submit server ([RFC4409]), as illustrated in Figure 1. +--------------------+ +--------------+ | | <------------ | | | MUA (M) | | IMAPv4Rev1 | | | | Server | | | ------------> | (Server I) | +--------------------+ +--------------+ ^ | ^ | | | | | | | | | | | | | | | | | | | | | | | | v | | +--------------+ | |----------------------> | SMTP | | | Submit | |-----------------------------| Server | | (Server S) | +--------------+ Figure 1: Lemonade "forward without download" Lemonade "forward without download" allows a Messaging User Agent to compose and forward an e-mail combining fragments that are located in an IMAP server, without having to download these fragments to the client. There are two ways to perform "forward without download" based on where the message assembly takes place. The first uses extended APPEND command [RFC4469] to edit a draft message in the message store and cause the message assembly on the IMAP server. The second uses a succession of BURL and BDAT commands to submit and assemble through concatenation, message data from the client and external data fetched from the provided URL. The two subsequent sections provide step-by- step instructions on how "forward without download" is achieved. 3.4.1. Message assembly using IMAP CATENATE extension In the BURL [RFC4468]/CATENATE [RFC4469] variant of the Lemonade "forward without download" strategy, messages are initially composed and edited within an MUA. The [RFC4469] extension to [RFC3501] is then used to create the messages on the IMAP server by transmitting Maes, et al. Expires November 2, 2006 [Page 7] Internet-Draft LEMONADE profile bis May 2006 new text and assembling them. The UIDPLUS [RFC4315] IMAP extension is used by the client in order to learn the UID of the created messages. Finally a [RFC4467] format URL is given to a [RFC4409] server for submission using the BUTL [RFC4468] extension. The flow involved to support such a use case consists of: M: {to I -- Optional} The client connects to the IMAP server, optionally starts TLS (if data confidentiality is required), authenticates, opens a mailbox ("INBOX" in the example below) and fetches body structures (See [RFC3501]). Example: M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE) I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "trip.txt") "<960723163407.20117h@washington.example.com>" "Your trip details" "BASE64" 4554 73) "MIXED")) I: A0051 OK completed M: {to I} The client invokes CATENATE (See [RFC4469] for details of the semantics and steps) -- this allows the MUA to create messages on the IMAP server using new data combined with one or more message parts already present on the IMAP server. Note that the example for this step doesn't use the LITERAL+ [RFC2088] extension. Without LITERAL+ the new message is constructed using 3 round-trips. If LITERAL+ is used, the new message can be constructed using one round-trip. Maes, et al. Expires November 2, 2006 [Page 8] Internet-Draft LEMONADE profile bis May 2006 M: A0052 APPEND Sent FLAGS (\Draft \Seen $MDNSent) CATENATE (TEXT {475} I: + Ready for literal data M: Message-ID: <419399E1.6000505@caernarfon.example.org> M: Date: Thu, 12 Nov 2004 16:57:05 +0000 M: From: Bob Ar M: MIME-Version: 1.0 M: To: foo@example.net M: Subject: About our holiday trip M: Content-Type: multipart/mixed; M: boundary="------------030308070208000400050907" M: M: --------------030308070208000400050907 M: Content-Type: text/plain; format=flowed M: M: Our travel agent has sent the updated schedule. M: M: Cheers, M: Bob M: --------------030308070208000400050907 M: URL "/INBOX;UIDVALIDITY=385759045/; UID=25627/;Section=2.MIME" URL "/INBOX; UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44} I: + Ready for literal data M: M: --------------030308070208000400050907-- M: ) I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed M: {to I} The client uses GENURLAUTH command to request a URLAUTH URL (See [RFC4467]). I: {to M} The IMAP server returns a URLAUTH URL suitable for later retrieval with URLFETCH (See [RFC4467] for details of the semantics and steps). M: A0054 GENURLAUTH "imap://bob.ar@example.org/Sent; UIDVALIDITY=387899045/;uid=45;expire=2005-10- 28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL I: * GENURLAUTH "imap://bob.ar@example.org/Sent; UIDVALIDITY=387899045/;uid=45;expire= 2005-10-28T23:59:59Z;urlauth=submit+bob.ar: internal:91354a473744909de610943775f92038" I: A0054 OK GENURLAUTH completed M: {to S} The client connects to the mail submission server and starts a new mail transaction. It uses BURL to let the SMTP submit server fetch the content of the message from the IMAP server (See [RFC4468] for details of the semantics and steps -- this allows the Maes, et al. Expires November 2, 2006 [Page 9] Internet-Draft LEMONADE profile bis May 2006 MUA to authorize the SMTP submit server to access the message composed as a result of the CATENATE step). Note that the second EHLO command is required after a successful STARTTLS command. Also note that there might be a third required EHLO command if the second EHLO response doesn't list any BURL options. Section 3.4.2 demonstrates this. S: 220 owlry.example.org ESMTP M: EHLO potter.example.org S: 250-owlry.example.com S: 250-8BITMIME S: 250-BINARYMIME S: 250-PIPELINING S: 250-BURL imap S: 250-CHUNKING S: 250-AUTH PLAIN S: 250-DSN S: 250-SIZE 10240000 S: 250-STARTTLS S: 250 ENHANCEDSTATUSCODES M: STARTTLS S: 220 Ready to start TLS ...TLS negotiation, subsequent data is encrypted... M: EHLO potter.example.org S: 250-owlry.example.com S: 250-8BITMIME S: 250-BINARYMIME S: 250-PIPELINING S: 250-BURL imap S: 250-CHUNKING S: 250-AUTH PLAIN S: 250-DSN S: 250-SIZE 10240000 S: 250 ENHANCEDSTATUSCODES M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= S: 235 2.7.0 PLAIN authentication successful. M: MAIL FROM: S: 250 2.5.0 Address Ok. M: RCPT TO: S: 250 2.1.5 foo@example.net OK. M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/; uid=45/;urlauth=submit+bar:internal: 91354a473744909de610943775f92038 LAST S: {to I} The mail submission server uses URLFETCH to fetch the message to be sent (See [RFC4467] for details of the semantics and steps. The so-called "pawn-ticket" authorization mechanism uses a URI which contains its own authorization credentials.). Maes, et al. Expires November 2, 2006 [Page 10] Internet-Draft LEMONADE profile bis May 2006 I: {to S} Provides the message composed as a result of the CATENATE step). Mail submission server opens IMAP connection to the IMAP server: I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com IMAP server ready S: a000 STARTTLS I: a000 Start TLS negotiation now ...TLS negotiation, if successful - subsequent data is encrypted... S: a001 LOGIN submitserver secret I: a001 OK submitserver logged in S: a002 URLFETCH "imap://bob.ar@example.org/Sent; UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar: internal:91354a473744909de610943775f92038" I: * URLFETCH "imap://bob.ar@example.org/Sent; UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar: internal:91354a473744909de610943775f92038" {15065} ...message body follows... S: a002 OK URLFETCH completed I: a003 LOGOUT S: * BYE See you later S: a003 OK Logout successful Note that if the IMAP server doesn't send CAPABILITY response code in the greeting, the mail submission server must issue the CAPABILITY command to learn about supported IMAP extensions as described in [RFC3501]. Also, if data confidentiality is not required the mail submission server may omit the STARTTLS command before issuing the LOGIN command. S: {to M} Submission server assembles the complete message and if the assembly succeeds it returns OK to the MUA: S: 250 2.5.0 Ok. M: {to I} The client marks the message containing the forwarded attachment on the IMAP server. M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded) I: * 215 FETCH (UID 25627 MODSEQ (12121231000)) I: A0053 OK STORE completed Note: the UID STORE command shown above will only work if the marked Maes, et al. Expires November 2, 2006 [Page 11] Internet-Draft LEMONADE profile bis May 2006 message is in the currently selected mailbox; otherwise, it requires a SELECT. This command can be omitted, being for metadata only. The untagged FETCH response is due to [RFC4551]. The $Forwarded IMAP keyword is described in Section 3.8. 3.4.2. Message assembly using SMTP CHUNKING and BURL extensions In the [RFC4468]/[RFC3030] variant of the Lemonade "forward without download" strategy, messages are initially composed and edited within an MUA. During submission [RFC4409], BURL [RFC4468] and BDAT [RFC3030] commands are used to create the messages from multiple parts. New body parts are supplied using BDAT commands, while existing body parts are referenced using [RFC4467] format URLs in BURL commands. The flow involved to support such a use case consists of: M: {to I -- Optional} The client connects to the IMAP server, optionally starts TLS (if data confidentiality is required), authenticates, opens a mailbox ("INBOX" in the example below) and fetches body structures (See [RFC3501]). Example: M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE) I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "trip.txt") "<960723163407.20117h@washington.example.com>" "Your trip details" "BASE64" 4554 73) "MIXED")) I: A0051 OK completed M: {to I} The client uses GENURLAUTH command to request URLAUTH URLs (See [RFC4467]) referencing pieces of the message to be assembled. I: {to M} The IMAP server returns URLAUTH URLs suitable for later retrieval with URLFETCH (See [RFC4467] for details of the semantics and steps). Maes, et al. Expires November 2, 2006 [Page 12] Internet-Draft LEMONADE profile bis May 2006 M: A0054 GENURLAUTH "imap://bob.ar@example.org/INBOX; UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL "imap://bob.ar@example.org/INBOX; UIDVALIDITY=385759045/;UID=25627/;Section=2; expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL I: * GENURLAUTH "imap://bob.ar@example.org/INBOX; UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: internal:A0DEAD473744909de610943775f9BEEF" "imap://bob.ar@example.org/INBOX; UIDVALIDITY=385759045/;UID=25627/;Section=2; expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: internal:BEEFA0DEAD473744909de610943775f9" I: A0054 OK GENURLAUTH completed M: {to S} The client connects to the mail submission server and starts a new mail transaction. It uses BURL to instruct the SMTP submit server to fetch from the IMAP server pieces of the message to be sent (See [RFC4468] for details of the semantics and steps). Note that the second EHLO command is required after a successful STARTTLS command. The third EHLO command is required if and only if the second EHLO response doesn't list any BURL options. See Section 3.4.1 for an example of submission where the third EHLO command/response is not present. S: 220 owlry.example.org ESMTP M: EHLO potter.example.org S: 250-owlry.example.com S: 250-8BITMIME S: 250-BINARYMIME S: 250-PIPELINING S: 250-BURL S: 250-CHUNKING S: 250-AUTH DIGEST-MD5 S: 250-DSN S: 250-SIZE 10240000 S: 250-STARTTLS S: 250 ENHANCEDSTATUSCODES M: STARTTLS S: 220 Ready to start TLS ...TLS negotiation, subsequent data is encrypted... M: EHLO potter.example.org S: 250-owlry.example.com S: 250-8BITMIME S: 250-BINARYMIME S: 250-PIPELINING Maes, et al. Expires November 2, 2006 [Page 13] Internet-Draft LEMONADE profile bis May 2006 S: 250-BURL S: 250-CHUNKING S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL S: 250-DSN S: 250-SIZE 10240000 S: 250 ENHANCEDSTATUSCODES M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= S: 235 2.7.0 PLAIN authentication successful. M: EHLO potter.example.org S: 250-owlry.example.com S: 250-8BITMIME S: 250-BINARYMIME S: 250-PIPELINING S: 250-BURL imap imap://imap.example.org S: 250-CHUNKING S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL S: 250-DSN S: 250-SIZE 10240000 S: 250 ENHANCEDSTATUSCODES M: MAIL FROM: BODY=BINARY S: 250 2.5.0 Address Ok. M: RCPT TO: S: 250 2.1.5 foo@example.net OK. M: BDAT 475 M: Message-ID: <419399E1.6000505@caernarfon.example.org> M: Date: Thu, 12 Nov 2004 16:57:05 +0000 M: From: Bob Ar M: MIME-Version: 1.0 M: To: foo@example.net M: Subject: About our holiday trip M: Content-Type: multipart/mixed; M: boundary="------------030308070208000400050907" M: M: --------------030308070208000400050907 M: Content-Type: text/plain; format=flowed M: M: Our travel agent has sent the updated schedule. M: M: Cheers, M: Bob M: --------------030308070208000400050907 S: 250 2.5.0 OK M: BURL imap://bob.ar@example.org/INBOX; UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: internal:A0DEAD473744909de610943775f9BEEF S: 250 2.5.0 OK M: BURL imap://bob.ar@example.org/INBOX; Maes, et al. Expires November 2, 2006 [Page 14] Internet-Draft LEMONADE profile bis May 2006 UIDVALIDITY=385759045/;UID=25627/;Section=2; expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: internal:BEEFA0DEAD473744909de610943775f9 S: 250 2.5.0 OK M: BDAT 44 LAST M: M: --------------030308070208000400050907-- S: {to I} The mail submission server uses URLFETCH to fetch the pieces of the message to be sent (See [RFC4467] for details of the semantics and steps. The so-called "pawn-ticket" authorization mechanism uses a URI which contains its own authorization credentials.). I: {to S} Returns the requested body parts. Mail submission server opens IMAP connection to the IMAP server: I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com IMAP server ready S: a001 LOGIN submitserver secret I: a001 OK submitserver logged in S: a002 URLFETCH "imap://bob.ar@example.org/INBOX; UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: internal:A0DEAD473744909de610943775f9BEEF" "imap:// bob.ar@example.org/INBOX; UIDVALIDITY=385759045/;UID=25627/;Section=2; expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: internal:BEEFA0DEAD473744909de610943775f9" I: * URLFETCH "imap://bob.ar@example.org/INBOX; UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: internal:A0DEAD473744909de610943775f9BEEF" {84} ...message section follows... "imap://bob.ar@example.org/INBOX; UIDVALIDITY=385759045/;UID=25627/;Section=2; expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: internal:BEEFA0DEAD473744909de610943775f9" {15065} ...message section follows... S: a002 OK URLFETCH completed I: a003 LOGOUT S: * BYE See you later S: a003 OK Logout successful Note that if the IMAP server doesn't send CAPABILITY response code in the greeting, the mail submission server must issue the CAPABILITY command to learn about supported IMAP extensions as described in Maes, et al. Expires November 2, 2006 [Page 15] Internet-Draft LEMONADE profile bis May 2006 [RFC3501]. Also, if data confidentiality is required the mail submission server should start TLS before issuing the LOGIN command. S: {to M} Submission server assembles the complete message and if the assembly succeeds it acknowledges acceptance of the message by sending 250 response to the last BDAT command: S: 250 2.5.0 Ok, message accepted. M: {to I} The client marks the message containing the forwarded attachment on the IMAP server. M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded) I: * 215 FETCH (UID 25627 MODSEQ (12121231000)) I: A0053 OK STORE completed Note: the UID STORE command shown above will only work if the marked message is in the currently selected mailbox; otherwise, it requires a SELECT. This command can be omitted. The untagged FETCH response is due to [RFC4551]. The $Forwarded IMAP keyword is described in Section 3.8. 3.5. Normative statements related to forward without download Lemonade compliant IMAP servers MUST support IMAPv4Rev1 [RFC3501], CATENATE [RFC4469], UIDPLUS [RFC4315] and URLAUTH [RFC4467]. This support MUST be declared via CAPABILITY [RFC3501]. Lemonade compliant submit servers MUST support the BURL [RFC4468], 8BITMIME [RFC1652], BINARYMIME [RFC3030] and CHUNKING [RFC3030]. This support MUST be declared via EHLO [RFC2821]. BURL MUST support URLAUTH type URLs [RFC4467], and thus MUST advertise the "imap" option following the BURL EHLO keyword (See [RFC4468] for more details). Additional normative statements are provided in other sections. 3.6. Security Considerations for pawn-tickets. The so-called "pawn-ticket" authorization mechanism uses a URI, which contains its own authorization credentials using [RFC4467]. The advantage of this mechanism is that the SMTP submit [RFC4409] server cannot access any data on the [RFC3501] server without a "pawn- ticket" created by the client. The "pawn-ticket" grants access only to the specific data that the Maes, et al. Expires November 2, 2006 [Page 16] Internet-Draft LEMONADE profile bis May 2006 SMTP submit [RFC4409] server is authorized to access, can be revoked by the client, and can have a time-limited validity. 3.7. Copies of Sent messages: The fcc problem The "fcc problem" refers to delivering a copy of a message to a mailbox, or "file carbon copy". By far, the most common case of fcc is a client leaving a copy of outgoing mail in a "Sent Mail" or "Outbox" mailbox. In the traditional strategy, the MUA duplicates the effort spent in transmitting to the MSA by writing the message to the fcc destination in a separate step. This may be a write to a local disk file or an APPEND to a mailbox on an IMAP server. The latter is one of the " repetitive network data transmissions" which represents the "problem" aspect of the "fcc problem". The BURL [RFC4468] extension can be used to eliminate the additional transmission. The final message is uploaded to the mailbox designed for outgoing mail, by the APPEND command of [RFC3501]. Note that APPEND, including when enhanced by [RFC4469], can only create a single message and this is only of use on the server which stages the outgoing message for submission. Additional copies of the message can be created on the same server using one or more COPY commands. 3.8. Registration of $Forwarded IMAP keyword The $Forwarded IMAP keyword is used by several IMAP clients to specify that the marked message was forwarded to another email address, embedded within or attached to a new message. A mail client sets this keyword when it successfully forwards the message to another email address. Typical usage of this keyword is to show a different (or additional) icon for a message that has been forwarded. Once set the flag SHOULD NOT be cleared. Lemonade compliant servers MUST be able to store the $Forwarded keyword. They MUST preserve it on the COPY operation. The servers MUST support the SEARCH KEYWORD $Forwarded. 4. Message Submission LEMONADE compliant mail submission servers are expected to implement the following set of SMTP extensions to make message submission efficient. Lemonade clients should take advantage of these features. Maes, et al. Expires November 2, 2006 [Page 17] Internet-Draft LEMONADE profile bis May 2006 4.1. Pipelining Mobile clients regularly use networks with a relatively high latency. Avoidance of round-trips within a transaction has a great advantage for the reduction in both bandwidth and total transaction time. For this reason LEMONADE compliant mail submission servers MUST support the SMTP Service Extensions for Command Pipelining [RFC2197]. Clients SHOULD pipeline SMTP commands when possible. 4.2. DSN Support LEMONADE compliant mail submission servers MUST support SMTP service extensions for delivery status notifications [RFC3461]. 4.3. Message size declaration LEMONADE compliant mail submission servers MUST support the SMTP Service Extension for Message Size Declaration [RFC1870]. LEMONADE compliant mail submission servers MUST resolve all BURL parts before enforcing a message size limit. A LEMONADE compliant client SHOULD use message size declaration. In particular the client MUST NOT send a message to a mail submission server, if it knows that the message exceeds the maximal message size advertised by the submission server. When including a message size in the MAIL FROM command, the client MUST use a value that is at least as large as the size of the message after expansion of all BURL parts. 4.4. Enhanced status code Support LEMONADE compliant mail submission servers MUST support SMTP Service Extension for Returning Enhanced Error Codes [RFC2034]. 4.5. TLS LEMONADE Compliant mail submission servers MUST support SMTP Service Extension for Secure SMTP over TLS [RFC3207]. 5. Message Store Lemonade compliant message store services provide an IMAP service with the following set of extensions in order to provide both efficient access to the message store and support constrained devices more effectively. Maes, et al. Expires November 2, 2006 [Page 18] Internet-Draft LEMONADE profile bis May 2006 5.1. Quick resynchronization LEMONADE Compliant IMAP servers MUST support the CONDSTORE [RFC4551] extension. It allows a client to quickly resynchronize any mailbox by asking the server to return all flag changes that have occurred since the last known mailbox synchronization mark. [RFC4549] shows how to perform quick mailbox resynchronization. In addition, LEMONADE Compliant IMAP servers MUST support the RECONNECT [I-D.ietf-lemonade-reconnect] extension to provide quick reconnection facilities in case the transport layer is cut, whether accidentally or as part of a change in network. 5.2. Message part handling LEMONADE Compliant IMAP servers MUST support the BINARY [RFC3516] extension. This moves MIME body part decoding operations from the client to the server. The decoded data is equal or less than the encoded representation, so this reduces bandwidth effectively. [RFC3516] allows for servers to refuse to accept uploaded messages containing binary data, however LEMONADE Compliant IMAP servers SHALL always accept binary encoded MIME messages in APPEND commands for any folder. [I-D.ietf-lemonade-convert] MUST also be supported by servers, which allows clients to request conversions between media types, and allows for scaling images, etc. This provides the ability to view attachments (and sometimes body parts) without the facility to cope with a wide range of media types, or to efficiently view attachments. 5.3. Compression The IETF has for some time generally agreed that compression is best handled at as low a level as possible, therefore Lemonade compliant IMAP servers SHOULD support the Deflate compression algorithm for TLS, as defined in [RFC3749]. However, the working group acknowledges that for many endpoints, this is a rarely deployed technology, as as such, Lemonade compliant IMAP servers MUST provide [I-D.gulbrandsen-imap-deflate] support for fallback application-level stream compression, where TLS is not actively providing compression. 5.4. Out of band notifications Server to client notifications as discussed in [I-D.ietf-lemonade- Maes, et al. Expires November 2, 2006 [Page 19] Internet-Draft LEMONADE profile bis May 2006 notifications]. Server to server notifications discussed in [I-D.ietf-lemonade-notifications] describes how NF interacts with the notifications mechanisms. <> 5.5. Virtual Mailboxes Lemonade compliant IMAP servers provide a mechanism for clients to avoid handling an entire mailbox, instead accessing a view of the mailbox defined previously. This technique, common in many desktop clients as a client-side capability, is useful for constrained clients to minimize the quantity of messages and notification data. This virtual folder mechanism is defined in [I-D.ietf-lemonade- vfolder]. <> 5.6. Additional IMAP extensions Lemonade compliant IMAP servers MUST support the NAMESPACE [RFC2342] extension. The extension allows clients to discover shared mailboxes and mailboxes belonging to other users, and provide a normalized heirarchy view of the mailboxes available. Lemonade compliant IMAP servers MUST support the LITERAL+ [RFC2088] extension. The extension allows clients to save a round trip each time a non-synchronizing literal is sent. Lemonade compliant IMAP servers MUST support the ESEARCH [I-D.melnikov-imap-search-ret] extension. The extension allows clients to efficiently find the first or last messages, find a count of matching messages, and obtain a list of matching messages in a considerably more compact representation. Lemonade compliant IMAP servers MUST support the METADATA [I-D.daboo- imap-annotatemore] extension. This allows metadata to be stored against mailboxes, which is a facility used by other extensions mandated by this profile. Lemonade compliant IMAP servers MUST support the IDLE [RFC2177] extension. The extension allows clients to receive unsolicited notifications about changes in the selected mailbox, without needing to poll for changes. The responses forming these notifications MUST be sent in a timely manner when such changes happen. Maes, et al. Expires November 2, 2006 [Page 20] Internet-Draft LEMONADE profile bis May 2006 Lemonade Compliant IMAP servers MUST support IMAP over TLS [RFC3501] as required by [RFC3501]. As noted above in Section 5.3, servers SHOULD support the deflate compression algorithm for TLS, as specified in [RFC3749] 6. Summary of the required IMAP and SMTP extensions +-------------------------+----------------------------------------+ | Name of SMTP extension | Comment | +-------------------------+----------------------------------------+ | PIPELINING | Section 4.1 | | DSN | Section 4.2 | | SIZE | Section 4.3 | | ENHANCEDSTATUSCODES | Section 4.4 | | STARTTLS | Section 4.5 | | BURL | Section 3 | | URLAUTH support in BURL | Section 3 | | CHUNKING, BINARYMIME | Section 3.5 | | 8BITMIME | Required by BURL | | AUTH | Required by Submission. See [RFC2554] | +-------------------------+----------------------------------------+ +-----------------------------------+----------------------------+ | Name of IMAP extension or feature | Comment | +-----------------------------------+----------------------------+ | NAMESPACE | Section 5.6 | | CONDSTORE | Section 5.1 | | STARTTLS | Required by IMAP [RFC3501] | | URLAUTH, CATENATE, UIDPLUS | Section 3 | | LITERAL+ | Section 5.6 | | IDLE | Section 5.6 | | $Forwarded IMAP keyword | Section 3.8 | | BINARY | Section 5.2 | | RECONNECT | Section 5.1 | | ESEARCH | Section 5.6 | | VFOLDER | Section 5.5 | | CONVERT | Section 5.2 | | COMPRESS=DEFLATE | Section 5.3 | | METADATA | Section 5.6 | +-----------------------------------+----------------------------+ 7. OMA MEM Requirement document The OMA MEM activity has collected a set of use cases and derived requirements for a mobile email enabler (MEM). the resulting work is summarized in OMA MEM Requirement document [MEM-req]. Some Maes, et al. Expires November 2, 2006 [Page 21] Internet-Draft LEMONADE profile bis May 2006 requirements relates to email protocols, some involve other OMA technologies outside the scope of IETF and some relate to implementations and normative interoperability statements for clients and servers. 7.1. OMA MEM Architecture The OMA MEM activity has derived a logical architecture from the requirements and use cases described in [MEM-req]. The logical architecture, its elements and interfaces and the notations that it uses can be found in [MEM-arch]. 7.2. OMA MEM Deployment Issues The OMA MEM Architecture document [MEM-arch] further identifies deployment models. Certain of these deployment models are not what IETF has conventionally modeled. They require special attention to end-to-end security aspects and may warrant introduction of additional security measures (e.g. object level encryption). 7.3. OMA MEM proxy The OMA MEM Architecture document [MEM-arch] identifies OMA MEM server proxies as server components that may be deployed ahead of firewalls to facilitate traversal of firewalls. Both IMAP and SMTP generally are compatible with proxies between the client and the server. Such proxies may disrupt end-to-end encryption, with the transport-level encryption ending at the proxy and re-generating from the proxy to the server. Again this may require additional security measures like object level encryption. 7.4. IETF LEMONADE Architecture This section gives a brief introduction to the LEMONADE Architecture. The IETF LEMONADE activity has derived a profile with the logical architecture represented in Figure 15, where arrows indicate content flows. Maes, et al. Expires November 2, 2006 [Page 22] Internet-Draft LEMONADE profile bis May 2006 ______________ | | _________| Notification | | | Mechanism | | |______________| |Notif. ^ |Protocol | | ___|______ | | | _____ __v__ IMAP | LEMONADE | ESMTP | | | |<----------->| IMAP |<---------------| MTA | | MUA |- | Store | |_____| |_____| \ |__________| \ | \ |URLAUTH \SUBMIT | \ ____v_____ \ | | _____ \ | LEMONADE | ESMTP | | ---->| Submit |--------------->| MTA | | Server | |_____| |__________| Figure 15: LEMONADE logical architecture The LEMONADE profile assumes: <> o IMAP protocol [RFC3501] including LEMONADE profile extensions o Submit protocol ([RFC4409], profile of [RFC2821]) including LEMONADE profile extensions o LEMONADE profile compliant IMAP store connected to MTA (Mail Transfer Agent) via ESMTP [RFC2821]. o LEMONADE profile compliant Submit server connected to MTA via ESMTP o Lemonade profile message store / Submit server protocols (URLAUTH) (see [RFC4467]). o Outband server to client notifications relying on external notification mechanisms (and notification protocols) that may be out of scope of the LEMONADE profile. o A LEMONADE aware MUA (Mail User Agent). While use of outband notification is described in the LEMONADE profile, support for the underlying notifications mechanisms/protocols is out of scope of the LEMONADE specifications. Further details on the IETF email protocol stack and architecture can be found in [I-D.crocker-email-arch] Note that in Figure 15 the IMAP server and Submit server are Maes, et al. Expires November 2, 2006 [Page 23] Internet-Draft LEMONADE profile bis May 2006 represented connected to MTAs (Mail Transfer Agents) via ESMTP [RFC1861]. This is not really essential. It could as well be X.400 so long as the message in the store is in the internet form. OMA MEM identifies other functionalities. These are considered as out of scope of the LEMONADE work and will need to be specified by OMA MEM. 7.5. LEMONADE profile logical architecture This section details the LEMONADE profile logical architecture. This architecture is also expected to support the OMA MEM logical Architecture. 7.5.1. Relationship between the OMA MEM and LEMONADE logical architectures Figure 16 illustrates the mapping of the IETF LEMONADE logical architecture on the OMA MEM logical architecture. Maes, et al. Expires November 2, 2006 [Page 24] Internet-Draft LEMONADE profile bis May 2006 _____________________ | Other_Mob. Enablers | | |--------------| | _________| Notification | | | | | Mechanism | | | | |______________| | |Notif. |____________^________| |Protocol ______|__________ ME-4 | | ___|_ME-3_ | ___|____ | | | | _____ | __v__ | IMAP | | LEMONADE | | ESMTP | | || |<----------->| IMAP |<-----------| MTA | || MUA || ME-2a | | Store | | |_____| ||_____||\ME-1 | |__________| | | MEM | \ | | | | Client| \ | |URLAUTH | |_______| \SUBMIT | | \ | ____v_____ | \ | | | | _____ \ | | LEMONADE | | ESMTP | | ---->| Submit |----------->| MTA | ME-2b | | Server | | |_____| | |__________| | |MEM Email | |Server Server| |_________________| ^ |ME-5 | Figure 16: Mapping of LEMONADE profile logical architecture onto the OMA MEM logical architecture. As described in Section 7.4, the LEMONADE profile assumes LEMONADE profile compliant IMAP stores and Submit servers. Because the LEMONADE profile extends the IMAP store and the submit server, the mobile enablement of email provided by the LEMONADE profile is directly provided in these server. Mapped to OMA MEM logical architecture, for the case considered and specified by the LEMONADE profile, the MEM server and email server logically combined. They are however split into distinct LEMONADE message store and LEMONADE submit server. The OMA MEM interfaces ME-2 ([MEM-arch]) consists of two interfaces ME-2a and ME-2b associated respectively to IMAP extended according to the LEMONADE profile and SUBMIT extended according to the LEMONADE profile. The MUA is part of the MEM client. Maes, et al. Expires November 2, 2006 [Page 25] Internet-Draft LEMONADE profile bis May 2006 External notifications mechanism can be part of the other OMA enabler specified by OMA (or other activities). 7.5.2. LEMONADE realization of OMA MEM with non-LEMONADE compliant servers The OMA MEM activity is not limited to enabling Lemonade compliant servers. It explicitly identifies the need to support other backends. 7.5.2.1. LEMONADE realization of OMA MEM with non-LEMONADE enhanced IMAP servers Figure 17 illustrates the case of IMAP servers that are not (yet) LEMONADE compliant / enhanced with LEMONADE. In such case, the I2 interface between the MEM server components and the IMAP store and submit server are IMAP and SUBMIT. ______________ | | _________| Notification | | | Mechanism | | |______________| |Notif. ^ |Protocol | | ___|______ _____________ | | LEMONADE | | | _____ __v__ IMAP | MEM | IMAP |NON-LEMONADE | ESMTP | | | |<--------->|Enabler |<------>|IMAP |<----->| MTA | | MUA |\ ME-2a | Server | |Store | |_____| |_____| \ |__________| |_____________| \ | \ |URLAUTH \SUBMIT | \ ____v_____ _____________ \ | | | | _____ \ | LEMONADE | SUBMIT |NON-LEMONADE | ESMTP | | -->| MEM | |Submit | | | | Enabler |------->|Server |------>| MTA | ME-2b | Server | | | |_____| |__________| |_____________| Figure 17: Architecture to support non-LEMONADE enhanced IMAP servers with a LEMONADE realization of OMA MEM enabler. In Figure 17, the server may be a separate proxy. Maes, et al. Expires November 2, 2006 [Page 26] Internet-Draft LEMONADE profile bis May 2006 7.5.2.2. LEMONADE realization of OMA MEM with non-IMAP servers < Figure 18 illustrates the cases where the message store and submit servers are not IMAP store or submit servers. They may be POP3 servers or other proprietary message stores. ______________ | | _________| Notification | | | Mechanism | | |______________| |Notif. ^ |Protocol | | ___|______ _____________ | | LEMONADE | | | _____ __v__ IMAP | MEM | I2 |Proprietary | ESMTP | | | |<--------->|Enabler |<------>|Message |<----->| MTA | | MUA |\ ME-2a | Server | |Store | |_____| |_____| \ |__________| |_____________| \ | \ |URLAUTH \SUBMIT | \ ____v_____ _____________ \ | | | | _____ \ | LEMONADE | I2 |Proprietary | ESMTP | | -->| MEM | |Submit | | | | Enabler |------->|Server |------>| MTA | ME-2b | Server | | | |_____| |__________| |_____________| Figure 18: Architecture to support non-IMAP servers with a LEMONADE realization of OMA MEM enabler. I2 designates proprietary adapters to the backends. They may involved functions performed in the message stores or submit server as well as in the MEM enabler server. In Figure 18, the server may be a separate proxy. 7.6. Filters and server to client notifications and LEMONADE OMA MEM RD [MEM-req] and AD [MEM-arch] emphasize the need to provide mechanisms for server to client notifications of email events and filtering. Figure 19 illustrates how notification and filterings are Maes, et al. Expires November 2, 2006 [Page 27] Internet-Draft LEMONADE profile bis May 2006 introduced in LEMONADE profile. ______________ | | _________| Notification | | | Mechanism | | |______________| |Notif. ^ |Protocol -------\ _|_ | ______| ___\>|NF|____ | | | ---- | _____ __v__| IMAP |__ LEMONADE |___ ESMTP __| | | |<-------->|VF| IMAP |DF |<--------|AF| MTA | | MUA |\ ME-2a |-- Store |--- --|_____| |_____| \ |_____________| ^ \_\_______________|_______| \ |URLAUTH \SUBMIT | \ ____v_____ \ | | _____ \ | LEMONADE | ESMTP | | ---->| Submit |--------------->| MTA | ME-2b | Server | |_____| |__________| Figure 19: Filtering mechanism defined in LEMONADE architecture In Figure 19, four categories of filters are defined: o AF: Administrative Filters - Set up by email service provider. AF are typically not configured by the user and set to apply policies content filtering, virus protection, spam filtering etc... o DF: Deposit Filters - Filters that are executed on deposit of new email messages. They can be defined as SIEVE filters [SIEVE]. They can include vacation notices. o VF: View Filters - Filters that define which emails are visible to the MUA. View filters can be defined as virtual folders [I-D.ietf-lemonade-vfolder] as described in [I-D.ietf-lemonade- vfolder] and [I-D.ietf-lemonade-notifications]. o NF: Notification Filters - Filters that define for what email server event an outband notification is sent to the client. The filters are manageable from the MUA: o NF and DF: via SIEVE Management protocol [I-D.martin-managesieve] Maes, et al. Expires November 2, 2006 [Page 28] Internet-Draft LEMONADE profile bis May 2006 o VF: via virtual folder mechanisms as discussed in [I-D.ietf- lemonade-vfolder] and [I-D.ietf-lemonade-notifications] 7.7. LEMONADE Profile features <> The LEMONADE Profile provides normative support for the technical features identified within scope of IETF LEMONADE work in the OMA MEM realization internet draft. The following is a list of features that will be normatively described: <> o LEMONADE profile features, evolved to include capabilities to edit on MUA and send differences to server even for address fields. o Server to client notifications as discussed in [I-D.ietf-lemonade- notifications]. Server to server notifications discussed in [I-D.ietf-lemonade-notifications] describes how NF interacts with the notifications mechanisms. o Filters as discussed in [I-D.ietf-lemonade-notifications], [I-D.ietf-lemonade-vfolder], [I-D.ietf-lemonade-search-within], [SIEVE] and [I-D.ietf-lemonade-imap-sieve]. Events that can be bound to notifications are described in [I-D.ietf-lemonade- msgevent]. Filter remote management are discussed in [I-D.ietf- lemonade-notifications] and [I-D.ietf-lemonade-vfolder]. For NF, it MAY rely on [I-D.martin-managesieve] o Virtual folders as discussed in [I-D.ietf-lemonade-vfolder] o Media conversion as discussed in [I-D.ietf-lemonade-convert]. Streamed media conversion is still under consideration. o Quick reconnect as discussed in [I-D.ietf-lemonade-reconnect] o Compression as discussed in [I-D.gulbrandsen-imap-deflate]. o Intermediaries as discussed in [I-D.smaes-lemonade-intermediary- challenges]. Best practices are discussed in [I-D.ietf-lemonade- deployments]. Lemonade protocols MAY also follow [I-D.maes- lemonade-tcp-challenged-environments] o Proxies and other intermediaries that provide protocol support disrupt conventional IETF security models and require object level encryption as discussed in [I-D.ietf-lemonade-convert]. [I-D.ietf-lemonade-notifications] further discusses the use for notification encryption. Maes, et al. Expires November 2, 2006 [Page 29] Internet-Draft LEMONADE profile bis May 2006 o Message recall within SUBMIT domain based on [RFC3888]. 8. Security Considerations Security considerations on Lemonade "forward without download" are discussed throughout Section 3. Additional security considerations can be found in [RFC3501] and other documents describing other SMTP and IMAP extensions comprising the Lemonade Profile. Note that the mandatory-to-implement authentication mechanism for SMTP submission is described in [RFC4409]. The mandatory-to- implement authentication mechanism for IMAP is described in [RFC3501]. 8.1. Confidentiality Protection of Submitted Messages When clients submit new messages, link protection such as TLS guards against an eavesdropper seeing the contents of the submitted message. It's worth noting, however, that even if TLS is not used, the security risks are no worse if BURL is used to reference the text than if the text is submitted directly. If BURL is not used, an eavesdropper gains access to the full text of the message. If BURL is used, the eavesdropper may or may not be able to gain such access, depending on the form of BURL used. For example, some forms restrict use of the URL to an entity authorized as a submission server or a specific user. 8.2. TLS When LEMONADE clients use the BURL extension to mail submission, an extension that requires sending a URLAUTH token to the mail submission server, such a token should be protected from interception to avoid a replay attack that may disclose the contents of the message to an attacker. TLS based encryption of the mail submission path will provide protection against this attack. LEMONADE clients SHOULD use TLS-protected IMAP and mail submission channels when using BURL-based message submission to protect the URLAUTH token from interception. LEMONADE compliant mail submission servers SHOULD use TLS-protected IMAP connections when fetching message content using the URLAUTH token provided by the LEMONADE client. When a client uses SMTP STARTTLS to send a BURL command which references non-public information, there is a user expectation that the entire message content will be treated confidentially. To meet Maes, et al. Expires November 2, 2006 [Page 30] Internet-Draft LEMONADE profile bis May 2006 this expectation, the message submission server should use STARTTLS or a mechanism providing equivalent data confidentiality when fetching the content referenced by that URL. 8.3. Additional extensions and deployment models This specification provides no additional security measures beyond those in the referenced Internet Mail and LEMONADE documents. We note however the security risks associated to: o Outband notifications o Server configuration by client o Client configuration by server o Presence of proxy servers o Presence of servers as intermediaries o In general the deployment models considered by OMA MEM that are not conventional IETF deployment models. o Measures to address the need to traverse firewalls and mobile network intermediaries. 9. IANA considerations This document doesn't require any IANA registration or action that are not covered by the different drafts and RFCs included in the realization described in this document. We note the reserved mailbox / folder names in [I-D.ietf-lemonade- vfolder]. 10. Future work o The different drafts and RFCs referenced in this document must be completed and separated into normative and informative references. o Text will be updated as described in editor's notes 11. Version history o Version 02: * Update of references and how they are displayed in the text (Comments from Randy Gellens) * Update of list of extensions to support as MUST by the Lemonade Profile Bis * Update of options for compression via placeholder imap- compression section describing compression requirements Maes, et al. Expires November 2, 2006 [Page 31] Internet-Draft LEMONADE profile bis May 2006 * Update of support of TCP chalenged environments * Update of support of object level encryption * Clarified the use of $Forwarded in the examples, and demonstrated how to remove the \Draft flag from the sent message * Clarified $Forwarded * Added RECONNECT to imap-condstore section * Add new section imap-bodypart, "Message part handling", describing BINARY and CONVERT requirements * Added placeholder section for notifications * Added various extensions to imap-other section, and added clarifying comments to IDLE, NAMESPACE, and a further references to TLS DEFLATE compression * Added extension names to IMAP table * Fixed all issues found with original Lemonade profile so far. o Version 01: * LEMONADE profile has been introduced in-line, with some updates / corrections. * Subsequent re-organization of the text * Details of extensions proper to Lemonade Profile-bis have been updated to refer to the drafts newly accepted as WG IETF drafts. * Addition of appendix on attachements streaming. o Version 00: * It evolved from a combination of the content of LEMONADE profile and the OMA MEM realization internet draft. 12. Acknowledgements The editors acknowledge and appreciate the work and comments of the IETF LEMONADE working group and the OMA MEM working group. In particular, the editors would like to thank Eric Burger, Randall Gellens, Zoltan Ordogh, Greg Vaudreuil, and Fan Xiaohui for their comments and reviews. Appendix A. Streaming attachments <> <> Maes, et al. Expires November 2, 2006 [Page 32] Internet-Draft LEMONADE profile bis May 2006 +----------+ +--------+ +---------+ | LEMONADE | (2) | Media | (3) | Media | | IMAP |<-------->| Server |<----->|Converter| | Store | | | | | +----------+ +--------+ +---------+ ^ ^ | | |(1) | | |(4) | | +----V---+ | | | | | Client <-----------------| | | +--------+ Figure 20: LEMONADE architecture to support streaming and conversion of attachments In Figure 20: o (1) Designates: * (a) The request (to be defined by Lemonade) for content streaming (possibly with conversion) sent by the client to the IMAP store. * (b) The response from the IMAP store (if any). o (2) Designates: * A yet to be defined rest to initiate streaming of converted content to the client. * The response o (3) Designates : * (a) A yet to be defined request by the media server to convert content as requested by the client. This could be based on OMA STI. <> * (b) The response o (4) Designates: * (a) The signaling between the Media Server and the client to initiate and control streaming of the media * (b) The actual media streaming o This could involve SIP, RTP, RTSP, ... <> o <> 13. References Maes, et al. Expires November 2, 2006 [Page 33] Internet-Draft LEMONADE profile bis May 2006 13.1. Normative References [I-D.crocker-email-arch] Crocker, D., "Internet Mail Architecture", draft-crocker-email-arch-04 (work in progress), March 2005. [I-D.daboo-imap-annotatemore] Daboo, C., "IMAP ANNOTATEMORE Extension", draft-daboo-imap-annotatemore-08 (work in progress), November 2005. [I-D.gulbrandsen-imap-deflate] Gulbrandsen, A., "The IMAP COMPRESS=DEFLATE extension", draft-gulbrandsen-imap-deflate-02 (work in progress), March 2006. [I-D.ietf-lemonade-convert] Maes, S. and R. Cromwell, "CONVERT", draft-ietf-lemonade-convert-01 (work in progress), January 2006. [I-D.ietf-lemonade-imap-sieve] Leiba, B., "Support for Sieve in Internet Message Access Protocol (IMAP4)", draft-ietf-lemonade-imap-sieve-00 (work in progress), December 2005. [I-D.ietf-lemonade-msgevent] Newman, C., "Internet Message Store Events", draft-ietf-lemonade-msgevent-00 (work in progress), June 2006. [I-D.ietf-lemonade-notifications] Maes, S., "Lemonade notifications and filters", draft-ietf-lemonade-notifications-00 (work in progress), January 2006. [I-D.ietf-lemonade-reconnect] Wilson, C. and A. Melnikov, "IMAP4 Extensions for Quick Reconnect", draft-ietf-lemonade-reconnect-05 (work in progress), January 2006. [I-D.ietf-lemonade-search-within] Maes, S. and R. Cromwell, "WITHIN Search extension to the IMAP Protocol", draft-ietf-lemonade-search-within-00 (work in progress), March 2006. [I-D.ietf-lemonade-vfolder] Maes, et al. Expires November 2, 2006 [Page 34] Internet-Draft LEMONADE profile bis May 2006 Maes, S., "Persistent Virtual Folder extension to the IMAP Protocol", draft-ietf-lemonade-vfolder-00 (work in progress), March 2006. [I-D.martin-managesieve] Martin, T. and A. Melnikov, "A Protocol for Remotely Managing Sieve Scripts", draft-martin-managesieve-06 (work in progress), February 2006. [I-D.melnikov-imap-search-ret] Melnikov, A. and D. Cridland, "IMAP4 extension to SEARCH command for controlling what kind of information is returned", draft-melnikov-imap-search-ret-02 (work in progress), October 2005. [MEM-arch] Open Mobile Alliance, "Mobile Email Architecture Document", OMA (Work in Progress), http://www.openmobilealliance.org/, October 2005. [MEM-req] Open Mobile Alliance, "Mobile Email Requirements Document", OMA http://www.openmobilealliance.org/ release_program/docs/RD/ OMA-RD-MobileEmail-V1_0_20051018-C.pdf, Oct 2005. [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994. [RFC1861] Gwinn, R., "Simple Network Paging Protocol - Version 3 -Two-Way Enhanced", RFC 1861, October 1995. [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995. [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. [RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. [RFC2197] Freed, N., "SMTP Service Extension for Command Maes, et al. Expires November 2, 2006 [Page 35] Internet-Draft LEMONADE profile bis May 2006 Pipelining", RFC 2197, September 1997. [RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998. [RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000. [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003. [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004. [RFC3888] Hansen, T., "Message Tracking Model and Requirements", RFC 3888, September 2004. [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005. [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. [RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006. [RFC4468] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006. [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, April 2006. Maes, et al. Expires November 2, 2006 [Page 36] Internet-Draft LEMONADE profile bis May 2006 [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006. [SIEVE] IETF, "SIEVE WG", http://www.ietf.org/html.charters/sieve-charter.html. 13.2. Informative References [I-D.ietf-lemonade-deployments] Gellens, R., "Deployment Considerations for lemonade- compliant Mobile Email", draft-ietf-lemonade-deployments-00 (work in progress), March 2006. [I-D.maes-lemonade-tcp-challenged-environments] Maes, S., "Lemonade in TCP Challenged Environments", draft-maes-lemonade-tcp-challenged-environments-00 (work in progress), May 2006. [I-D.smaes-lemonade-intermediary-challenges] Maes, S., "Lemonade and the challenges of Intermediaries", draft-smaes-lemonade-intermediary-challenges-02 (work in progress), November 2005. [RFC4549] Melnikov, A., "Synchronization Operations for Disconnected IMAP4 Clients", RFC 4549, June 2006. Maes, et al. Expires November 2, 2006 [Page 37] Internet-Draft LEMONADE profile bis May 2006 Authors' Addresses Stephane H. Maes (editor) Oracle MS 4op634, 500 Oracle Parkway Redwood Shores, CA 94539 USA Phone: +1-203-300-7786 Email: stephane.maes@oracle.com Alexey Melnikov (editor) Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK Email: Alexey.Melnikov@isode.com Dave Cridland (editor) Inventure Systems Ltd 21, Heol Bronwydd Caerfyrddin, Cymru SA31 2AJ GB Email: dave.cridland@invsys.co.uk Maes, et al. Expires November 2, 2006 [Page 38] Internet-Draft LEMONADE profile bis May 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Maes, et al. Expires November 2, 2006 [Page 39] --32030.1151359953.814126@peirce.dave.cridland.net Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --32030.1151359953.814126@peirce.dave.cridland.net-- From lemonade-bounces@ietf.org Tue Jun 27 05:49:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvACh-0003Jy-Oz; Tue, 27 Jun 2006 05:49:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvACg-0003Jt-WF for lemonade@ietf.org; Tue, 27 Jun 2006 05:49:55 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvACg-0002U0-GB for lemonade@ietf.org; Tue, 27 Jun 2006 05:49:54 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5R9nova007493 for ; Tue, 27 Jun 2006 12:49:53 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 12:49:48 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 12:49:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-01.txt Date: Tue, 27 Jun 2006 12:49:30 +0300 Message-ID: <0FA975F2D8295A448BE3ADC161244657603F85@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-01.txt Thread-Index: AcaWTtjSdWAnMx1aSh2R/ly5jhriYwDfPGbw From: To: X-OriginalArrivalTime: 27 Jun 2006 09:49:48.0449 (UTC) FILETIME=[072FC910:01C699CF] X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi all, I have a few comments on this new revision: General: Section numbers are missing. Introduction and overview: "Hopefully it will not be necessary to define = additional algorithms." Can we remove this sentence? The Compress command: "The client MUST NOT send additional commands = until it has seen the result of COMPRESS." Can we replace the word = "additional" with "any" to make sure that it's clear? The Compress command: "If both SASL/TLS and COMPRESS are in use, the = data should be..." isn't this a MUST? Compression efficiency: "(just a tiny bit) pmore CPU than level 9. = Independent verification" typo in pmore. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20 Sent: 23 June, 2006 01:50 To: i-d-announce@ietf.org Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Enhancements to Internet email to = support diverse service environments Working Group of the IETF. Title : The IMAP COMPRESS=3DDEFLATE Extension Author(s) : A. Gulbrandsen Filename : draft-ietf-lemonade-compress-01.txt Pages : 8 Date : 2006-6-22 =09 The COMPRESS=3DDEFLATE extension allows an IMAP connection to be compressed using the DEFLATE algorithm, such that effective compression is available even when TLS is used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-01.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-compress-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-lemonade-compress-01.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 27 06:36:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvAvN-0003Nh-PT; Tue, 27 Jun 2006 06:36:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvAvN-0003Nc-Ad for lemonade@ietf.org; Tue, 27 Jun 2006 06:36:05 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvAvL-0001K6-R2 for lemonade@ietf.org; Tue, 27 Jun 2006 06:36:05 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5RAZvSB025337; Tue, 27 Jun 2006 13:36:02 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 13:36:01 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 13:36:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Profile Bis -03 Date: Tue, 27 Jun 2006 13:35:42 +0300 Message-ID: <0FA975F2D8295A448BE3ADC16124465760400B@esebe199.NOE.Nokia.com> In-Reply-To: <32030.1151359954.696131@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Profile Bis -03 Thread-Index: AcaZbbu3YnCcYGR3Qwy1fCArvQFi3AAYW04Q From: To: , X-OriginalArrivalTime: 27 Jun 2006 10:36:00.0870 (UTC) FILETIME=[7BADA860:01C699D5] X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Thank You Dave for the update. Goog progress. Here are some comments/questions I came across while reading it: General: shouldn't the cover page say dated June, expires in December? Abstract: "this version of the LEMONADE profile." Is "this version" = needed? It is going to supercede profile - should we say this instead? Introduction: "LEMONADE assumes that the LEMONADE profile can be = used..." Can we remove "LEMONADE assumes"? 3.4.1 "This command can be omitted, being for metadata only." Suggest = wording change to: "This command is only metadata, thus it can be = omitted." 3.4.2 "This command can be omitted." Suggest same wording as previous: = "This command is only metadata, thus it can be omitted." 3.7 Looks a lot better now, thanks. 4.3 One question on this: should we mention that the size declared is = supposed to be "before compression, encyption, transfer encoding, etc". = Another question: if I do forward without download, what size do I = declare here? I might not have fetched the attachment, so I might have = no idea how big it is - does the "size of the message after expansion of = all BURL parts" statement take care of this? 4.4 "Server to client notifications as discussed in = [I-D.ietf-lemonade-notifications]. Server to server notifications = discussed in [I-D.ietf-lemonade-notifications] describes how NF = interacts with the notifications mechanisms." The two references are the = same - why not collapse these two into a single sentence without making = a difference between client-server and server-server notifications at = this point? 5.6 I-D.melnikov-imap-search-ret is an expired draft. 11.2.2. The discussion on this section did not happen yet (commented in = earlier mail). Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: ext Dave Cridland [mailto:dave@cridland.net]=20 Sent: 27 June, 2006 01:13 To: Enhancements to Internet email to support diverse service = enivronments Subject: [lemonade] Profile Bis -03 Hiya folks, I submitted the attached version of draft-ietf-lemonade-profile-bis this = morning, UK time, hence before the deadline, as version -03. I'm guessing there'll be a slight delay before it's seen in the I-D = repository, so here is an advance copy. Have fun, and see if you can = find the deliberate errors. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 28 09:34:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvaBK-0000U7-CE; Wed, 28 Jun 2006 09:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvaBJ-0000Tq-7X for lemonade@ietf.org; Wed, 28 Jun 2006 09:34:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fva19-0007Xi-Af for lemonade@ietf.org; Wed, 28 Jun 2006 09:23:43 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvZHg-0006lr-VX for lemonade@ietf.org; Wed, 28 Jun 2006 08:36:46 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 28 Jun 2006 13:34:25 +0100 Message-ID: <44A2774A.3090602@isode.com> Date: Wed, 28 Jun 2006 13:34:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zoltan.Ordogh@Nokia.com Subject: Re: [lemonade] Profile Bis -03 References: <0FA975F2D8295A448BE3ADC16124465760400B@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC16124465760400B@esebe199.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.1 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Zoltan.Ordogh@Nokia.com wrote: >3.4.1 "This command can be omitted, being for metadata only." Suggest wording change to: "This command is only metadata, thus it can be omitted." >3.4.2 "This command can be omitted." Suggest same wording as previous: "This command is only metadata, thus it can be omitted." > > RFC editor didn't like this sentence either. [...] >4.3 One question on this: should we mention that the size declared is supposed to be "before compression, encyption, transfer encoding, etc". > The ESMTP size is always the size of the fully constructed message. If a message part is using content transfer encoding, the encoded size is counted. If you are asking about COMPRES= and STARTTLS, then no, the message size is the size of the message before any lower level transformations are done. > Another question: if I do forward without download, what size do I declare here? I might not have fetched the attachment, so I might have no idea how big it is - does the "size of the message after expansion of all BURL parts" statement take care of this? > > Yes. The section basically says that if a client wants to specify SIZE parameter, it must count all BURL parts as if there were expanded. However this is just a SHOULD requirement, if the client doesn't know the final size, or if it is difficult to compute, then it should not specify the SIZE parameter at all. [...] >5.6 I-D.melnikov-imap-search-ret is an expired draft. > > Check draft-melnikov-imap-search-ret-03.txt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 28 17:18:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvhQU-0007OR-Ut; Wed, 28 Jun 2006 17:18:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvgzm-0000Vs-Ct; Wed, 28 Jun 2006 16:50:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvgWp-0007hh-LF; Wed, 28 Jun 2006 16:20:51 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvgHX-0005M7-Nx; Wed, 28 Jun 2006 16:05:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5SJo2jx013895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Jun 2006 19:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fvg30-00031v-Lc; Wed, 28 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-notifications-03.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Lemonade notifications and filters Author(s) : R. Cromwell, S. Maes Filename : draft-ietf-lemonade-notifications-03.txt Pages : 25 Date : 2006-6-28 This document discusses how to provide notification and filtering mechanisms to IMAP [RFC3501] as part the Lemonade profile [LEMONADEPROFILEBIS]. This document also discusses the use of Lemonade notifications to implement server to server notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notifications-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-notifications-03.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-lemonade-notifications-03.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: <2006-6-28135324.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-notifications-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-notifications-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28135324.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Wed Jun 28 17:29:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvhav-0003ve-Ra; Wed, 28 Jun 2006 17:29:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvgzn-0000fb-RJ; Wed, 28 Jun 2006 16:50:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvgFr-0005lB-JQ; Wed, 28 Jun 2006 16:03:19 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fvg31-0004SF-2f; Wed, 28 Jun 2006 15:50:11 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5SJo2UA029654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fvg30-00031O-Fb; Wed, 28 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-04.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : CONVERT Author(s) : S. Maes, R. Cromwell Filename : draft-ietf-lemonade-convert-04.txt Pages : 17 Date : 2006-6-28 CONVERT defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at allowing adaptation and transcoding of attachments as needed by the client. Conversion (adaptation, transcoding) may be requested by the client and performed by the server on a best effort basis or decided by the server based on its knowledge of the client capabilities, user or administrator preferences or its settings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-convert-04.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-lemonade-convert-04.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: <2006-6-28132301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-convert-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-convert-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28132301.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Wed Jun 28 17:35:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvhgj-0000bs-Bd; Wed, 28 Jun 2006 17:35:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvh1E-00047S-W8; Wed, 28 Jun 2006 16:52:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvgFr-0005iQ-JP; Wed, 28 Jun 2006 16:03:19 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fvg30-0004S9-S0; Wed, 28 Jun 2006 15:50:12 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5SJo21u029597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fvg30-00031Y-H2; Wed, 28 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-search-within-02.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : WITHIN Search extension to the IMAP Protocol Author(s) : S. Maes, R. Cromwell Filename : draft-ietf-lemonade-search-within-02.txt Pages : 6 Date : 2006-6-28 WITHIN is an extension to [RFC3501] SEARCH which returns messages whose internal date is within or outside a specified interval and differs from SINCE in that an interval in days is specified instead of a date. WITHIN is expected to be most useful for persistent searches in combination with mobile devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-search-within-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-search-within-02.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-lemonade-search-within-02.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: <2006-6-28133123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-search-within-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-search-within-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28133123.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Thu Jun 29 05:00:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvsOJ-0001lM-5Y; Thu, 29 Jun 2006 05:00:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvsOH-0001lH-CO for lemonade@ietf.org; Thu, 29 Jun 2006 05:00:49 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvsOC-0008K9-U3 for lemonade@ietf.org; Thu, 29 Jun 2006 05:00:49 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 7C7D34AC89 for ; Thu, 29 Jun 2006 11:00:43 +0200 (CEST) Message-Id: Date: Thu, 29 Jun 2006 11:01:38 +0200 From: Arnt Gulbrandsen To: Enhancements to Internet email to support diverse service environments Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [lemonade] compress=deflate: why turn compression off? X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi, someone (I didn't catch the name, sorry) suggested that being able to turn compression off again (via something like "COMPRESS NONE") is desirable. However, I didn't hear any use case for that. Could the person who wanted the feature speak up? Why? I didn't write that up yet, because it's tricky. Adds some otherwise unnecessary server state, so the cost needs to be judged against the value. Use cases will be helpful. (Up to now, the client can turn off client-to-server compression and the server can turn off server-to-client compression, but the client cannot direct the server to turn off server-to-client compression.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 29 05:04:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvsRQ-0002L8-9w; Thu, 29 Jun 2006 05:04:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvsRO-0002IY-Mq for lemonade@ietf.org; Thu, 29 Jun 2006 05:04:02 -0400 Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvsRJ-0008Pq-Ay for lemonade@ietf.org; Thu, 29 Jun 2006 05:04:02 -0400 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k5T93qCV010310 for ; Thu, 29 Jun 2006 04:03:54 -0500 Received: from us.oracle.com (dhcp-amer-csvpn-gw2-141-144-74-68.vpn.oracle.com [141.144.74.68]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k5T93nqg027952 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 29 Jun 2006 03:03:51 -0600 From: "Stephane H. Maes" To: "Enhancements to Internet email to support diverse service environments" Subject: RE: [lemonade] compress=deflate: why turn compression off? Date: Thu, 29 Jun 2006 02:03:40 -0700 Organization: Oracle Message-ID: <20060629020340609.00000005412@smaes-lap3> In-Reply-To: X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8010) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Arnt, I would like to have that capability for battery consumption reasons. Stephane = _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or s= tephane.maes@gmail.com (Google) -----Original Message----- From: Arnt Gulbrandsen [mailto:arnt@gulbrandsen.priv.no] = Sent: Thursday, June 29, 2006 2:02 AM To: Enhancements to Internet email to support diverse service environments Subject: [lemonade] compress=3Ddeflate: why turn compression off? Hi, someone (I didn't catch the name, sorry) suggested that being able to turn = compression off again (via something like "COMPRESS NONE") is desirable. Ho= wever, I didn't hear any use case for that. Could the person who wanted the= feature speak up? Why? I didn't write that up yet, because it's tricky. Adds some otherwise unnece= ssary server state, so the cost needs to be judged against the value. Use c= ases will be helpful. (Up to now, the client can turn off client-to-server compression and the se= rver can turn off server-to-client compression, but the client cannot direc= t the server to turn off server-to-client compression.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 29 05:28:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvsof-0000Xw-MO; Thu, 29 Jun 2006 05:28:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvsoe-0000XM-QN for lemonade@ietf.org; Thu, 29 Jun 2006 05:28:04 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvsoa-000161-Bk for lemonade@ietf.org; Thu, 29 Jun 2006 05:28:04 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id CF8F84AC89; Thu, 29 Jun 2006 11:27:58 +0200 (CEST) Message-Id: Date: Thu, 29 Jun 2006 11:28:54 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] compress=deflate: why turn compression off? References: <20060629020340609.00000005412@smaes-lap3> In-Reply-To: <20060629020340609.00000005412@smaes-lap3> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Stephane H. Maes writes: > Arnt, > > I would like to have that capability for battery consumption reasons. Explain? All the evidence I've seen so far is that receiving data data compressed requires less CPU than uncompressed. (FWIW, for those who want to try it themselves and have a linux laptop with ttcp, gunzip, ACPI support and the right sort of radio, some rough-and-ready testing is quite easy. Via ACPI you can get battery status and drain rate with fair accuracy, so all you need to do is log it to /tmp or some other RAM disk every second, then do a long series of transfers and see what eats more power. I've tried it, but only with 802.11b and an intel cpu.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 29 05:35:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvsvq-0002Id-Je; Thu, 29 Jun 2006 05:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvsvp-0002HW-0e for lemonade@ietf.org; Thu, 29 Jun 2006 05:35:29 -0400 Received: from rgminet01.oracle.com ([148.87.113.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvsvk-0001tU-LK for lemonade@ietf.org; Thu, 29 Jun 2006 05:35:28 -0400 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k5T9ZKMT003479 for ; Thu, 29 Jun 2006 03:35:21 -0600 Received: from us.oracle.com (dhcp-amer-csvpn-gw2-141-144-74-68.vpn.oracle.com [141.144.74.68]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k5T9ZIcd022012 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 29 Jun 2006 03:35:20 -0600 From: "Stephane H. Maes" To: "lemonade@ietf.org" Subject: RE: [lemonade] compress=deflate: why turn compression off? Date: Thu, 29 Jun 2006 02:35:09 -0700 Organization: Oracle Message-ID: <20060629023509687.00000005412@smaes-lap3> In-Reply-To: X-Mailer: Oracle Connector for Outlook 10.1.2.0.3 71207 (11.0.8010) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Spam-Score: 0.5 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org When under battery strain, I may selectively request to get a content compr= ess and the turn it off. I have heard arguments with both point of view on = what cost the most. = What were the results of your measures? Stephane _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) or s= tephane.maes@gmail.com (Google) -----Original Message----- From: Arnt Gulbrandsen [mailto:arnt@gulbrandsen.priv.no] = Sent: Thursday, June 29, 2006 2:29 AM To: lemonade@ietf.org Cc: Stephane H. Maes Subject: Re: [lemonade] compress=3Ddeflate: why turn compression off? Stephane H. Maes writes: > Arnt, > > I would like to have that capability for battery consumption reasons. Explain? All the evidence I've seen so far is that receiving data data compressed re= quires less CPU than uncompressed. (FWIW, for those who want to try it themselves and have a linux laptop with= ttcp, gunzip, ACPI support and the right sort of radio, some rough-and-rea= dy testing is quite easy. Via ACPI you can get battery status and drain rat= e with fair accuracy, so all you need to do is log it to /tmp or some other= RAM disk every second, then do a long series of transfers and see what eat= s more power. I've tried it, but only with 802.11b and an intel cpu.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 29 06:13:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvtWO-0001gv-Tx; Thu, 29 Jun 2006 06:13:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvtWO-0001gl-Hk for lemonade@ietf.org; Thu, 29 Jun 2006 06:13:16 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvtWK-0001po-0x for lemonade@ietf.org; Thu, 29 Jun 2006 06:13:16 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id D71B14AC89; Thu, 29 Jun 2006 12:13:10 +0200 (CEST) Message-Id: Date: Thu, 29 Jun 2006 12:14:06 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] compress=deflate: why turn compression off? References: <20060629023509687.00000005412@smaes-lap3> In-Reply-To: <20060629023509687.00000005412@smaes-lap3> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Stephane H. Maes writes: > When under battery strain, I may selectively request to get a content > compress and the turn it off. I have heard arguments with both point > of view on what cost the most. > > What were the results of your measures? Some disclaimers first. 1. VERY ROUGH AND READY. 2. 802.11b IS VERY DIFFERENT FROM MOBILE SPEEDS. 3. I USED AN INTEL CPU. In other words, it was just enough for me to look at whether the issue warranted serious consideration, nothing more. I took all the files I've downloaded or received via email since the last time I cleaned my ~/tmp directory. For each file, I transferred it lots of times to my laptop using ttcp, without compression, with gzip -1 and gzip -9, and checked the battery status using /proc/acpi on the receiver. (This on a Lifebook S6010, which reports battery status well. The laptop was otherwise idle.) For some files, the -9 used the least battery power per transmission. For some, the -1. Uncompressed never won discernibly. There were some ties. I couldn't see any pattern (which would have interested me, since that could enable the client to predict that the server should not compress). I kept the shell scripts, in case anyone wants to do this with a real radio and wants a starting point. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 29 07:59:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvvB1-0005nD-0y; Thu, 29 Jun 2006 07:59:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvvB0-0005n3-6M for lemonade@ietf.org; Thu, 29 Jun 2006 07:59:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvtui-0004nn-Jr for lemonade@ietf.org; Thu, 29 Jun 2006 06:38:24 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvtrA-0001B9-Vq for lemonade@ietf.org; Thu, 29 Jun 2006 06:34:51 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 17D7E4ACE4; Thu, 29 Jun 2006 12:34:19 +0200 (CEST) Message-Id: Date: Thu, 29 Jun 2006 12:35:14 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] compress=deflate: why turn compression off? References: <20060629023509687.00000005412@smaes-lap3> In-Reply-To: <20060629023509687.00000005412@smaes-lap3> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: -2.3 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "Stephane H. Maes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Stephane H. Maes writes: > When under battery strain, I may selectively request to get a content > compress and the turn it off. I have heard arguments with both point > of view on what cost the most. Forgot to answer this. Perhaps the distinction between compression and decompression got lost somewhere along the line? It's easy to find files that require lots of CPU (and battery power) to compress. It's plausible that in some (or many?) cases, compress+transmit is more expensive than transmit. But that's irrelevant. Usually the sender isn't battery-constrained, and even when it is, the sender already has the possibility to adjust its compression expense up and down, all the way down to zero. Decompression is the issue. Decompression seems (from what everyone says) to be a win-or-even in terms of power. Can you (or anyone) find exceptions? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 29 12:52:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvzkh-0005GZ-Tu; Thu, 29 Jun 2006 12:52:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvzkh-0005GU-F9 for lemonade@ietf.org; Thu, 29 Jun 2006 12:52:27 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvzkg-0000fD-7Z for lemonade@ietf.org; Thu, 29 Jun 2006 12:52:27 -0400 X-IronPort-AV: i="4.06,192,1149480000"; d="scan'208"; a="34840329:sNHT29835380" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Jun 2006 12:52:24 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664703388F45@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Agenda and Reading List Thread-Index: AcabnGWNfmcbLtR4QSKaIRfgajT/Eg== From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [lemonade] Draft Agenda and Reading List X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On-line at http://www3.ietf.org/proceedings/06jul/agenda/lemonade.txt D R A F T D R A F T D R A F T D R A F T D R A F T [Updated 060629 1300 ET] lemonade Work Group Meetings IETF 66, Montreal, PQ, Canada Agenda Bashing Drafts' Status http://www.ietf.org/internet-drafts/draft-ietf-lemonade-futuredelivery-0 4.txt Profile-bis http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-03.t xt Reconnect http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client -00.txt http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-07.txt Other Bis Components http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-01.txt http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-04.txt http://www.ietf.org/internet-drafts/draft-maes-lemonade-xencrypted-02.tx t http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-03.t xt Views http://www.ietf.org/internet-drafts/draft-ietf-lemonade-search-within-02 .txt http://www.ietf.org/internet-drafts/draft-ietf-lemonade-vfolder-01.txt Notifications http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-00.txt http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notification-pro tocol-00.txt http://www.ietf.org/internet-drafts/draft-melnikov-lemonade-imap-events- 00.txt Streaming Media http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-00.txt http://www.ietf.org/internet-drafts/draft-burger-lemonade-streamctrls-00 .txt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 29 13:01:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvztE-0000O9-PZ; Thu, 29 Jun 2006 13:01:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvztD-0000O0-HE for lemonade@ietf.org; Thu, 29 Jun 2006 13:01:15 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvztB-0002Fz-WC for lemonade@ietf.org; Thu, 29 Jun 2006 13:01:15 -0400 Received: from [192.168.0.9] ([62.3.217.253]) by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 29 Jun 2006 18:01:06 +0100 Message-ID: <44A40722.90007@isode.com> Date: Thu, 29 Jun 2006 18:00:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Burger, Eric" Subject: Re: [lemonade] Draft Agenda and Reading List References: <330A23D8336C0346B5C1A5BB1966664703388F45@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664703388F45@ATLANTIS.Brooktrout.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Burger, Eric wrote: >Views >http://www.ietf.org/internet-drafts/draft-ietf-lemonade-search-within-02 >.txt >http://www.ietf.org/internet-drafts/draft-ietf-lemonade-vfolder-01.txt > > Considering recent discussions on the mailing list I would also suggest to add draft-cridland-imap-contexts.txt to this list (BTW, Dave has forgot to submit it before the -00 deadline). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 29 16:45:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw3OQ-0004Nq-3W; Thu, 29 Jun 2006 16:45:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2yr-0001h7-UH; Thu, 29 Jun 2006 16:19:17 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw2sb-000535-4o; Thu, 29 Jun 2006 16:12:50 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5TJo39F012820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 19:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fw2WZ-0003WM-Qa; Thu, 29 Jun 2006 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 29 Jun 2006 15:50:03 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-03.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : LEMONADE profile bis Author(s) : S. Maes, et al. Filename : draft-ietf-lemonade-profile-bis-03.txt Pages : 39 Date : 2006-6-29 This document describes the LEMONADE profile. It contains pointers to or descriptions of all the features that are normatively part of this version of the LEMONADE profile. This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon extensions to IMAP and Mail Submission protocols; specifically URLAUTH and CATENATE IMAP protocol extensions and BURL extension to the SUBMIT protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lemonade-profile-bis-03.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-lemonade-profile-bis-03.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: <2006-6-29143058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-profile-bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-profile-bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-29143058.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Thu Jun 29 17:33:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw492-0005UK-RZ; Thu, 29 Jun 2006 17:33:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw491-0005UA-Rs for lemonade@ietf.org; Thu, 29 Jun 2006 17:33:51 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw490-0005ZD-8z for lemonade@ietf.org; Thu, 29 Jun 2006 17:33:51 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1Fw48z-0005x6-0D; Thu, 29 Jun 2006 21:33:49 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 95D0C498003; Thu, 29 Jun 2006 22:34:14 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31391-05; Thu, 29 Jun 2006 22:34:09 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 6E4EA498002; Thu, 29 Jun 2006 22:34:09 +0100 (BST) Date: Thu, 29 Jun 2006 22:33:38 +0100 Subject: RE: [lemonade] Profile Bis -03 References: <0FA975F2D8295A448BE3ADC16124465760400B@esebe199.NOE.Nokia.com> In-Reply-To: <0FA975F2D8295A448BE3ADC16124465760400B@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Message-Id: <8537.1151616823.309195@peirce.dave.cridland.net> From: Dave Cridland To: "Zoltan.Ordogh@Nokia.com" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.5 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue Jun 27 11:35:42 2006, Zoltan.Ordogh@Nokia.com wrote: > Thank You Dave for the update. > Goog progress. > Here are some comments/questions I came across while reading it: > General: shouldn't the cover page say dated June, expires in > December? Yes, I'd slightly messed up the boilerplate, which meant it was rejected. The good news is that not only has that been put right, but it gave me the opportunity to address your comments in part. It's almost like I planned it all along. > Abstract: "this version of the LEMONADE profile." Is "this version" > needed? It is going to supercede profile - should we say this > instead? We can do. > Introduction: "LEMONADE assumes that the LEMONADE profile can be > used..." Can we remove "LEMONADE assumes"? "LEMONADE assumes" is referring to the WG, which cannot make claims about OMA MEM realization. I've changed it to "The LEMONADE working group believes", to make this distinction clearer. > 3.4.1 "This command can be omitted, being for metadata only." > Suggest wording change to: "This command is only metadata, thus it > can be omitted." > 3.4.2 "This command can be omitted." Suggest same wording as > previous: "This command is only metadata, thus it can be omitted." I looked at what the RFC Editor did to the original ("This command can be omitted" in both), and I don't actually like it much, because it fails to explain why it can be omitted. I've tried out a new variant. > 4.3 One question on this: should we mention that the size declared > is supposed to be "before compression, encyption, transfer > encoding, etc". Another question: if I do forward without download, > what size do I declare here? I might not have fetched the > attachment, so I might have no idea how big it is - does the "size > of the message after expansion of all BURL parts" statement take > care of this? It should do, by reference to RFC1847. But I've attempted to clarify this a little. In general, clients do know the size of an attachment in its encoded form without downloading, from the BODYSTRUCTURE. In the case of forwarding a non-leaf part (say, a multipart/related or multipart/alternative) by reference, though, the client almost certainly wouldn't know. If it assembled the message via CATENATE, though, it would know the complete message size (by FETCHing RFC822.SIZE in a command pipelined with the GENURLAUTH, so there's no additional round-trip there). > 5.6 I-D.melnikov-imap-search-ret is an expired draft. That's updated. However, I missed changing the reference for compression from gulbrandsen-imap-deflate to ietf-lemonade-compress - I couldn't do this before, as the referencing library would have generated incorrect authorship for it, but I could have done when redoing the boilerplate. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade